Notifications
Clear all
Topic starter
24/06/2026 9:27 pm
TL;DR: Third-party trust now reaches deep into enterprise identity layers, and SecurityScorecard’s 2024 report cited in Entro Security’s post says 98% of organisations have ties to a breached third party, while 29% of security incidents are linked to those relationships. The governance problem is not exposure alone, but unmanaged secrets, overprivilege, and slow remediation across external access paths.
NHIMG editorial — based on content published by Entro Security: A deeper look into third-party secrets security risks
By the numbers:
- 98% of organizations have ties to a third party that has experienced a breach.
- 29% of all security incidents are linked to third-party breaches.
- 12.8 million cases of secrets were exposed on GitHub in 2023.
Questions worth separating out
Q: How should security teams govern third-party secrets in cloud environments?
A: Treat every external secret as a managed identity with an owner, scope, and retirement date.
Q: Why do third-party secrets create so much risk for IAM programmes?
A: They extend trust outside the organisation while often bypassing the controls used for human access.
Q: What breaks when secrets are hard-coded into code or deployment pipelines?
A: The organisation loses control over distribution, visibility, and retirement.
Practitioner guidance
- Inventory third-party secrets as governed identities Map every external token, key, certificate, and SSH secret to an owner, business purpose, and expiry condition.
- Reduce privilege before exposure happens Review external secrets for excessive permissions and replace broad administrative access with task-scoped rights.
- Bind secret retirement to lifecycle events Trigger revocation and replacement when a partner relationship changes, a vendor contract ends, a pipeline is retired, or a secret is copied into a new system.
What's in the full article
Entro Security's full blog covers the operational detail this post intentionally leaves for the source:
- Specific examples of how third-party secrets leak through public repositories, .env files, and CI/CD pipelines.
- The article's practical remediation guidance on detection, prioritisation, and revocation for exposed secrets.
- A fuller explanation of how to assess context when deciding which secrets to rotate first.
- The vendor's discussion of how to support developers with guidance, not just alerts, during incident response.
👉 Read Entro Security's analysis of third-party secrets security risks →
Third-party secrets exposure is growing. What should IAM teams do?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 6:42 am
Third-party secrets are governance-bound NHIs, not temporary integration artefacts. The article is right to frame API keys, tokens, certificates, and SSH keys as operational identity objects rather than passive configuration. Once a third party can act through those secrets, the access path needs owner assignment, scope review, and retirement discipline. The practitioner conclusion is simple: if the secret has runtime authority, it belongs in identity governance.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- Our research also found that 60% of NHIs are being overused, with the same NHI utilised by more than one application, increasing the risk of widespread compromise if exposed.
A question worth separating out:
Q: How can teams tell whether third-party secret controls are actually working?
A: Look for evidence that every exposed or unused secret is being found, prioritised, and revoked quickly, and that partner access is removed when the relationship changes. If secrets remain active after their original purpose ends, the control is not working, even if scanning exists.
👉 Read our full editorial: Third-party secrets security risks are widening enterprise attack surfaces
