Federated identity access governance and the NHI control gap

At a glance

What this is: This is an analysis of federated identity access governance and how it applies to joiners, movers, leavers, and NHI accounts.

Why it matters: It matters because IAM teams need governance models that scale beyond human users and preserve evidence, ownership, and policy enforcement for NHI risk.

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 federated identity access governance and NHI control

Context

Federated identity access governance is a control model for deciding who gets access, who approves it, and how evidence is preserved when access changes. The NHI governance problem appears when the same model is stretched across service accounts, API keys, bots, and AI-related identities that do not fit human-centric approval flows or periodic review cycles.

The source article describes a common enterprise gap: formal IAM structure on paper, but slow joiner access, risky mover changes, orphaned leaver accounts, and unclear ownership for machine identities in practice. That gap is typical, not exceptional, because central teams often end up routing work instead of enforcing policy across the full identity lifecycle.

Key questions

Q: How should security teams govern non-human identities in federated access models?

A: Security teams should treat non-human identities as governed accounts with named ownership, policy checks, and offboarding requirements, not as technical leftovers. The practical model is to place service accounts, API keys, bots, and AI-related identities inside the same lifecycle controls used for human access, then enforce approvals, logging, and periodic reassessment through a central control layer.

Q: Why do service accounts create so much access governance risk?

A: Service accounts create risk because they often accumulate standing privilege, lack a durable owner, and survive long after the workflow or application that created them has changed. That combination makes it hard to prove why access exists, when it should be removed, or whether it still matches the business purpose.

Q: What breaks when movers keep inherited access after a role change?

A: When movers keep inherited access, segregation of duties can collapse quietly. The organisation may still show a valid approval trail, but the user now holds a new combination of permissions that opens paths for fraud, unauthorized changes, or audit findings. The breakage is usually discovered too late, after the role change has already affected production or finance processes.

Q: How do organisations prove access governance is working during audit?

A: Organisations prove governance is working by showing that every access decision has a policy basis, an accountable approver, and a complete evidence trail. Auditors care less about the number of approvals than about whether access was reviewed at the right time, by the right owner, with any exceptions documented and remediated.

Technical breakdown

How federated identity access governance separates policy from execution

Federated identity access governance uses one layer to define policy and another to execute decisions. The central layer sets rules for high-impact access, segregation of duties, and risk thresholds, while local business owners make the context-aware approval decision. That separation matters because application-native admin tools usually lack the cross-system view needed to judge enterprise risk consistently. The architecture works only when the control layer can evaluate access continuously, generate evidence, and enforce policy across ERP, SaaS, cloud, and AI-connected systems without becoming the system of record for identities itself.

Practical implication: treat governance as an independent control plane, not a collection of workflow approvals.

Joiner, mover, leaver controls and the NHI lifecycle

Joiners, movers, and leavers describe the identity lifecycle, but the hard part is maintaining control when access changes faster than review cycles. Joiner requests need policy-based routing, mover events need automated re-evaluation of role combinations, and leaver events need reconciliation against authoritative sources to remove lingering access. NHI governance extends this lifecycle to service accounts and bots, which often have no clean HR owner or obvious offboarding trigger. Without lifecycle coverage, access control becomes reactive and leaves residual privilege in place long after the business need has ended.

Practical implication: extend lifecycle controls to non-human identities, not just employees and contractors.

Why auditability breaks when ownership is unclear

Auditability depends on being able to show who requested access, who approved it, what policy was applied, and what evidence was preserved. In federated models, that chain fails when ownership is diffuse, approvals are buried in tickets, or exceptions are handled outside the control layer. For NHIs, the issue is sharper because machine accounts can be created by engineering teams, used by operations, and forgotten by both. Clear ownership is not a documentation exercise; it is a control requirement that determines whether compensating controls, emergency access, and periodic reviews can actually be tested.

Practical implication: make ownership and evidence immutable parts of the access workflow.

Threat narrative

Attacker objective: The attacker objective is to exploit persistent identity sprawl to gain durable access through weakly governed human and non-human accounts.

1. Entry occurs when service accounts, API keys, or bots are provisioned without clear ownership or lifecycle review, creating persistent access that outlives the business need.
2. Escalation follows when mover events or inherited roles accumulate into toxic combinations that grant broader reach across ERP, SaaS, or cloud systems.
3. Impact is unauthorized access, delayed remediation, and repeat audit findings because the organisation cannot prove who approved what or why.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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

NHI Mgmt Group analysis

Federated identity access governance is now an NHI problem, not just an IAM process problem. The source article correctly frames governance as a control model, but the real pressure point is the explosion of service accounts, bots, and AI-related identities that live outside human lifecycle assumptions. Once those identities start carrying business-critical privilege, the access model must account for ownership, rotation, and offboarding as first-class controls. Practitioners should treat NHI coverage as part of governance architecture, not a side issue.

Continuous evidence matters more than periodic approval theatre. Quarterly reviews and spreadsheet sign-offs do not tell auditors or security teams whether access was appropriate when it mattered. The stronger model is policy evaluation at the point of change, with an immutable record of who decided, against what rule, and with what exception. That shift reduces the gap between formal control and operational reality, which is where most audit findings begin.

Identity blast radius is the right concept for this operating model. When movers accumulate access or when leavers retain dormant entitlements, the problem is not merely excess privilege, it is the size of the damage area that any single account can create. Federated governance helps narrow that blast radius by forcing policy checks close to the change event. Practitioners should measure governance by how quickly they can constrain blast radius after role or ownership changes.

Machine identity ownership is the most underdeveloped part of enterprise governance. Service accounts and bots often inherit privilege from the teams that deploy them, not from a durable accountable owner. That is structurally weak because operations, development, and audit all need a single answer to the question of who can revoke access. Organisations should formalise NHI ownership before they try to automate more approvals.

Automation only helps when the underlying policy model is coherent. Routing requests faster through a broken control design simply accelerates bad decisions. Federated governance works when policy definitions, approval authority, and evidence generation are aligned, and it fails when any one of those layers is left vague. Practitioners should use automation to enforce clarity, not to hide ambiguity.

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: 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• To go deeper: Read NHI Lifecycle Management Guide for provisioning, rotation, and offboarding controls that support federated governance.

What this signals

Federated governance will keep failing in organisations that treat NHI ownership as optional. The control model only scales when teams can answer who owns each account, who can revoke it, and what evidence proves the decision was legitimate at the time it was made.

Identity blast radius: this is the operational measure practitioners should watch as role changes, service accounts, and AI-related identities multiply. If access changes create more reach than the business process requires, then the governance model is not constraining risk, only documenting it.

With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, the same governance pattern now applies to autonomous systems. Teams should prepare for access reviews, approval chains, and offboarding processes that explicitly include machine actors, not just people.

For practitioners

• Map NHI ownership into the access lifecycle Assign a named business or technical owner for every service account, API key, bot, and AI-related identity, then require that owner to participate in approval and offboarding decisions. The goal is to eliminate orphaned identities and make revocation possible when projects, roles, or integrations change.
• Move access approvals to policy-based routing Route joiner, mover, and leaver decisions through a control layer that applies policy before the application grant happens. Use the same process to flag segregation-of-duties conflicts, elevated access, and exceptions so approvals are consistent across ERP, SaaS, and cloud systems.
• Build continuous evidence for audit and review Record the request, approval, policy result, exception status, and revocation trail in a system that auditors can inspect without relying on screenshots or tickets. Continuous evidence is especially important for NHI accounts because their owners and purposes change faster than periodic review cycles.

Key takeaways

• Federated identity access governance only works when policy, approval authority, and evidence are separated and testable.
• NHI accounts make governance harder because ownership, lifecycle, and offboarding are often undefined or inconsistent.
• Practitioners should move from periodic access cleanup to continuous control of joiners, movers, leavers, and machine identities.

Key terms

• Federated Identity Access Governance: A control model that separates access policy from access execution. Central teams define rules, risk thresholds, and evidence requirements, while business owners make context-aware decisions inside those guardrails. The model is designed to scale across applications, processes, and identity types without losing auditability.
• Identity Blast Radius: The amount of damage an identity can cause if its access is misused, stale, or overextended. In NHI governance, blast radius is shaped by privilege, ownership, lifecycle discipline, and how quickly access can be constrained after a role or project change.
• Machine Identity Ownership: The assignment of accountable responsibility for a service account, API key, bot, or AI-related identity. Ownership is not the same as technical creation. It means someone can approve, review, rotate, and revoke the identity when the business purpose changes or ends.
• Continuous Access Evidence: A persistent record showing why access was granted, who approved it, which policy applied, and what happened when the access changed. Continuous evidence is stronger than periodic screenshots because it ties control decisions to actual lifecycle events and supports audit testing directly.

Deepen your knowledge

Federated identity access governance and NHI lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for service accounts, bots, and AI-related identities, it is worth exploring.

This post draws on content published by SafePaaS: federated identity access governance and how it works in day-to-day operations. Read the original.