Cloud identity and access management: the basics for small teams

Cloud identity and access management (IAM) decides who and what can do things in a cloud account: which people can sign in, which applications can call which services, and what each of them is allowed to change. In a cloud platform, almost everything happens through an identity, so IAM is usually where security starts. This guide explains the core ideas, least privilege, MFA for admins, roles versus users, service accounts and access reviews, using what the ACSC, Microsoft and AWS publish.

Why it matters

In most cloud services there is no locked server room. Anyone holding a valid identity with enough permissions can create, read or delete resources from anywhere. That is why Microsoft’s shared responsibility model keeps identities and access management on the customer’s side for every service type, even when the provider runs the hardware.

The ACSC’s Cloud computing security for tenants guidance lists, among its general mitigations, administering cloud services from “a corporately approved and secured computer, multi-factor authentication, a strong passphrase” and “least access privileges”. Those three ideas run through the rest of this page.

Key terms

• Identity: anything that can sign in or authenticate: a person, an application, a script or a virtual machine.
• Authentication: proving who you are (password plus MFA, a passkey, a certificate).
• Authorisation: what an authenticated identity is allowed to do. In Azure this is role-based access control (RBAC); in AWS it is IAM policies attached to users, groups and roles.
• Scope: where a permission applies. Microsoft’s RBAC documentation describes scopes from a management group or subscription down to a resource group or a single resource.
• Workload identity: Microsoft’s term for “an identity you assign to a software workload (such as an application, service, script, or container)”.

How least privilege works in Azure and AWS

Least privilege means each identity gets only the permissions it needs for its job, at the narrowest scope that works.

• Microsoft’s Azure RBAC best practices say to “grant users the least privilege to get their work done” and to “avoid assigning broader roles at broader scopes even if it initially seems more convenient to do so.”
• For privileged administrator roles, Microsoft describes removing unnecessary assignments, using a job-function role where one will do, and, if a privileged role is needed, using a narrow scope such as a resource group instead of a whole subscription.
• Microsoft’s page states a maximum of three subscription owners “to reduce the potential for breach by a compromised owner.”
• AWS’s IAM best practices describe a similar path: start with AWS managed policies, then move toward customer-managed policies tailored to the task, and use IAM conditions to restrict when a permission applies.

The trade-off is convenience. Broad roles are quicker to hand out and rarely cause “access denied” errors, which is exactly why they build up. Microsoft’s guidance on Entra admin roles is covered in our guide to Microsoft 365 admin roles and least privilege.

MFA for admins and the most powerful accounts

Administrative accounts are the highest-value targets because they can change everything else.

• AWS root user: AWS’s root user best practices describe securing root credentials and using them “for only the tasks that require them”, adding MFA (AWS says up to eight MFA devices can be registered and strongly recommends more than one), not creating access keys for the root user, and using a business-managed group email address for the root account.
• Azure: Microsoft’s mandatory MFA documentation describes Microsoft enforcing MFA for sign-ins to the Azure portal, Microsoft Entra admin center and Intune admin center (Phase 1, from October 2024), and for create, update and delete operations through Azure CLI, Azure PowerShell, the Azure mobile app, infrastructure-as-code tools, REST APIs and the Azure SDK (Phase 2, rolling out gradually from 1 October 2025). Microsoft says there is no way to opt out. Its page says Phase 2 could be postponed until 1 July 2026, a date that has now passed.

Phishing-resistant methods such as passkeys and security keys are explained in MFA methods compared.

Why roles go to groups, not individuals

A common early pattern is giving permissions directly to individual people. It works for two staff and becomes hard to follow at twenty.

• Microsoft’s RBAC best practices say to “avoid assigning roles directly to users. Instead, assign roles to groups.” This makes assignments easier to manage and keeps the number of role assignments down.
• AWS’s best practices describe requiring human users to sign in through federation with an identity provider so they get temporary credentials, with AWS IAM Identity Center as the central option, rather than long-lived IAM users.
• In AWS, an IAM role is an identity that is assumed for a session, rather than one that holds a permanent password or key. AWS’s best practices describe workloads using IAM roles to obtain temporary credentials.

Service accounts and workload identities

Applications also need identities. Older approaches often used a normal user account with a password stored in a configuration file, which brings the risks described in our guide to secrets and API keys.

• Microsoft’s workload identities page notes that a workload “may deal with multiple credentials to access different resources and those credentials need to be stored securely”, and that “it’s also hard to track when a workload identity is created or when it should be revoked.”
• Managed identities in Azure let applications obtain Microsoft Entra tokens “without having to manage any credentials.” Microsoft says managed identities can be used “at no extra cost” and describes two types: system-assigned (tied to one resource and deleted with it) and user-assigned (a standalone resource that several resources can share).
• Microsoft’s mandatory MFA page says workload identities such as managed identities and service principals aren’t affected by MFA enforcement, but user accounts used as service accounts are, and Microsoft recommends moving those to workload identities.

Access reviews and cleaning up

Access tends to grow. People change roles, contractors finish, test applications are forgotten.

• Microsoft’s access reviews overview says that “excessive access rights can lead to compromises” and asks, “As people move teams or leave the company, how do you make sure that their old access is removed?” Reviews can recur weekly, monthly, quarterly or annually. Microsoft states the feature requires Microsoft Entra ID Governance or Microsoft Entra Suite subscriptions, and that some capabilities “may operate with a Microsoft Entra ID P2 subscription.”
• AWS’s best practices describe regularly reviewing and removing unused users, roles and permissions using “last accessed” information, and using IAM Access Analyzer to generate least-privilege policies from actual activity and to verify public and cross-account access.

Teams without governance licences often run the same process by hand: export the role assignments, ask each owner to confirm them, and remove what nobody claims.

How to run a basic access review

Based on the practices described by Microsoft (Azure RBAC best practices, access reviews) and AWS (IAM best practices), checked October 2026. The exact screens change; each provider’s documentation has current steps.

1. List every identity with an owner, administrator or other privileged role, including service accounts and applications.
2. For each, record who uses it and why. Anything without a clear owner is flagged.
3. Compare the number of subscription owners with Microsoft’s stated maximum of three, and check whether the AWS root user has MFA and no access keys.
4. Look for roles assigned directly to individuals that could move to a group.
5. Use last-accessed or sign-in information to find identities and permissions that haven’t been used.
6. Remove or reduce what isn’t needed, and note the date of the review.

A fictional example

Mei looks after cloud systems for a small design firm, studio.example. When she checks the Azure subscription, she finds five owners: two former contractors, a shared “admin” login, the director and herself. A web app connects to storage using a key pasted into its settings. Using Microsoft’s RBAC guidance as a reference, she replaces the shared login with named accounts, removes the contractors, moves day-to-day staff to narrower roles assigned through a group, and switches the web app to a managed identity. She then records the changes for her next quarterly review and turns on alerts for role changes, as described in our guide to cloud logging and monitoring.

Things to watch for

• Shared admin logins. They make it impossible to tell who did what, and they rarely have MFA tied to one person.
• Break-glass accounts left unchecked. Emergency accounts are meant to be rare and closely watched, and Microsoft says they are included in mandatory MFA.
• Convenience roles that never shrink. “Owner for now” often becomes “owner forever”.
• User accounts used as service accounts. Microsoft notes these are affected by mandatory MFA, which can break automation.
• Long-lived access keys. AWS’s best practices describe preferring temporary credentials and rotating long-term keys where they are unavoidable.

Common questions

What is identity and access management (IAM) in cloud computing?

IAM is the set of controls that decide who or what can sign in to a cloud account and what each identity is allowed to do. Identities include people, applications, scripts and virtual machines. In Azure, permissions are given through role-based access control; in AWS, through IAM policies attached to users, groups and roles. Because almost everything in the cloud happens through an identity, IAM is usually where security starts. See key terms.

What does least privilege mean in the cloud?

Each identity gets only the permissions needed for its task, at the narrowest scope that works. Microsoft’s RBAC guidance says to avoid broader roles at broader scopes “even if it initially seems more convenient”, and states a maximum of three subscription owners. AWS describes moving from managed policies toward tailored policies, with conditions that restrict when a permission applies. See how least privilege works in Azure and AWS.

Do I need MFA on cloud admin accounts?

The ACSC’s cloud guidance for tenants lists multi-factor authentication for administering cloud services. AWS says it’s crucial to add MFA to the root user and strongly recommends registering more than one device. Microsoft enforces MFA for Azure portal and admin center sign-ins, and for create, update and delete operations through tools such as Azure CLI, and says there’s no way to opt out. See MFA for admins.

What’s the difference between a service account and a user account?

A user account represents a person, while a service account or workload identity represents software. Microsoft notes workloads often juggle several credentials that need secure storage, and describes managed identities as a way to avoid handling those credentials at all. Microsoft also says user accounts used as service accounts are affected by mandatory Azure MFA, which can break automation. See service accounts and workload identities.

How often should cloud access be reviewed?

There’s no single answer. Microsoft’s access reviews feature supports weekly, monthly, quarterly or annual reviews, and AWS describes regularly removing unused users, roles and permissions using last-accessed information. The right frequency depends on how often staff and systems change. Teams without governance licences often run the same process by hand. How to run a basic access review lists the steps.

What do I do if a former staff member or contractor still has cloud access?

Microsoft’s access reviews overview says excessive access rights can lead to compromises, and asks how old access is removed as people move teams or leave. A basic review lists every privileged identity, flags anything without a clear owner, and removes or reduces what isn’t needed. Shared admin logins are replaced with named accounts so it’s clear who did what. If misuse is suspected, the ACSC takes reports through ReportCyber. See access reviews and cleaning up.

Where to get official help

• The ACSC publishes cloud security guidance for organisations and runs ReportCyber and the 24/7 hotline (1300 CYBER1, 1300 292 371).
• Microsoft Learn’s Azure RBAC best practices and AWS’s IAM best practices describe each platform’s current approach.