Inherited access can remain active even when the business justification has changed. Privileged roles, service accounts, and partner integrations may continue to operate with the target’s old assumptions, creating excessive access and unexpected reach inside the combined environment. Re-certification is what forces the buyer to re-justify that access under its own control model.
Why This Matters for Security Teams
When inherited access is not re-certified after a deal closes, the combined environment keeps operating on assumptions that no longer exist. Privileged accounts, service credentials, and partner integrations can remain valid even though the legal entity, ownership, and control model have changed. That gap turns a routine integration issue into an access governance failure, especially for NHIs that never stop working just because a contract changed. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which makes post-close recertification a high-value control, not a paperwork exercise.
Security teams often underestimate how much inherited access survives in service accounts, automation jobs, API tokens, and third-party connectors. Those paths are easy to miss because they do not show up in the same way as human user access, yet they can reach production data, admin functions, and downstream systems. The real issue is not only excess access, but stale trust: the buyer inherits authorisation decisions made under a different operating model. Current guidance from the OWASP Non-Human Identity Top 10 treats unmanaged NHI privilege as a core risk area for exactly this reason. In practice, many security teams encounter misuse of inherited access only after post-close integration work has already expanded the attack surface.
How It Works in Practice
Re-certification after close should be treated as a control reset, not a simple access review. The first step is to inventory all inherited access paths: privileged roles, service accounts, machine-to-machine credentials, partner grants, delegated admin rights, and any automation that authenticates on behalf of the acquired business. That inventory must include where the access is used, who owns it after the transaction, how long the credentials remain valid, and whether the access still supports a current business process.
From there, the buyer should force each entitlement through a new approval path under the acquiring organisation’s policy model. For NHIs, that usually means validating workload identity, intended purpose, scope, rotation cadence, and whether the credential can be replaced with a shorter-lived mechanism. The NHI lifecycle guidance in Ultimate Guide to NHIs — Key Challenges and Risks is useful here because post-merger failures often come from hidden sprawl rather than a single obviously risky account. Practically, teams should:
- Re-approve every inherited privilege against current business need.
- Rotate or replace long-lived secrets as part of the close process.
- Remove orphaned integrations that no longer have an approved owner.
- Apply least privilege before systems are connected to the buyer’s network.
- Document exceptions with expiry dates, not open-ended waivers.
This should be paired with identity telemetry and access logging so that stale accounts can be detected if they are still authenticating after the recertification window closes. NIST’s access control guidance in Zero Trust Architecture reinforces the idea that trust must be continuously re-evaluated, not assumed from historical ownership. These controls tend to break down when the acquisition includes unmanaged legacy infrastructure because the inventory is incomplete and nobody can confidently map each credential to a current system owner.
Common Variations and Edge Cases
Tighter post-close recertification often increases integration effort and can slow business continuity, so organisations have to balance speed against risk. That tradeoff is real, especially when the target company runs critical services that cannot be paused without disruption. Best practice is evolving, but there is no universal standard for this yet on how quickly every inherited NHI must be re-approved. The practical rule is to prioritise anything with admin reach, external exposure, or broad token scope first.
Edge cases usually involve shared accounts, embedded credentials in pipelines, and vendor-managed integrations. These are difficult because ownership is ambiguous and the business may assume the access is “temporary” even when it persists for months. The 52 NHI Breaches Analysis shows how often credential misuse becomes a broader incident once access is left in place. In parallel, operational teams should use the Schneider Electric credentials breach as a reminder that exposed or overextended credentials can create downstream impact far beyond the original system. The hardest cases are acquisitions with fragile documentation and loosely governed partner access because re-certification becomes a reconstruction exercise, not a review.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Inherited NHIs need recertification and rotation to avoid stale privileges after a deal closes. |
| NIST CSF 2.0 | PR.AC-4 | Post-close access should be reviewed and restricted to current business need. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires trust decisions to be continuously re-evaluated after ownership changes. |
Treat the acquisition as a trust reset and require fresh verification before inherited access remains active.
