The three lines of defence is a governance model that separates operational execution, independent risk challenge, and internal audit. In AML, it helps avoid conflicts of interest by making it clear who performs checks, who questions decisions, and who independently validates whether controls are working.
Expanded Definition
Three lines of defence is a governance model that divides accountability into three distinct roles: operational ownership, independent risk oversight, and internal audit. In anti-money laundering and broader control environments, the model reduces self-review risk by separating execution from challenge and assurance.
In NHI security, the same structure can help clarify who owns service account hygiene, who reviews exceptions such as shared secrets or delayed rotation, and who independently verifies whether controls actually work. The model is not a technical control by itself; it is an operating model that shapes how identity risk decisions are made and reviewed. Its practical value depends on clear authority boundaries, documented escalation paths, and evidence that each line can act without undue influence. Definitions vary across vendors when the model is applied to cloud, IAM, or AI governance, so teams should treat it as a governance pattern rather than a fixed compliance checklist. NIST’s NIST Cybersecurity Framework 2.0 aligns with the same separation of accountability through governance, protection, and assurance outcomes.
The most common misapplication is treating the first and second lines as the same control owner, which occurs when security reviewers approve their own exceptions.
Examples and Use Cases
Implementing three lines of defence rigorously often introduces slower decision cycles, requiring organisations to weigh stronger challenge and independence against the cost of added review steps.
- The first line owns NHI lifecycle tasks such as provisioning, secret rotation, and decommissioning for application identities.
- The second line reviews policy exceptions, such as service accounts that cannot meet standard rotation windows, and challenges whether compensating controls are sufficient.
- The third line samples evidence to confirm that rotation logs, vault settings, and access reviews are occurring as documented, rather than relying on self-attestation.
- In a regulated environment, the model can separate AML transaction monitoring operations from the team that approves control exceptions and from the audit function that tests those approvals.
- For identity programs, the approach is often paired with Ultimate Guide to NHIs guidance on lifecycle governance and with NIST Cybersecurity Framework 2.0 control mapping to keep ownership and assurance distinct.
In practice, the model works best when each line has a written mandate and evidence requirements that differ from the other two. That separation becomes especially important where secrets, API keys, and service accounts are embedded in pipelines or infrastructure as code.
Why It Matters in NHI Security
Three lines of defence matters because NHI failures often become governance failures before they become technical failures. When the same team provisions a workload identity, approves the exception to keep it static, and later certifies that the control is effective, risk can go unchallenged until an incident exposes the gap. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, and 71% are not rotated within recommended time frames, which makes independent oversight critical when exceptions start to accumulate. The issue is not just whether a secret exists, but whether there is a separate function empowered to question why it exists, how long it remains valid, and whether the control design still matches the threat model. The Ultimate Guide to NHIs and NIST’s NIST Cybersecurity Framework 2.0 both reinforce the need for governance that separates operation from oversight.
Organisations typically encounter the weakness only after a secrets leak, access review failure, or audit finding, at which point three lines of defence becomes operationally unavoidable to address.
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 CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV | Separates governance, oversight, and assurance roles across cybersecurity operations. |
| NIST CSF 2.0 | GV.RM | Risk management requires independent challenge of decisions and exceptions. |
| OWASP Non-Human Identity Top 10 | NHI-10 | Governance gaps around ownership and oversight amplify NHI misuse and weak accountability. |
Assign distinct owners for execution, review, and audit evidence to avoid self-approval.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
