Because they often arrive with their own credential stores, rotation habits, and access assumptions. Without re-certifying ownership and dependencies, the enterprise inherits access that may still work but no longer matches policy or business need. The risk is hidden persistence, not just poor visibility.
Why This Matters for Security Teams
Acquired software rarely arrives as a clean slate. It usually brings inherited API keys, database passwords, certificates, deployment tokens, and service dependencies that were created for a different operating model. That matters because secrets management is not just about storing credentials centrally, it is about knowing which secrets still exist, who can use them, and whether they still match current privilege and business intent. Fragmentation and weak ownership turn post-acquisition integration into an exposure problem. The State of Secrets in AppSec notes that organisations maintain an average of 6 distinct secrets manager instances, which helps explain why inherited estates so often remain split across tools and teams. In practice, many security teams discover the problem only after integration work exposes credentials that should have been retired months earlier.
How It Works in Practice
The risk emerges in the handoff between technical ownership and operational reality. During an acquisition, application teams often preserve the target environment so business services keep running, but the existing secret stores, rotation schedules, and approval paths may never be revalidated. As a result, credentials can remain valid even after the business no longer has a clear reason to keep them. That creates hidden persistence, especially when secrets are embedded in CI/CD pipelines, configuration files, container images, or third-party integrations.
A sound review usually needs to answer four questions:
- Which secrets exist, and where are they stored or injected?
- Which systems still depend on them, and are those dependencies legitimate?
- Who owns rotation, revocation, and exception approval after the acquisition?
- What breaks if each secret is disabled, and how quickly can the breakage be detected?
The practical problem is that inherited applications often come with “working” access paths that are invisible until someone tries to remove them. Some of those paths are legitimate transitional dependencies, but others are leftover access that no one has consciously accepted. The safest approach is to recertify the secrets inventory before migration, then rotate or revoke by dependency group rather than by repository or team label. OWASP Non-Human Identity Top 10 is useful here because many of the secrets in acquired estates are tied to machine and workload access, not human login flows. These controls tend to break down when the acquired environment has undocumented service-to-service dependencies and no single team can explain which secrets are still required.
Common Variations and Edge Cases
Tighter secrets control often slows integration, so organisations have to balance short-term business continuity against the cost of leaving inherited access in place. The right response depends on whether the application is being absorbed, isolated, or sunsetted. A sunset path usually justifies aggressive revocation, while a critical revenue system may need a staged rotation plan with temporary exceptions.
Two edge cases deserve special attention. First, vendor-managed or partner-linked applications can hide secrets outside the acquirer’s direct tooling, which means the security team must verify contractual and technical revocation paths, not just scan its own vaults. Second, “dynamic” credentials are safer than long-lived ones, but they still create risk if ownership, scope, and expiry are unclear after the deal closes. This is where The 2024 State of Secrets Management Survey is especially relevant, since it highlights dissatisfaction with central management and the operational burden of manual remediation. The key judgement is whether the acquired system can be brought under one control plane without breaking business dependencies or leaving exceptions to become permanent.
Risk and Threat Considerations
Acquired applications create a secrets risk because they often preserve access paths that no longer have a clear business justification. That produces exposure through orphaned credentials, stale integration tokens, and overbroad service accounts that survive the transition period and remain usable long after ownership changes.
Failure mechanism: The failure is usually not immediate compromise, but persistence. If inherited secrets are not re-certified, an attacker who later finds one of those credentials can reuse a valid path into production systems, or a former vendor, contractor, or integration can keep access that the enterprise believes has been removed.
Impact: The impact is unauthorised access that is hard to distinguish from legitimate application traffic, delayed revocation, larger blast radius during incident response, and a control environment where the enterprise cannot confidently prove who still has access to what.
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 CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Acquired apps often retain machine credentials that outlive ownership changes. |
| NHI-03 — Privilege and Access Governance | Post-acquisition secrets frequently preserve access that no longer matches business intent. | |
| NHI-06 — Lifecycle and Rotation | Mergers expose stale rotation habits and long-lived credentials that keep working unnoticed. | |
| Recommendation — Inventory inherited machine credentials and rotate or revoke any secret with unclear ownership. Re-certify inherited access paths and remove privileges that are no longer justified. Enforce rotation deadlines and tie each inherited secret to a documented lifecycle owner. | ||
| NIST CSF 2.0 | PR.AC-1 — Identity and Access Management | Inherited secrets change access control posture and require recertification after acquisition. |
| GV.RM-03 — Risk Management Strategy | Acquisition secrets risk is a governance issue that needs explicit risk acceptance or remediation. | |
| Recommendation — Review inherited access paths and revoke credentials that exceed current business need. Document inherited-secret risk decisions and assign remediation ownership with deadlines. | ||
| CIS Controls v8 | 5 — Account Management | Acquired systems often contain unmanaged accounts and service credentials. |
| 3 — Data Protection | Secrets exposure often occurs through files, configs, images and code repositories. | |
| Recommendation — Disable or revalidate inherited accounts and secrets before integrating the application. Protect and scan code, configs and images for embedded secrets during acquisition. | ||
Practitioner Guidance
What to prioritise: Start with secrets that grant production access, cross-environment access, or access to shared infrastructure. Those are the credentials most likely to survive an acquisition with material blast radius.
What to verify: Confirm that every inherited secret has an owner, an expiry or rotation rule, and a documented dependency. If any one of those is missing, treat the secret as ungoverned until proven otherwise.
Decision rule: If a secret can authenticate to a live business system and no current owner can justify it, rotate or revoke it before you spend time on cosmetic cleanup. If revocation would interrupt service, narrow the exception and time-box the remediation.
What practitioners underestimate: The hardest part is usually not storing secrets in one place, it is proving that a secret can be removed without breaking an undocumented dependency. That proof is what separates safe consolidation from accidental outage.
Practitioner takeaway: In acquisitions, the real secrets-management question is not whether a credential still works, but whether the organisation can explain why it still needs to work.
