Post-close re-certification is the review of inherited access after a merger or acquisition completes. It forces teams to re-justify privileges under the buyer’s own policies, which is essential when the target’s old access model no longer matches the combined environment.
Expanded Definition
Post-close re-certification is the controlled review of inherited access after a merger or acquisition closes, when accounts, API keys, service accounts, and other non-human identities must be re-justified against the buyer’s policies. In NHI governance, it is not a ceremonial attestation. It is a reset point for privilege, ownership, and business purpose.
The term sits close to access recertification and entitlement review, but the post-close context matters because the inherited estate often contains duplicated admins, orphaned automation, and secrets tied to the seller’s tooling. No single standard governs this yet, so definitions vary across vendors and advisory content. In practice, the buyer must decide which identities survive, which are converted, and which are revoked or reissued. This is especially important when the target’s old access model was built around different trust boundaries, logging, or vaulting practices. For broader identity governance context, the NIST Cybersecurity Framework 2.0 remains a useful anchor for access governance and recovery planning.
The most common misapplication is treating post-close re-certification as a one-time spreadsheet exercise, which occurs when teams review only human admin accounts and ignore machine credentials embedded in pipelines, integrations, and application configs.
Examples and Use Cases
Implementing post-close re-certification rigorously often introduces a temporary operational slowdown, requiring organisations to weigh rapid integration against the risk of carrying forward unverified access.
- A buyer inherits a subsidiary’s CI/CD system and must re-approve service accounts before production deployment rights are preserved.
- An M&A integration team reviews legacy API keys after close and rotates any credential that was issued under the seller’s vault and naming conventions.
- Shared cloud roles are mapped to business functions, then re-certified so inherited privilege matches the combined operating model rather than the target’s old org chart.
- Automation used by finance, support, or data migration scripts is validated against the buyer’s Ultimate Guide to NHIs — What are Non-Human Identities guidance on lifecycle control and privilege reduction.
- A post-close review uncovers an overprivileged integration account in a system similar to the Sisense breach pattern, prompting immediate containment and re-issuance.
Where identity governance is mature, this review also aligns with NIST guidance on least privilege and continuous access review, including NIST Cybersecurity Framework 2.0 outcomes for access control and recovery.
Why It Matters in NHI Security
Post-close re-certification matters because M&A activity expands the attack surface before the buyer fully understands it. Inherited NHIs can retain access to cloud resources, SaaS apps, code repositories, and data pipelines long after the business case for that access has expired. NHIMG research shows that 97% of NHIs carry excessive privileges, and that scale of overreach becomes especially dangerous during integration, when trust decisions are being made quickly and often without complete visibility. The risk is not only unauthorized access; it is also hidden dependency. A single revoked token can break payroll, data replication, or customer support if the dependency was never documented. That is why governance must pair recertification with ownership assignment, secret rotation, and decommissioning. This is consistent with the identity control expectations reflected in the NIST Cybersecurity Framework 2.0 and the lifecycle emphasis in the Ultimate Guide to NHIs — What are Non-Human Identities.
Organisations typically encounter the consequences only after a post-merger incident, failed audit, or production outage, at which point post-close re-certification 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 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-02 | Inherited secrets and service accounts must be reviewed and remediated after close. |
| NIST CSF 2.0 | PR.AA | Access governance after acquisition aligns with identity and authorization management outcomes. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification of access, including post-merger inherited privilege. |
Re-certify inherited NHIs, rotate exposed secrets, and remove unneeded access immediately after integration.
Related resources from NHI Mgmt Group
- Why do non-human identities make access certification harder than human identities?
- Should IAM teams re-evaluate their NHI tooling choices after a major acquisition?
- When does continuous monitoring matter more than access certification?
- Should security teams re-evaluate identity tooling when regional demand accelerates?
