How do Profiles and Tiers help IAM programmes mature?

Why This Matters for Security Teams

Profiles and Tiers are useful because IAM maturity is rarely linear. Most programmes accumulate controls in response to incidents, audit findings, and platform sprawl, then struggle to tell whether those controls actually improve identity risk. For human identities, that often shows up as weak provisioning discipline; for non-human identities, the gap is usually worse. NHIMG research shows that 88.5% of organisations say their non-human IAM practices lag behind or merely match human IAM, which is a strong signal that maturity needs a clearer baseline than ad hoc policy checks. The NIST Cybersecurity Framework 2.0 helps teams structure that baseline around outcomes rather than isolated tools.

For practitioners, the value is not the label itself. Profiles define the target state for a specific environment, and Tiers describe how consistently the organisation can execute against that target. That gives IAM leaders a way to separate “we own a vault” from “we can prove secrets are rotated, offboarded, and reviewed at scale.” It also makes board-level reporting less vague, because progress can be tied to measurable operational capability instead of generic maturity claims. In practice, many security teams discover the real gap only after an audit or secrets incident exposes how little of the programme was actually repeatable.

How It Works in Practice

A Profile is the customised set of identity outcomes an organisation wants to achieve for a given scope, such as cloud workloads, contractors, privileged admins, or agents. A Tier is the maturity lens that asks how well the organisation can govern, measure, and sustain those outcomes. Used together, they stop IAM from becoming a one-size-fits-all checklist and instead turn it into an operating model with priorities.

In a practical IAM programme, teams typically start by defining a current-state Profile: where identities exist, how access is granted, how secrets are stored, how revocation works, and which reviews are actually happening. They then define a target Profile for the business context. For example, a regulated workload may require tighter lifecycle control, stronger segregation of duties, and faster offboarding than a low-risk internal app.

• Use Profiles to describe the controls that matter in a specific environment, not every possible control.
• Use Tiers to assess whether governance is ad hoc, repeatable, measured, or continuously improved.
• Map evidence to outcomes such as access review completion, rotation latency, and offboarding success.
• Compare human and non-human identity maturity separately, because the failure modes differ.

This is especially important for non-human identities. NHIs often rely on long-lived secrets, brittle automation, and inconsistent ownership, which makes a simple “policy exists” assessment misleading. NHI Management Group research on the Ultimate Guide to NHIs highlights how gaps in visibility, rotation, and offboarding create persistent exposure long after a system is provisioned. Tiers help expose whether the organisation can actually enforce those controls across platforms, while Profiles show which controls are non-negotiable for that workload. These controls tend to break down when identity data is fragmented across cloud consoles, CI/CD tooling, and local scripts because no single team can prove end-to-end ownership.

Common Variations and Edge Cases

Tighter Profiles often increase assessment overhead, requiring organisations to balance precision against the effort needed to maintain evidence. That tradeoff becomes visible when different business units want different identity outcomes or when platforms mature at different speeds. There is no universal standard for this yet, so current guidance suggests using Profiles as a governance anchor rather than a rigid compliance template.

One common edge case is a programme that scores highly on Tier but still has weak real-world outcomes. That happens when documentation is strong but telemetry is poor, or when reviews are performed but not acted on. Another is the reverse: a team may have solid operational discipline for one workload class but no consistent model across the enterprise. Profiles help prevent those situations from being blended together into a misleading average.

For non-human identities, the most useful variation is a separate Profile for service accounts, API keys, and autonomous agents, because their lifecycle and access behaviour differ materially. In environments with high secrets turnover, a maturity model that ignores revocation latency can look healthy while still leaving stale access in place. The Azure Key Vault privilege escalation exposure research is a good reminder that control design and effective enforcement are not the same thing.

Related resources from NHI Mgmt Group

• Why do privileged sessions still create risk in mature IAM programmes?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• What is the difference between human IAM controls and NHI governance?
• What does a mature secrets governance program need to cover?