Approval should come from someone outside the operational path that requested or granted the access. The exception should be time-bound, documented, and separately reviewable so it does not become a permanent bypass. Independence matters more than speed when the control is meant to prevent conflicted authority.
Why This Matters for Security Teams
Segregation of duties is supposed to stop one person or one workflow from creating, approving, and benefiting from the same privileged action. The moment exceptions and temporary overrides are approved by the same operational chain, the control becomes a formality. That is especially dangerous for NHIs, where a service account, API key, or workflow token can act far faster than any human review cycle.
The practical risk is not only abuse, but also drift. temporary access often becomes standing access, and emergency bypasses tend to outlive the incident that justified them. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which helps explain why exception handling needs stronger oversight than routine access grants. Current guidance from the OWASP Non-Human Identity Top 10 also treats privilege creep and weak governance as recurring failure modes.
In practice, many security teams encounter SoD failure only after a temporary override has already been reused in production or quietly extended beyond its original purpose.
How It Works in Practice
The safest approval model is simple: the request is made by the operational owner, but the approval is given by an independent reviewer who does not sit in the same execution path. That reviewer is often from security, risk, platform governance, or a separate control owner function. The key requirement is independence, not organisational title.
For NHIs and agentic workflows, the approval should be bound to a specific scope, duration, and reason. That means defining what system, secret, role, or token is affected; when the override starts and expires; and what compensating controls apply while it is active. A strong pattern is to issue short-lived access aligned to NHI risk, then require automatic revocation and post-approval review. This aligns with the intent of OWASP NHI guidance, which emphasises lifecycle control, least privilege, and monitoring.
- Use an independent approver outside the requesting team and outside the granting team.
- Set an explicit expiry time for every exception or temporary override.
- Document the business reason, affected identity, and compensating controls.
- Log approval, activation, extension, and revocation as separately reviewable events.
- Require re-approval for any extension, even if the original issue persists.
For higher-risk access, a two-step approval can be appropriate, such as one operational sign-off and one control sign-off. Where organisations use PAM or workflow automation, the approver should validate the context at request time, not rely on a standing role assignment. These controls tend to break down in 24/7 operations and emergency change windows because the same on-call group is often asked to both request and approve the exception.
Common Variations and Edge Cases
Tighter approval controls often increase friction during incidents, requiring organisations to balance rapid recovery against separation of authority. That tradeoff is real, especially when production outages, security containment, or third-party support access cannot wait for a full review cycle.
Best practice is evolving for automated systems and AI agents, because the approval may need to cover not just a human user but an autonomous workload that can chain tools or escalate privileges unpredictably. In those cases, current guidance suggests pairing independent approval with workload identity, runtime policy checks, and time-bound credentials rather than granting broad standing access. Where the exception is for a break-glass account, the approver should still be separate from the person who activates it, and the account should be monitored more aggressively than normal privileged access.
Some organisations allow the same business unit to request and attest, but not approve, if a separate risk or security function owns the final decision. That is acceptable only when the approver can genuinely challenge the request and enforce expiry. NHIMG’s 52 NHI Breaches Analysis reinforces how quickly unchecked privileged paths become incident paths. The right question is not who can move fastest, but who can deny or narrow the request when the business case is weak.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses excessive and unreviewed NHI privilege, which makes SoD exceptions risky. |
| NIST CSF 2.0 | PR.AA-01 | Identity and access governance supports controlled approval of temporary access. |
| NIST AI RMF | GOVERN | Governance is needed when autonomous systems request or consume privileged overrides. |
Require independent approval, time limits, and revocation checks for every NHI exception.
