Access certification verifies whether people still need the access they have. Segregation of duties analysis checks whether those entitlements create toxic combinations that could enable fraud, errors, or misuse. Certification answers whether access should exist at all, while SoD analysis answers whether the remaining access creates an unacceptable control conflict.
How access certification differs from segregation of duties analysis
access certification and segregation of duties analysis are both access governance controls, but they answer different questions. Certification is a review of whether access should remain assigned to a person, usually based on role, job need, or ownership. SoD analysis is a conflict check on whether the access that remains creates an unacceptable combination of entitlements.
That distinction matters because certification can approve access that still produces risk. A reviewer may confirm that someone needs invoice approval rights, for example, while SoD analysis flags that the same person should not also be able to create vendors or post payments. One control is about entitlement necessity, the other is about entitlement compatibility.
In practice, certification is often person-centered and entitlement-by-entitlement, while SoD is workflow- and control-centered. Certification asks whether the access is still justified for this user or account. SoD asks whether the full set of entitlements lets one actor initiate, approve, modify, and conceal a sensitive transaction without independent checks.
- Ultimate Guide to NHIs helps anchor the broader governance view of access review, lifecycle control, and excessive privilege.
- Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs is useful when access certification is part of recurring recertification and revocation workflows.
- Ultimate Guide to NHIs, Key Challenges and Risks is a good companion for understanding why excessive permissions and weak visibility make both controls harder to operate well.
Where each control fits in an access governance program
Certification is the control you use to remove stale, unnecessary, or orphaned access. It is concerned with ownership, attestation, and periodic validation. SoD analysis is the control you use to prevent a valid access set from becoming a control failure, especially in finance, procurement, production change, privileged administration, and other high-impact workflows.
That is why the two controls are complementary rather than interchangeable. Certification can tell you an entitlement is no longer needed and should be revoked. SoD can tell you that even a legitimately needed entitlement must be constrained, split across roles, or offset by compensating controls because the combination creates too much authority in one place.
In mature programs, certification often sits upstream of SoD. You first remove access that is no longer required, then assess the remaining access for toxic combinations. If you reverse that order, you risk preserving unnecessary access while spending effort analysing entitlements that should have been removed outright.
At scale, the difference becomes operationally important. Certification workloads grow with user and account counts, while SoD analysis grows with the number of roles, entitlements, and transaction paths. The more complex the environment, the more important it becomes to define which conflicts are hard blocks, which are exceptions, and which need compensating monitoring rather than outright denial.
What practitioners should verify before trusting either control
What to verify: For certification, verify that reviewers are the real business owners of the access being attested, and that they can see the full entitlement set, not just a partial list. For SoD, verify that the rule set reflects actual business transactions, not a generic policy template that misses the combinations most likely to cause fraud or operational misuse.
Common mistake: Teams often treat certification as if it automatically solves SoD. It does not. A clean attestation does not prove that the remaining access is safe in combination, and a passed SoD check does not prove that the access is still needed. You need both questions answered separately.
What good looks like: Certification removes obsolete access on a fixed cadence, SoD rules are tied to meaningful business processes, and exception handling is explicit. The strongest programs also track whether exceptions are temporary, whether compensating controls are actually operating, and whether the same conflict keeps reappearing because the underlying role design has not been fixed.
Practitioner takeaway: Treat certification as an entitlement validity control and SoD as a control-conflict control, because the governance failure modes are different and the remediation decisions should be different too.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Covers access governance, least privilege, and account review decisions for entitlements. |
| Recommendation — Review and remove unnecessary access, then enforce least-privilege role design. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions Management | Directly supports periodic review and management of access permissions. |
| GV.RM-03 — Risk Response | Supports exception handling when SoD conflicts require compensating controls or acceptance. | |
| GV.OC-01 — Organizational Context | Supports aligning access governance rules with business process ownership and transaction risk. | |
| Recommendation — Define review cadences and revoke permissions that are no longer justified. Document and approve compensating controls for unresolved access conflicts. Map access review ownership to the business process that creates the entitlement risk. | ||
| ISO/IEC 42001:2023 | A.5.2 — AI system roles and responsibilities | Not included |
Related resources from NHI Mgmt Group
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between RBAC and segregation of duties in healthcare access governance?
- What is the difference between segregation of duties and policy-based access control in financial governance?
- What is the difference between static access governance and continuous identity-first security?
