Should organisations exclude birthright access from certification campaigns?

Why This Matters for Security Teams

birthright access is not the problem by itself. The issue is that certification campaigns often mix stable baseline entitlements with discretionary and privileged access, which makes reviewers rubber-stamp what should never have been in scope. That dilutes signal, wastes approver time, and obscures whether access is still justified. OWASP’s OWASP Non-Human Identity Top 10 treats weak lifecycle governance as a recurring control failure, and the same logic applies to human access reviews.

For NHI-adjacent environments, the lesson is sharper. If an identity is expected to exist, but its baseline permissions are not reliably defined, the review process becomes a fault-finding exercise instead of a governance decision. NHIMG’s Ultimate Guide to NHIs frames this as an identity lifecycle issue: governance only works when the baseline is trustworthy and exceptions are visible. That same principle applies to employee, contractor, and service access reviews. In practice, many security teams discover over-entitlement only after a certification campaign has already approved it for another cycle.

How It Works in Practice

The most defensible model is to exclude true birthright access from routine recertification, then manage it through entitlement design, joiner-mover-leaver controls, and periodic baseline validation. That means the organisation must first define what “standard” actually means by role, location, employment type, and system population. If the baseline is vague, exclusion simply hides the risk rather than reducing it.

Operationally, mature programs separate three layers:

• Static baseline access that is automatically provisioned and automatically revoked when status changes.
• Discretionary access that requires a business justification and periodic reapproval.
• Privileged access that is governed through tighter controls such as PAM, JIT, and session monitoring.

This separation improves certification quality because reviewers focus on exceptions, toxic combinations, and stale access instead of confirming that every employee still needs email, HR system access, or standard collaboration tools. Guidance from 52 NHI Breaches Analysis shows how quickly weak entitlement hygiene becomes a broader exposure problem once credentials, tokens, or access paths are reused across systems. For a parallel control model, the same logic appears in OWASP Non-Human Identity Top 10, where standing access and poor lifecycle discipline are treated as core attack-enabling conditions.

Current guidance suggests that exclusion works best when certification tooling can distinguish inheritance from exception. If the platform cannot tell whether access was assigned by policy or granted manually, reviewers lose confidence and start rechecking everything. These controls tend to break down in federated environments with multiple HR sources and loosely governed group nesting because entitlement origin becomes hard to verify.

Common Variations and Edge Cases

Tighter exclusion of birthright access often reduces review effort, but it also increases the burden on entitlement engineering and baseline assurance. Organisations must balance cleaner certification signals against the risk of quietly cementing a bad default into policy.

There is no universal standard for this yet, but a practical split is emerging. Exclude birthright access when it is: consistently provisioned, mapped to a documented role model, time-bounded by employment status, and validated through automated controls. Keep it in scope when the baseline itself is contested, when access is inherited through broad groups, or when the entitlement set changes faster than the business can maintain policy-as-code. The Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it highlights how unclear ownership and weak governance create persistent blind spots, even when access appears “standard.”

For highly regulated or merger-heavy environments, best practice is evolving toward two tracks: baseline entitlement attestation at the control-design level, and exception-focused certification at the user level. That approach prevents the review campaign from becoming a box-checking exercise while still forcing periodic scrutiny of what is truly inherited. The model is strongest when baseline definitions are reviewed after org changes, not only during the annual campaign.

Related resources from NHI Mgmt Group

• What breaks when organisations rely only on periodic access reviews?
• What do organisations get wrong about temporary access in SaaS platforms?
• How do organisations know whether frictionless access is safe?
• How should organisations govern access if IDaaS already handles sign-in?