Cloud Identity and CIEM Maturity Model: 5 Levels

In most cloud estates, machine identities outnumber people and hold permissions they have never used, so one stolen role or key reaches far more than its job requires. Turning on a cloud infrastructure entitlement management (CIEM) tool is a step, not a level of maturity. This model uses NHI Mgmt Group's five levels, Ad hoc to Optimised, to describe how cloud identity programmes progress across three core dimensions: cloud IAM hygiene, entitlement right-sizing and workload identity federation, supported by monitoring and governance. It is for cloud security, platform and identity teams who need to score where they are and agree the next step, and for leaders who need a defensible maturity number. Platforms are listed alphabetically where named; order is never a ranking. For the discipline and tooling, see the Cloud PAM and CIEM Guide; this page does not repeat it.

Key takeaways

The five levels are Ad hoc, Developing, Defined, Managed and Optimised, scored separately across five capability areas.
Usage data decides right-sizing. All three major clouds can now report unused roles, credentials or permissions; maturity is whether you act on those findings, not whether you can see them.
Level 3 is the first sensible target: every cloud identity has an owner, long-lived keys are inventoried and shrinking, and unused-access findings are reviewed on a schedule.
Level 4 changes the model, from managing stored keys to workload identity federation with tightly scoped trust conditions, so there are fewer secrets to steal.
Measure outcomes: share of workloads using federation, long-lived keys older than 90 days, and the gap between granted and used permissions.

The five levels

Level	Name	What it looks like
1	Ad hoc	No inventory of cloud identities across accounts, subscriptions and projects. Broad built-in roles such as Owner, Editor or administrator policies are granted for convenience. Long-lived access keys and service account keys sit in pipelines and laptops. Nobody owns machine identities.
2	Developing	The cloud provider's native findings are switched on in some accounts. Some unused identities are removed after audits. Human access moves to single sign-on, but workloads still rely on stored keys. Reviews are manual and irregular.
3	Defined	A cloud identity standard sets ownership, naming, maximum key age and which roles are prohibited for workloads. Every account or project is covered by entitlement analysis. Unused roles, keys and permissions are reviewed at least quarterly, and new long-lived keys need an exception.
4	Managed	CI/CD and cross-cloud workloads use federation instead of stored keys. Right-sizing recommendations are applied through infrastructure as code with tests. Privileged role use is logged and alerted on. Metrics go to leadership monthly.
5	Optimised	Long-lived keys are rare, each with a documented reason. Permissions are generated from observed use and guarded by organisation-level policies. Anomalous identity behaviour triggers automatic containment, and cross-cloud trust relationships are reviewed like code.

Capability areas

Score each area separately. The programme level is the lowest score among the three core areas.

Capability area	Level 1 Ad hoc	Level 3 Defined	Level 5 Optimised
Cloud IAM hygiene (inventory, ownership)	Identities created by hand in each account; no owner	Inventory across all clouds with owner, purpose and environment; root and break-glass accounts controlled	Identities created only through pipelines with mandatory metadata; orphans removed automatically
Entitlement right-sizing	Broad built-in roles; no usage data	Unused roles, keys and permissions reviewed quarterly; prohibited roles for workloads enforced	Least-privilege policies generated from usage and applied as code; standing privilege rare
Workload identity federation	Static keys in CI/CD, scripts and other clouds	Inventory of long-lived keys with maximum age; federation piloted for top pipelines	Federation by default with subject and attribute conditions; exceptions documented
Monitoring and detection	Cloud audit logs not retained or reviewed	Audit logs centralised; alerts on new keys, role grants and policy changes	Behavioural baselines per workload identity with automated containment
Governance and review	No reviews	Quarterly access review for privileged and machine identities, with owners attesting	Continuous, event-driven review; findings feed architecture and procurement decisions

What the native tools give you

Each major provider now reports unused or excessive access and supports keyless federation. The table summarises what each provider's documentation describes; the maturity question is whether findings are reviewed, owned and fixed.

Provider	Right-sizing signal	Workload federation
AWS	IAM Access Analyzer unused access findings report unused roles, unused IAM user access keys and passwords, and unused service-level and action-level permissions within a usage window; external and internal access findings show who can reach a resource	IAM OIDC identity providers let workloads such as GitHub Actions exchange a JWT for temporary credentials mapped to a role; AWS strongly recommends not storing long-term credentials outside AWS
Google Cloud	IAM recommender compares granted and used permissions over up to 90 days and proposes REMOVE_ROLE, REPLACE_ROLE or REPLACE_ROLE_CUSTOMIZABLE; lateral movement insights flag cross-project service account impersonation	Workload Identity Federation replaces service account keys for AWS, Azure, GitHub, GitLab, OIDC, SAML 2.0 and X.509 workloads, using pools, providers, attribute mapping and attribute conditions
Microsoft	Defender for Cloud CIEM covers Microsoft Entra ID, AWS and Google Cloud identities, with recommendations for inactive identities and overprovisioned permissions based on usage	Microsoft Entra workload identity federation lets GitHub Actions, Kubernetes, Google Cloud and AWS workloads use external tokens instead of secrets; issuer, subject and audience must match the token exactly

Availability: AWS documents that internal access and unused access findings are charged per monitored resource or per analysed role and user, while external access findings are free. Google Cloud documents that recommendations are not applied automatically and cover IAM policies only, not ACLs or Kubernetes RBAC. Microsoft documents that CIEM is included in the Defender Cloud Security Posture Management (CSPM) plan, and that the deprecation of Microsoft Entra Permissions Management does not affect Defender for Cloud CIEM.

Framework mapping

Framework	Reference	What it asks for
NIST CSF 2.0	PR.AA-01, PR.AA-05, DE.CM-03	Identities and credentials for users, services and hardware managed; permissions managed with least privilege and reviewed; technology usage monitored
NIST SP 800-53 Rev. 5	AC-2, AC-2(12), AC-6, AC-6(7), IA-5, IA-9	Account management and atypical-use monitoring; least privilege and privilege review; authenticator management; service identification and authentication
MITRE ATT&CK v20	T1078.004, T1098.001, T1098.003, T1552.005	Cloud Accounts, Additional Cloud Credentials, Additional Cloud Roles and Cloud Instance Metadata API: the techniques Levels 1 and 2 leave open

Self-assessment questions

Answer for production accounts, subscriptions and projects first. Score each answer 1 to 5.

Inventory: can you list every human and machine identity across all clouds, with an owner, within a day?
Broad roles: how many workload identities hold Owner, Editor, Contributor or administrator-equivalent permissions, and is each justified in writing?
Unused access: are unused-access findings enabled in every account and project, and what share were resolved last quarter?
Granted versus used: for your ten most privileged machine identities, what share of granted permissions was used in the last 90 days?
Long-lived keys: how many access keys and service account keys exist, how many are older than 90 days, and where are they stored?
Federation: what share of CI/CD pipelines and cross-cloud workloads authenticate through federation rather than stored keys?
Trust conditions: does every federated trust restrict the subject (repository, branch, namespace or service account) rather than trusting a whole identity provider or pool?
Metadata and workload credentials: could a server-side request forgery on a workload expose its role credentials, and would that role reach sensitive data? In the Capital One breach, a firewall's role credentials obtained through the metadata service could list and read many storage buckets.
Detection: would you be alerted to a new access key on a privileged role, a new role grant or bulk data reads by a machine identity?
Review: do owners attest to machine identity access at least quarterly, and are rejected entitlements removed?

Moving up a level

Level 1 to 2: get visibility. Enable native unused-access and external-access findings in every account, subscription and project. Build a first inventory of identities and keys. Move human administrators to single sign-on. See the Cloud IAM Review Checklist.
Level 2 to 3: set the standard. Publish a cloud identity standard: owner and purpose tags, maximum key age, prohibited roles for workloads, and an exception process for new long-lived keys. Review unused access quarterly and record decisions.
Level 3 to 4: remove keys and right-size. Move the top pipelines and cross-cloud integrations to federation with subject conditions. Apply right-sizing through infrastructure as code: test in a non-production account, apply in a pilot account, watch for access-denied errors for two weeks, then roll out. Keep the previous policy version for one-step rollback. See the Workload Identity Federation Guide.
Level 4 to 5: make least privilege the default. Generate policies from observed use, enforce organisation-level guardrails that block broad roles and key creation, baseline workload behaviour and automate containment of anomalous identities.

Small versus large organisations: a single-cloud organisation can reach Level 3 with the provider's native findings and a quarterly review in a spreadsheet. Multi-cloud estates and those with thousands of workload identities usually need a CIEM product or a central identity inventory to hold Level 3 consistently; see the CIEM Buyers Guide and the Multi-Cloud Identity Guide.

Metrics that show maturity

Share of cloud identities with a named owner.
Long-lived access keys and service account keys older than 90 days, trended down.
Share of CI/CD pipelines and cross-cloud workloads using federation.
Gap between granted and used permissions for the most privileged machine identities.
Unused-access findings resolved within the review cycle.
Federated trusts without a subject or attribute condition (target zero).

Common failure patterns

Findings without owners: unused-access reports pile up because nobody is accountable for machine identities.
Federation trusting too much: a trust that accepts any repository or a whole identity pool replaces a key problem with a broader one; Google Cloud's documentation warns that granting access to an entire pool carries risk.
Right-sizing by hand in the console: changes drift back on the next deployment; apply them as code.
Short observation windows: removing permissions after 30 days of data breaks quarterly or annual jobs; record why a permission is kept.
Keys left after federation: teams add federation but never delete the old key.
Ignoring cross-account and cross-project paths: impersonation and role chaining let a modest identity reach a powerful one.

Practitioner checklist

Score all five capability areas and take the lowest core score as the programme level.
Enable unused-access and external-access findings in every account, subscription and project.
Give every cloud identity an owner, purpose and environment tag.
Prohibit broad built-in roles for workloads and document every exception.
Inventory long-lived keys, set a maximum age and require an exception for new ones.
Move the top ten pipelines to federation with subject conditions, then delete the old keys.
Apply right-sizing as code with a pilot account and a one-step rollback.
Report the six metrics monthly and re-score the model every six months.

Cloud Identity and CIEM Maturity Model: Score Your Cloud Entitlements in Five Levels