Subscribe to the Non-Human & AI Identity Journal
Home FAQ Governance, Ownership & Risk How should security teams handle SoD violations that…
Governance, Ownership & Risk

How should security teams handle SoD violations that cannot be remediated?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated June 24, 2026 Domain: Governance, Ownership & Risk

They should treat them as formal risk acceptances with documented mitigation, not as unresolved exceptions. That means assigning an owner, a justification, a validity period, and a review process. If the conflict stays active in production, the organisation needs evidence that the risk is monitored and periodically revalidated rather than simply tolerated.

Why This Matters for Security Teams

Segregation of Duties violations are often treated like paperwork problems, but when the conflict cannot be remediated, it becomes a durable control gap that affects fraud, abuse, and operational resilience. The right response is not to ignore the exception or leave it open indefinitely. It is to convert the issue into a managed risk decision with clear ownership, compensating controls, and a scheduled review cycle aligned to the organisation’s risk appetite and governance model.

This matters because unresolved SoD conflicts tend to sit in the same identity and privilege pathways that already create exposure in NHIs. NHI Management Group research shows that 97% of NHIs carry excessive privileges and 91.6% of secrets remain valid five days after notification, which illustrates how slowly identity risk can be corrected in real environments. That pattern is visible in incidents such as the Schneider Electric credentials breach, where identity compromise becomes operationally consequential once access paths are left over-extended. In practice, many security teams encounter SoD violations only after audit findings, incident review, or privilege review has already shown the control failed to stop a harmful combination of access.

For teams mapping this into broader governance, NIST Cybersecurity Framework 2.0 provides a useful structure for documenting ownership, monitoring, and continuous improvement, but it does not remove the need for a formal risk decision when remediation is not technically possible.

How It Works in Practice

When an SoD conflict cannot be removed, the control objective shifts from elimination to controlled tolerance. Security teams should document the violation as a formal risk acceptance, not as an open exception, and tie it to specific compensating measures. That usually means separating approval authority from execution authority through workflow checks, applying enhanced logging, and requiring independent review of the affected transactions or administrative actions.

A practical response also needs lifecycle discipline. The accepted risk should have an owner, a business justification, a validity period, and a review trigger. If the conflict affects a service account, API key, or automation identity, the team should align the approval to the identity lifecycle, not just the application ticket. This is where NHI governance becomes important. The Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a warning sign that exception handling often outruns identity hygiene.

  • Record the SoD conflict in the risk register with control owner, approver, and expiry date.
  • Apply compensating controls such as dual approval, transaction monitoring, and periodic access recertification.
  • Link the risk acceptance to evidence, including logs, reviews, and remediation milestones.
  • Escalate to governance if the conflict remains in production beyond the review window.

Where identity evidence is incomplete, the New York Times breach is a reminder that overlooked access paths can become persistent exposure points. These controls tend to break down when the SoD conflict is embedded in a legacy process or shared automation account because no single system owner can fully redesign the workflow.

Common Variations and Edge Cases

Tighter SoD enforcement often increases operational friction, so organisations must balance control purity against business continuity. That tradeoff becomes especially visible in legacy ERPs, emergency break-glass processes, and automated service workflows where one identity must both trigger and complete a task. Current guidance suggests these cases should be handled through temporary approvals and stronger monitoring, but there is no universal standard for every environment.

For NHIs, the edge case is usually not a human policy override but an automated process that cannot be split cleanly. In those situations, security teams should prefer short-lived authorization, narrow scope, and independent validation of output over broad permanent entitlements. If the conflict is caused by a third-party integration, the review should also include the vendor, because NHI exposure often extends beyond internal systems. The governance question becomes whether the residual risk is acceptable for a bounded period, not whether the conflict can be ignored.

Best practice is evolving, but the practical rule is stable: if remediation is impossible, the organisation must be able to show why the exception exists, who accepted it, what reduces the risk, and when it will be reconsidered. When those answers are missing, the SoD violation is no longer a controlled exception, it is unmanaged privilege drift.

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.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03SoD exceptions often persist because NHI credentials are over-privileged or poorly rotated.
NIST CSF 2.0PR.AC-4SoD risk acceptance depends on controlled access, monitoring, and periodic revalidation.
NIST AI RMFRisk governance and accountability are needed when automation or AI-driven workflows cannot be remediated.

Review NHI entitlements, reduce scope, and enforce rotation or revocation for identities tied to unresolved SoD risk.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org