Policy assurance for access governance: why roles are not enough

At a glance

What this is: This is an analysis of why access policy design often breaks down in complex enterprises and why effective identity governance depends on policy assurance, not just policy administration.

Why it matters: It matters because IAM, IGA and audit teams need controls that work across human and non-human identities, application change, and SoD risk, not just clean role records.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read SafePaaS's analysis of policy assurance for identity governance

Context

Access policy only works when the organisation can turn intent into enforced decisions across applications, identities and business processes. In practice, that means the policy must follow role changes, segregation-of-duties rules, review cycles and evidence requirements, including where non-human identities are executing business tasks.

The primary governance gap here is not policy definition. It is policy assurance, which is the ability to show what access actually exists, whether risky combinations were blocked, and whether exceptions were removed or formally accepted. That problem becomes harder when identity governance has to cover both workforce access and non-human identity access in the same control model.

For IAM and audit leaders, the real test is whether governance reaches the material applications where money moves, data changes and exceptions accumulate. A policy that cannot survive role proliferation, application sprawl and outside-the-platform access is only a statement of intent.

Key questions

Q: How should security teams prove that access policy is actually enforced?

A: They should require evidence that each request was checked against policy rules, reviewed with the right context and either approved, denied or remediated in a traceable workflow. The key test is whether the control shows effective privileges and conflict outcomes, not just that the policy exists on paper.

Q: Why do role-based models break down in complex enterprises?

A: Role-based models break down when role names no longer describe the actual access underneath them. Copying, privilege creep and local exceptions produce broad or inconsistent entitlements that reviewers cannot interpret safely. The result is role proliferation, hidden SoD conflict and weak assurance.

Q: What should organisations do when access spans multiple systems and business units?

A: They should govern access at the entitlement and process level, then apply the same policy across systems, entities and approval paths. That approach lets teams compare cross-system combinations, apply consistent risk thresholds and keep exceptions visible when access changes outside one central platform.

Q: How do IGA teams know whether their programme is producing real control value?

A: They know it is working when fewer risky combinations reach production, access reviews show effective privileges, exceptions are closed or accepted with a mitigation, and audit evidence is generated automatically from the workflow. If the programme only counts certifications completed, it is measuring activity rather than control.

Technical breakdown

Policy administration versus policy assurance

Policy administration records the intended rule set: who may request what, which approvals are needed, and which roles or privileges should be allowed together. Policy assurance is the evidence that those rules were translated into effective privileges, enforced at the right time, and retained in a defensible record. The difference matters because role names often conceal real access, especially when copied roles, inherited privileges and local application exceptions accumulate across the estate.

Practical implication: treat policy assurance as the control objective, not role documentation.

Effective privileges beneath role labels

A role is only a packaging mechanism. The actual governance problem sits below the label, where entitlements, SoD conflicts and cross-system combinations define what the identity can really do. In mature environments, two similar role names can produce very different access paths, while two different roles can create the same financial or operational conflict. That is why entitlement-level visibility is central to continuous compliance.

Practical implication: review effective access, not just assigned roles.

Continuous SoD and evidence generation

Segregation of duties works when conflicts are checked before access is granted, then re-evaluated when roles, systems or legal entities change. Evidence has to be created as part of the workflow, including the request, conflict result, reviewer decision and any mitigating control. Without that closed loop, the organisation can describe its policy but cannot prove that it prevented risky combinations or removed them in time.

Practical implication: make SoD checks and evidence capture part of every access change.

Threat narrative

Attacker objective: The objective is to obtain and use access combinations that let an identity influence sensitive business processes without effective segregation or evidence.

1. Entry occurs when excessive or poorly governed access is granted through copied roles, local exceptions or outside-the-platform entitlements.
2. Escalation follows when conflicting privileges are combined inside a single identity or across systems, letting an actor move from routine access to high-risk business actions.
3. Impact is realised when inappropriate access is used to influence payments, journals, approvals or other financially material processes without timely detection or remediation.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Policy assurance is the real control objective, not policy administration. Recording what the organisation intends to permit is necessary, but it is not governance. If the platform cannot prove effective privileges, conflict checks, approvals and remediations across the applications that matter, it is managing intent rather than access. Practitioners should judge IGA by the quality of its assurance trail, not by how many identities it can register.

Role names are too coarse to carry compliance risk decisions. The article correctly separates a role label from the privileges hidden beneath it. In enterprise governance, copied roles, inherited privileges and local exceptions create a false sense of clarity, while the real risk sits at entitlement level. The implication is straightforward: auditors and security teams need access views that show what an identity can actually do, not what a catalogue says it should mean.

Segregation of duties only works as a continuous control. SoD that is checked only at request time or review time misses the way enterprise access changes in motion. The governance value comes from rechecking conflicts when role, process or entity boundaries change, then forcing documented removal or acceptance of the conflict. Continuous compliance is not a reporting exercise; it is the mechanism that keeps financial processes from accumulating invisible risk.

Non-human identities now sit inside the same governance problem space as workforce access. The article explicitly notes that policy must continue working when non-human identities begin performing business activities, and that is the point where many IGA programmes stop being sufficient. Once service accounts, bots or AI agents execute process steps, policy cannot stop at human role design. Practitioners should extend governance to the full identity estate or accept a partial control model.

Coverage is the difference between governance and theatre. A policy framework that covers only some ERPs, some SaaS applications or only centrally managed identities will always produce a good story for part of the estate and a weak story everywhere else. The practical conclusion is that governance scope, not feature count, determines whether identity controls can support audit, enablement and change at enterprise scale.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• From our research: 92% of organisations expose NHIs to third parties, according to the Ultimate Guide to NHIs.
• From our research: The NHI Lifecycle Management Guide shows how provisioning, rotation and offboarding need to work together when non-human access becomes part of governance scope.

What this signals

Governance coverage is now a control variable, not a reporting metric. As more organisations push automation and non-human execution into finance and operations, access policy has to reach the applications where those identities actually act. The practical shift is from managing role inventories to managing coverage, because incomplete scope creates a control gap even when the policy design is sound.

Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. That number explains why entitlement-level governance keeps surfacing as an audit and risk problem. Teams that cannot see the full machine identity estate cannot reliably certify access, contain privilege creep or prove that policy is being enforced consistently.

The next maturity step is to correlate policy, entitlement and evidence across human and non-human identities in the same operating model. That is where NHI Lifecycle Management Guide becomes operationally relevant, because lifecycle discipline is what keeps governance from stopping at provisioning and forgetting revocation, rotation and offboarding.

For practitioners

• Map policy to effective privileges Build access views that show the entitlements and cross-system combinations behind each role so reviewers can see actual exposure, not just labels.
• Move SoD checks into the request path Check conflicts before provisioning, then re-evaluate them when roles, applications or legal entities change so toxic combinations cannot drift into production.
• Treat evidence as a workflow output Capture the request, policy result, approver rationale, mitigation and remediation in the same trace so audit evidence is produced automatically.
• Extend governance to non-human identities Include service accounts, bots and AI agents in the same policy framework as workforce access so process ownership does not disappear when the actor is non-human.
• Prioritise material application coverage Start with the ERP, finance and SaaS systems that move money or sensitive data, then expand governance to legacy and locally managed applications.

Key takeaways

• Policy only becomes governance when it can prove effective privileges, conflict checks and remediation across the real application estate.
• Role names are too abstract to carry risk decisions on their own, especially when entitlement creep and local exceptions hide the true access path.
• Continuous SoD, closed-loop evidence and non-human identity coverage are the controls that separate real assurance from administrative intent.

Key terms

• Policy Assurance: Policy assurance is the proof that an access rule was enforced as intended across real systems, not just written down. It includes effective privilege views, approval outcomes, exception handling and remediation evidence that can survive audit scrutiny.
• Effective Privilege: Effective privilege is the real access an entity can exercise after inheritance, delegation, token scope, and connected-system trust are applied. It is often broader than the permissions shown in an identity repository, which is why runtime validation matters.
• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Governance Coverage Drift: Governance coverage drift is the gap between the access estate an organisation believes it controls and the access estate actually present across applications and identities. It emerges when discovery is incomplete, integrations lag, or review data does not reconcile cleanly to real entitlements.

What's in the full article

SafePaaS's full article covers the operational detail this post intentionally leaves for the source:

• Platform-specific guidance on turning policy rules into access decisions across ERP and SaaS environments.
• Examples of how federated governance layers coexist with existing IAM, IGA and ITSM tooling.
• Customer case details showing how coverage, fulfilment time and audit findings changed in practice.
• Decision criteria for choosing between centralised IGA, ERP-native GRC and federated policy-based governance.

👉 SafePaaS's full article covers the entitlement-level controls, SoD logic and coverage questions in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity governance programme, it is worth exploring.