A formal review process that evaluates proposed system or policy changes before they reach production. In identity and access environments, it helps prevent hidden access drift by requiring testing, approval, and rollback planning for changes that could affect who can access what.
Expanded Definition
A Change Advisory Board, or CAB, is a formal governance checkpoint that reviews proposed changes before they are released into production. In identity and access management, the CAB is not just a scheduling body. It evaluates whether a change could alter authentication paths, privilege boundaries, secret handling, token issuance, or account lifecycle controls. The practical value is control over blast radius, not bureaucracy for its own sake.
Definitions vary across vendors and ITIL-adjacent implementations, but the core discipline is consistent: changes should be tested, risk-rated, approved by accountable owners, and paired with rollback criteria. For NHI environments, that matters when a change touches service account permissions, CI/CD variables, certificate rotation, federation trust, or policy-as-code rules. Guidance from NIST change management guidance aligns closely with this approach.
The most common misapplication is treating the CAB as a paperwork step, which occurs when approvals happen after deployment decisions are already effectively final.
Examples and Use Cases
Implementing CAB discipline rigorously often introduces release latency, requiring organisations to weigh faster delivery against reduced change risk.
- A rotation job for API keys is reviewed before deployment because the new workflow changes which pipeline account can mint and revoke credentials.
- A policy update for role-based access control is paused for CAB review until the team verifies it will not widen access for dormant service accounts.
- A federation change is tested in staging because a broken trust relationship could silently disable machine-to-machine authentication across applications. This is especially relevant when teams track the secret exposure patterns described in the Ultimate Guide to NHIs.
- A certificate renewal pipeline is reviewed with rollback steps because expired or misissued certificates can interrupt production traffic and break dependent automations.
- An emergency privilege grant is escalated through CAB after-hours review so the team can restore service without leaving standing access behind.
Change review practices are also shaped by incident-response expectations in CISA cyber threat advisories, which repeatedly show how configuration changes can become attack paths when not validated.
Why It Matters in NHI Security
In NHI security, unmanaged change is one of the fastest ways to create invisible privilege drift. A seemingly routine update can expose secrets in logs, widen token scope, break revocation logic, or leave a service account with more access than the system owner intended. That is why CAB review becomes a governance control, not a project-management ritual. NHIMG notes that 97% of NHIs carry excessive privileges, which means change decisions often affect identities already operating with too much reach. The same research shows 96% of organisations store secrets outside secrets managers in vulnerable locations, making change reviews critical when pipelines, scripts, or configuration files are altered.
CAB processes matter most when paired with evidence: test results, owner sign-off, rollback instructions, and dependency mapping for downstream systems. Without that, teams may approve a change that looks narrow but actually impacts trust chains, secret distribution, or emergency access paths. Organisationally, the need for CAB often becomes obvious only after a failed deployment, an access outage, or an incident review reveals that the change process never evaluated who could still authenticate after the update.
Organisations typically encounter access drift only after a rollout, at which point CAB discipline 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 SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-5 | Change governance supports controlled supplier and internal system modifications. |
| NIST SP 800-63 | Identity assurance is impacted when changes affect authenticators, sessions, or federation. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Access and privilege changes are central to non-human identity governance. |
Route NHI-affecting changes through CAB to prevent privilege drift and undocumented access expansion.
