Conflict recertification is the repeated review of previously identified access conflicts to confirm whether they are still justified. It is used when risk, role structures, or business needs change over time. The process helps organisations avoid permanent exceptions and keeps SoD decisions current, documented, and defensible.
Expanded Definition
Conflict recertification is the periodic re-evaluation of an access conflict that was previously approved as an exception, usually because business needs, role mappings, or risk tolerance have changed. In NHI governance, this matters when service accounts, API keys, automation agents, or privileged workflows create Segregation of Duties tension that cannot be resolved once and forgotten. Unlike a one-time exception record, recertification asks whether the conflict remains necessary, whether compensating controls still work, and whether the same access would be justified today under current policy. Industry usage is still evolving, but the governing idea is consistent with formal access review practices described in the NIST Cybersecurity Framework 2.0, especially where authorisation decisions must be tracked and revalidated over time. NHI Management Group treats this as a control discipline, not an administrative reminder, because stale exceptions often become invisible entitlements. The most common misapplication is treating a prior conflict approval as permanent, which occurs when reviewers assume the underlying workflow, ownership, or compensating control has not changed.
Examples and Use Cases
Implementing conflict recertification rigorously often introduces review overhead and temporary operational friction, requiring organisations to weigh auditability and reduced risk against the cost of recurring approvals.
- A payroll automation service account previously allowed to approve journal entries is recertified after a finance system change, using the same logic that would now appear in the Ultimate Guide to NHIs — What are Non-Human Identities as part of lifecycle governance.
- An API key used by a deployment pipeline had write access to production logs for incident triage, but the team later recertifies the conflict because monitoring coverage now replaces that need.
- An AI agent with tool access to procurement data is reviewed quarterly to confirm that its exceptions still match the delegated approval model and do not exceed current policy boundaries.
- A legacy service account retained temporary dual-role access during a merger. The conflict is recertified after role consolidation, then either reapproved with compensating controls or removed.
- A security team uses findings from the Sisense breach to justify a broader recertification campaign for long-lived exceptions that were never revisited after initial approval.
In each case, the key question is not whether the conflict once made sense, but whether the current business process still requires it under today’s controls and threat model.
Why It Matters in NHI Security
Conflict recertification matters because NHI exceptions often outlive the conditions that justified them. That is especially dangerous in environments where privileges accumulate quietly and ownership becomes unclear. NHI Management Group research shows that 97% of NHIs carry excessive privileges, which means exception creep is not a niche problem but a common exposure pattern. When conflicts are never rechecked, organisations can end up with permanent Segregation of Duties bypasses embedded in service accounts, CI/CD identities, and machine-to-machine workflows. That weakens auditability, complicates incident response, and makes it harder to prove that access decisions remain defensible. The operational lesson aligns with NIST Cybersecurity Framework 2.0 expectations around access governance and review. It also supports the broader visibility and lifecycle discipline described in the Ultimate Guide to NHIs — What are Non-Human Identities. Organisations typically encounter the real cost only after an audit finding, privilege abuse, or production incident exposes that an exception had been active long after its original justification expired.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 | Recurring review of NHI exceptions aligns with access governance and privilege drift controls. |
| NIST CSF 2.0 | PR.AA-01 | Identity and access decisions must be reviewed and maintained as conditions change. |
| NIST Zero Trust (SP 800-207) | AC-1 | Zero Trust requires continuous verification, not one-time exception approval. |
| NIST SP 800-63 | IAL2 | Assurance principles support periodic revalidation of authoritative access decisions. |
| CSA MAESTRO | Agentic systems need recurring governance checks when delegated actions create SoD tension. |
Treat every conflict exception as time-bound and reauthorise it against current trust conditions.
Related resources from NHI Mgmt Group
- What is the difference between access recertification and access provisioning?
- Who is accountable when a SoD conflict leads to fraud or compliance failure?
- Who is accountable when an SoD conflict is missed in an audit or incident?
- What breaks when non-human identities are not included in recertification?
