Most cloud breaches are not the result of an exotic zero-day. They start with an over-permissioned role, a forgotten access key, or a service account nobody owns. As Australian enterprises push more workloads into AWS and Azure — often both at once — identity has quietly become the real security perimeter. Getting cloud IAM best practices right is now the single highest-leverage thing most organisations can do to reduce risk without slowing delivery.
This guide walks through the practices that matter most for AWS and Azure, with an Australian regulatory lens (APRA CPS 234, the ACSC Essential Eight) and the operational reality of running identity at scale across multiple clouds.
Why cloud IAM is different from on-premises identity
On-premises identity grew up around a network boundary: get inside the firewall and Active Directory largely decided what you could reach. In the cloud that boundary is gone. Every API call to AWS or Azure is authenticated and authorised individually, and a single misconfigured policy can expose storage, compute, or an entire management plane to the public internet.
Two consequences follow. First, the blast radius of a bad permission is larger and faster to exploit. Second, identity is now programmable — which cuts both ways. The same APIs that let an attacker escalate privileges let you codify, review, and continuously test access. The enterprises that win treat IAM as code, not as a console clicking exercise.
Core cloud IAM best practices for AWS and Azure
1. Enforce least privilege — then keep proving it
Least privilege is easy to say and hard to sustain. Permissions accrete: someone needs write access for a migration, it never gets removed, and six months later that role is a liability. The practical discipline is to grant narrowly and review continuously.
- AWS: Use IAM Access Analyzer to generate policies from actual CloudTrail activity, and to flag resources shared outside your account. Prefer permission boundaries and Service Control Policies (SCPs) at the AWS Organizations level to cap what any account can do, regardless of local policy.
- Azure: Lean on built-in Azure RBAC roles before writing custom ones, scope assignments to the narrowest resource group or resource, and use Azure AD (Entra ID) access reviews to expire standing access that is no longer justified.
The goal is not a one-off cleanup but a repeatable loop: grant, monitor real usage, right-size, and re-review on a schedule.
2. Eliminate long-lived credentials
Static access keys are the credential most likely to end up in a public code repository, a laptop, or a CI log. Wherever possible, replace them with short-lived, federated credentials.
- For human access, federate through your identity provider with SSO rather than issuing IAM users. In AWS, IAM Identity Center (formerly AWS SSO) is the default; in Azure, Entra ID already is your directory.
- For workloads, use IAM roles for service accounts, workload identity federation, and Azure managed identities so machines authenticate without a stored secret at all.
- For CI/CD pipelines, use OpenID Connect federation (for example, GitHub Actions to AWS or Azure) instead of storing keys in the pipeline.
3. Make MFA and phishing-resistant auth non-negotiable
Multi-factor authentication on every human identity — especially privileged and break-glass accounts — is the baseline the Essential Eight explicitly calls for. Push beyond SMS and app codes toward phishing-resistant methods (FIDO2 security keys, passkeys) for administrators. In Azure, enforce this with Conditional Access; in AWS, require MFA in your identity provider and through IAM policy conditions for sensitive actions.
4. Separate privileged access from everyday access
Administrators should not carry standing high-privilege rights. Just-in-time elevation limits the window an attacker can abuse. Azure AD Privileged Identity Management (PIM) lets you grant time-bound, approval-gated activation of privileged roles; on AWS, achieve the equivalent with temporary role assumption, session policies, and approval workflows. This is where cloud IAM and dedicated privileged access controls meet — a topic we cover in depth in our guide to privileged access management.
5. Centralise identity across both clouds
Running AWS and Azure with two disconnected identity stores doubles the places a joiner-mover-leaver process can fail. Federate both to a single authoritative identity provider so that deprovisioning one account removes access everywhere. This is also the foundation for consistent logging, consistent policy, and a single access review rather than several.
6. Log everything and actually watch it
Enable AWS CloudTrail across all regions and accounts, and Azure AD sign-in and audit logs, then ship them to a central store you monitor. The signal that matters most: unusual privilege escalation, new access key creation, disabled logging, and sign-ins from unexpected locations. Detection is not optional — CPS 234 expects APRA-regulated entities to detect and respond to information security incidents in a timely way, and identity logs are where the earliest signals appear.
Governance: the practice that ties it together
Tooling gets you started; governance keeps you safe. Every access grant should trace back to a role or a request, every privileged account should have a named owner, and every quarter you should be able to answer “who can touch production, and why?” without a fire drill. This is the domain of identity governance — automated joiner-mover-leaver, periodic certification, and segregation-of-duties enforcement. For regulated Australian organisations, we explore this further in identity governance and administration for regulated industries.
Cloud IAM done well is not a product you buy once. It is an operating model: least privilege enforced as code, credentials that expire by default, privileged access granted just in time, and a governance layer that continuously proves the whole thing is still true.
Meeting Australian regulatory expectations
For AU enterprises, two frameworks anchor the conversation. APRA CPS 234 requires regulated entities to maintain information security capability proportionate to threats, to clearly define information security roles and responsibilities, and to test controls — identity controls very much included. The ACSC Essential Eight calls out MFA and restricting administrative privileges as core mitigations. Mature cloud IAM is, in practice, how you satisfy large parts of both. Building the evidence trail as you go — access reviews, logs, policy-as-code history — turns your next audit from a scramble into an export.
Where to start
If you are early in the journey, sequence it: federate identity to a single provider, enforce MFA everywhere, kill long-lived keys, then layer on least-privilege tuning and just-in-time privileged access. If you are further along, the highest-value move is usually continuous verification — turning point-in-time cleanups into automated reviews and policy-as-code guardrails.
Delivery Centric helps Australian and APAC enterprises design and operate cloud IAM across AWS and Azure — from identity federation and least-privilege architecture to privileged access and governance that stands up to APRA scrutiny. If you are scaling identity across multiple clouds and want it done once, properly, talk to our team. We are also growing our identity and cloud practice if you would rather build this from the inside.
Recent Comments