They often treat exemptions as a convenience instead of a governed exception. A valid exemption needs a reason, a clear expiry, and a process that forces re-review. Without those boundaries, temporary exceptions turn into permanent control gaps that nobody owns.
Why This Matters for Security Teams
Separation of Duties exemptions are supposed to be narrow, documented exceptions, but teams often let them drift into routine access. That mistake matters because the exemption is usually masking a conflict that controls were designed to catch: payment approval plus vendor creation, production access plus change approval, or secret creation plus secret use. When the exception becomes normal operating practice, audit evidence gets weaker and accountability gets blurred. Guidance from the NIST Cybersecurity Framework 2.0 reinforces that access governance must be intentional, reviewable, and tied to risk rather than convenience.
The same pattern shows up in non-human identities, where exemptions are often granted for service accounts, API keys, or automation pipelines without a clean expiry path. NHIMG’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is exactly the kind of gap that turns an SoD exception into a standing control failure. In practice, many security teams encounter the abuse pattern only after an audit finding or incident has already exposed the missing owner.
How It Works in Practice
A defensible SoD exemption needs to function like a controlled exception, not a permanent waiver. The request should state the exact conflict being bypassed, the business justification, the compensating control, the approver, and the expiry date. The review should also ask whether the task can be redesigned so the exemption is no longer needed. For non-human identities, this is often where teams discover they are compensating for poor workload design rather than a true business exception.
In mature environments, exemption handling is tied to identity and access workflows, ticketing, and periodic recertification. For example, a pipeline account might need both deployment and rollback rights for a limited migration window, but the approval should require a clear end date and automatic revocation. That aligns with the broader governance model described in Ultimate Guide to NHIs, where lifecycle controls and visibility are treated as core security requirements, not after-the-fact cleanup.
- Define the conflict precisely, including which roles, systems, or workflows are being separated.
- Require a compensating control, such as dual approval, enhanced logging, or read-only monitoring.
- Set a hard expiry and link it to automated re-review before renewal.
- Track the exception to a named owner so accountability does not disappear.
- Revoke or redesign the access path when the business need ends.
Current guidance suggests that exemption review should be integrated with access governance and control validation, not handled as a one-time paperwork step. That matters because persistent exceptions distort the control environment and make recertification meaningless. These controls tend to break down when service accounts or CI/CD automation are allowed to renew access without human review, because the exception quietly becomes part of the operational baseline.
Common Variations and Edge Cases
Tighter SoD exception governance often increases operational friction, so organisations have to balance speed against control integrity. That tradeoff is real in change-heavy environments such as finance close, emergency production fixes, and automated release pipelines, where legitimate exceptions may be necessary but still dangerous if left open-ended.
One common edge case is emergency access. Best practice is evolving here, but the current consensus is that emergency elevation should be time-boxed, fully logged, and reviewed after the event, not converted into a standing exception. Another edge case is shared automation accounts, where teams incorrectly assume the absence of a person means SoD no longer applies. It still does, because the conflict may sit in the workflow, not the individual.
For high-volume non-human identity estates, exemption sprawl is especially risky because ownership is fragmented and review becomes stale. NHIMG’s Ultimate Guide to NHIs highlights how excessive privileges and weak offboarding combine into broad exposure, and those same conditions make SoD exceptions hard to retire. The practical test is simple: if nobody can explain why the exemption still exists, it is already overdue for revalidation.
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, CSA MAESTRO and OWASP Agentic AI 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 |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | SoD exemptions are an access-governance exception that needs review and accountability. |
| OWASP Non-Human Identity Top 10 | NHI-03 | NHI exemptions often mask over-privileged service accounts and stale credentials. |
| CSA MAESTRO | GOV-02 | Agentic and automated workflows need explicit governance for exception handling. |
| NIST AI RMF | AI RMF governance applies when automated systems create or rely on policy exceptions. | |
| OWASP Agentic AI Top 10 | A2 | Autonomous workflows can amplify exception misuse through unexpected tool actions. |
Require documented approval, periodic recertification, and revocation when the business need ends.
