What breaks when the same team can approve and certify access?

Why This Matters for Security Teams

When the same team can approve and certify access, the control no longer has an independent check. The workflow may still show a request, a review, and a sign-off, but segregation of duties is functionally gone if the same people can influence the grant and later validate it. That creates self-attestation, weakens evidence quality, and makes access reviews far less useful for detecting over-provisioning, toxic combinations, or policy drift.

This is especially dangerous for non-human identities, where entitlement sprawl is already common. NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, and only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs. If certification is performed by the same function that owns the grant path, those numbers are harder to challenge and easier to normalise. The issue is not just audit hygiene. It affects blast radius, incident response confidence, and whether exceptions are actually being enforced. Current guidance from the OWASP Non-Human Identity Top 10 treats excessive privilege and weak governance as primary risk drivers, not paperwork defects.

In practice, many security teams discover the problem only after an entitlement review becomes a rubber stamp and a finding surfaces during audit or an access incident.

How It Works in Practice

The practical failure point is control independence. Access approval, provisioning, logging, and certification should not sit under the same decision-maker or the same operational team without a compensating control. When one team can both grant access and later certify that access as appropriate, the review loses objectivity. That matters even more for service accounts, API keys, and other NHIs because their permissions often outlive the human context that created them.

Security teams usually break this into three separate functions: request fulfilment, control ownership, and periodic recertification. A request may be approved by an application owner, provisioned by an IAM or platform team, and certified by an independent control owner or business risk owner. For NHIs, the review should cover the workload, the secret or token type, the effective privileges, the rotation interval, and whether the access is still needed for the task. NHI Mgmt Group’s Key Challenges and Risks guidance highlights how poor visibility and long-lived credentials make this harder to verify after the fact.

• Use separate approvers and certifiers for the same entitlement class.
• Record who requested, who approved, who provisioned, and who certified.
• Require evidence that certification used current usage data, not just a static roster.
• For NHIs, tie review to workload identity, secret TTL, and recent activity.

Where possible, align review logic with policy-as-code and runtime checks so the certifier is validating actual state, not a spreadsheet. Emerging practice also points to privileged access workflows and zero trust style verification, but there is no universal standard for this yet. These controls tend to break down in small platform teams and fast-moving DevOps environments because the people who own the infrastructure often end up owning the exceptions too.

Common Variations and Edge Cases

Tighter segregation of duties often increases operating overhead, requiring organisations to balance independence against delivery speed. That tradeoff is real in product engineering, cloud platform teams, and incident response where the same few people may hold the technical context needed to act quickly. The goal is not blind separation everywhere, but credible independence where the risk justifies it.

One common edge case is emergency access. Best practice is evolving, but emergency elevation should still preserve an after-the-fact review by someone who did not initiate the grant. Another is very small organisations, where full role separation may be impractical. In those cases, compensating controls matter more: stronger logging, time-limited access, mandatory peer review for exceptions, and independent periodic sampling. For NHI estates, the risk is amplified because credentials can be reused by automation long after the original approval has faded from memory. The 52 NHI Breaches Analysis shows why weak lifecycle discipline and poor review separation frequently appear together in real incidents.

Security leaders should treat any process where the same team can both authorise and certify access as a control design flaw unless a documented, independent compensating control exists. That is the difference between a procedural workflow and a defensible governance control.

Related resources from NHI Mgmt Group

• What breaks when organisations rely only on periodic access reviews?
• What breaks when access management stops at SSO and MFA?
• What breaks when workload identity access is governed like human access?
• What breaks when access governance is not standardised across a hospital group?