How should organisations combine penetration testing with identity governance?

Why This Matters for Security Teams

Penetration testing and identity governance solve different parts of the same problem. Pentesting shows how an attacker can move through real systems, while identity governance determines whether the access paths that made that movement possible should exist at all. When those disciplines are separated, findings become one-time reports instead of durable control improvements. NIST Cybersecurity Framework 2.0 makes the point at a program level by linking risk identification, access control, and continuous improvement across the security lifecycle through NIST Cybersecurity Framework 2.0.

The practical value is in making identity findings testable. A penetration test can confirm whether a service account has excessive permissions, whether a privileged session can be reused, or whether a stale delegated token still works after a role change. Identity governance then converts that evidence into access review, approval redesign, secret rotation, and offboarding fixes. Without that handoff, organisations often patch the attack path in one environment but leave the same pattern live in other business units, cloud tenants, or automation pipelines. In practice, many security teams encounter identity weaknesses only after a test shows lateral movement, rather than through intentional control verification.

How It Works in Practice

A useful model is to treat pentesting as the validation layer and identity governance as the remediation and prevention layer. The pentest team should be scoped to identity-relevant attack paths such as excessive RBAC assignments, dormant accounts, shared admin credentials, long-lived API keys, federation misconfigurations, and privileged automation used by agents or scripts. The governance team should then map each confirmed path to a control owner, remediation due date, and repeatable prevention step.

Good practice is to translate each finding into an identity object or process, not just a ticket. For example, if a tester reaches a production system through an over-privileged service account, the response should include removing unused entitlements, moving the account to just-enough access, storing its secret in a managed vault, and setting a rotation interval that matches operational reality. If a delegated access chain survives a role change, the review process should explicitly check inheritance, group membership, and application-side authorization, not just the directory record.

• Use pre-test identity inventories so testers know which accounts, secrets, and trusts are in scope.
• Capture every successful identity-based attack path as a governance control gap, not only a technical exploit.
• Require evidence that remediations changed entitlement state, secret lifecycle, or approval logic.
• Retest after rotation, deprovisioning, and privilege cleanup to confirm the path is actually closed.

Frameworks such as MITRE ATT&CK are useful for classifying the technique used, while identity-specific control mapping benefits from OWASP guidance on non-human identity risk and access sprawl. Current guidance suggests the strongest programs run pentests on a recurring cadence but trigger identity review immediately after any finding that involves accounts, tokens, certificates, or delegated privileges. These controls tend to break down when testing is outsourced without access to identity architecture, because the report then describes symptoms while the real authorization failure stays hidden in upstream policy design.

Common Variations and Edge Cases

Tighter pentesting scope often increases operational overhead, requiring organisations to balance realistic attack simulation against change-control windows, production stability, and identity-team capacity. That tradeoff becomes more visible in hybrid estates, regulated sectors, and environments with large automation footprints.

One common edge case is third-party access. A test may show that partner accounts remain active after a contract ends, but the fix is not only deprovisioning. It may also require federation policy changes, shorter access lifetimes, and contract-driven review cycles. Another edge case is machine identity. Some environments have strong human access reviews but weak governance for certificates, workloads, and service principals. In those cases, the pentest may expose a path that is technically “non-human” but still governed through the same approval process as a user account, which is usually too slow for operational security.

There is no universal standard for exactly how often identity issues should be retested after remediation. Best practice is evolving, but the decision should reflect the criticality of the path, the velocity of identity change, and whether the weakness affects internet-facing systems, privileged automation, or sensitive data. For high-risk paths, combining a short remediation window with focused retesting is more reliable than waiting for the next annual assessment. If identity governance teams and testers do not share a common asset and entitlement source, the program tends to drift into point-in-time compliance rather than continuous control assurance. The MITRE ATT&CK technique catalog can help keep retesting aligned to actual attacker behavior, while governance teams preserve the authoritative access record.

Related resources from NHI Mgmt Group

• What is the Agentic AI identity governance framework organisations should adopt?
• Should organisations prioritise identity governance before expanding agentic AI?
• When should organisations review external data shares as part of identity governance?
• Should organisations delay production AI agents until identity governance is mature?