Why do compromised credentials matter more than vulnerability counts in M&A security?

Why This Matters for Security Teams

In M&A work, vulnerability counts are a weak proxy for risk because they describe potential exposure, not usable access. Compromised credentials matter more because they immediately reveal where trust can be abused, where admin reuse exists, and which identity paths can be chained into lateral movement. That distinction is central to acquisition security, where inherited access often spans multiple tenants, vendors, and legacy directories.

NHIMG research shows how often identity blind spots become the real problem: in The State of Non-Human Identity Security, only 1.5 out of 10 organisations are highly confident in securing NHIs, and 85% lack full visibility into third-party vendors connected via OAuth apps. That confidence gap matters because M&A assessments often over-focus on scan results while under-weighting credential reuse, secret sprawl, and dormant trust relationships. Guidance from the OWASP Non-Human Identity Top 10 reinforces that identity abuse is frequently the faster path to impact than exploiting a vulnerability. In practice, many security teams discover the real acquisition blast radius only after a valid credential has already been used to pivot across shared services.

How It Works in Practice

A pragmatic M&A review starts by asking which credentials are valid, where they work, and what trust they inherit. That includes human admin accounts, service accounts, API keys, OAuth grants, CI/CD secrets, and non-human identities embedded in scripts or automation. Vulnerability scans still matter, but they should be interpreted as secondary context unless they directly expose a path to execution or privilege escalation.

Current best practice is to map identity flows, not just asset counts. That means:

• Inventorying active credentials, secret stores, federation links, and third-party OAuth connections.
• Checking whether privileged access is shared, reused, or unmanaged across environments.
• Revalidating authentication boundaries after directory mergers, tenant linking, or temporary migration access.
• Prioritising evidence of credential compromise, token theft, and session hijacking over raw CVE totals.

This aligns with CISA cyber threat advisories and the control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls, where access control and auditability are operational concerns, not paper exercises. For acquisition teams, the practical question is whether a stolen credential can reach crown-jewel systems before detection. That is why NHIMG’s Guide to the Secret Sprawl Challenge is more useful than a generic vuln summary when prioritising remediation. These controls tend to break down when inherited tenants, unmanaged service accounts, and stale federations are left in place during a fast-close integration.

Common Variations and Edge Cases

Tighter credential controls often increase deal friction, requiring organisations to balance rapid integration against containment and verification. That tradeoff is real in carve-outs, partial acquisitions, and regulated environments where business continuity limits how fast accounts can be reset or segmented.

There is no universal standard for this yet, but current guidance suggests treating “high vulnerability count” and “known credential compromise” as different risk classes. A noisy scan may indicate hygiene debt, while a confirmed credential leak can represent immediate access. In practice, a small number of compromised secrets in source control, build pipelines, or cloud consoles can outweigh hundreds of unexploited findings because the attacker already has an authenticated starting point.

Edge cases include environments with strong segmentation but poor secret governance, where vulnerability reports look severe but attack paths are actually constrained. The opposite also happens: low scan volume can mask catastrophic identity exposure, especially where The 52 NHI breaches Report pattern of secret misuse is present. For acquisition due diligence, the right lens is whether a credential can be used, reused, and escalated. If the answer is yes, the vulnerability count is usually just background noise.

Related resources from NHI Mgmt Group

• Why do compromised package publisher identities matter for supply chain security?
• What is the impact of using hard-coded credentials on security?
• Why do kernel privilege escalation bugs matter so much for container security?
• How do security teams know if cluster credentials are usable outside their intended boundary?