Most cloud security incidents trace back to identity. Overly permissive IAM roles, stale service accounts, shared credentials, long-lived access keys that were never rotated: the pattern repeats across AWS, across Azure, and especially across organisations running both at once. When you add a second cloud, you do not just double the infrastructure; you double the identity surface area, and that surface area tends to be less well-governed the more distributed it becomes.
Establish a single identity source of truth
The first practice is the most important: pick one authoritative identity provider and federate everything from it. Azure Active Directory (Entra ID) works well for organisations already in the Microsoft ecosystem. Okta is a common choice for multi-cloud environments with a heterogeneous tooling stack. AWS IAM Identity Centre can act as the broker for AWS-side access.
The goal is that no user or service has a standalone cloud-native identity that exists independently of your central directory. Every identity should be created, managed, and revoked in one place. When someone leaves your organisation, you disable one account and access is removed everywhere. This sounds simple; it is surprisingly hard to achieve if you let cloud-native identities accumulate over time.
Apply least-privilege rigorously and review it regularly
Both AWS and Azure provide tools to identify excessive permissions: AWS IAM Access Analyzer and Azure AD Access Reviews surface accounts and roles with permissions they are not using. Neither is enabled by default. Switch them on, run them monthly, and act on what they surface.
The practical rule: grant the minimum permission set required for a task, time-bound where possible (using just-in-time access tooling like AWS IAM Identity Centre's permission sets or Azure PIM), and review every standing elevated permission on a regular cycle. Most organisations discover they have accumulated far more standing admin access than they realised once they start reviewing.
Enforce MFA everywhere, without exceptions
Multi-factor authentication is not optional for cloud console access. Enforce it at the identity provider level so that no route into your environment bypasses it. Be specific about which MFA types you allow: hardware keys and authenticator apps are acceptable; SMS-based MFA is weaker and should be a last resort, not the default.
Service-to-service authentication is a separate concern. Use workload identity federation (AWS IAM roles for service accounts, Azure Workload Identity) rather than static credentials wherever possible. Long-lived API keys that live in environment variables or configuration files are the most common cause of credential exposure incidents we see in environments we assess.
Instrument identity events in your observability platform
You cannot detect identity-based threats if you cannot see identity events. Both AWS CloudTrail and Azure Activity Logs capture authentication, authorisation, and configuration change events. Route these into your observability platform alongside your infrastructure and application telemetry so that anomalies in identity behaviour surface alongside the rest of your operational signal.
In practice, this means setting up alerts for: console logins from unfamiliar locations, privilege escalation events, role assumption by unexpected principals, and any API calls involving IAM or Entra ID made outside business hours. None of these are guaranteed indicators of compromise, but all of them are worth reviewing when they occur. With Datadog's Cloud SIEM capabilities, these events can be correlated and surfaced automatically rather than requiring manual log review.
Govern service account sprawl
Service accounts and machine identities accumulate faster than human identities and are reviewed far less frequently. An application that was decommissioned two years ago may still have an active service account with permissions it no longer needs. Run a quarterly audit of all non-human identities in both clouds, document what each one is for, and remove any that cannot be attributed to an active workload.
Automated tooling helps here. AWS IAM Access Analyzer's unused access findings and Azure's service principal reporting can surface candidates for removal without requiring manual investigation of each one. The key is to have a process that acts on these findings rather than just generating them.
What good looks like operationally
In environments we operate at Critical Cloud, identity hygiene is not a one-off task; it is part of the ongoing operational rhythm. We run regular access reviews, monitor identity events as part of our 24x7 observability coverage, and flag anomalies as part of our incident response process. The result is an environment where identity misconfigurations are caught early rather than discovered during a security incident. Combined with proper observability instrumentation, we have seen mean time to detection for anomalous access patterns improve significantly compared to environments that treat identity as a configuration-time concern and not an operational one.