Third-party secrets security risks are widening enterprise attack surfaces

At a glance

What this is: This is an analysis of third-party secrets risk, showing how external partners expand NHI exposure through leaked credentials, overprivileged access, and weak lifecycle control.

Why it matters: It matters because IAM, PAM, and NHI teams must govern external access as part of the identity lifecycle, not as an isolated security exception.

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.

👉 Read Entro Security's analysis of third-party secrets security risks

Context

Third-party secrets are the credentials, tokens, certificates, and keys that let external services connect into enterprise systems. In practice, they are non-human identities with real operational reach, which means their exposure becomes an identity governance problem rather than just a secure coding problem.

Entro Security’s article argues that the risk is increasing because organisations now depend on many more partners, cloud services, and delivery pipelines. That expansion makes lifecycle control, visibility, and remediation harder, especially where external secrets are reused, overprivileged, or left active after business relationships change.

Key questions

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. Then pair discovery with privilege reduction, continuous scanning, and a revocation workflow tied to partner offboarding. If a secret can authenticate into production, it needs the same governance discipline as any other high-risk access path.

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. If the secret is overprivileged, duplicated, or left active after its business purpose ends, one leak can affect multiple systems. IAM teams must govern the secret lifecycle, not just the login event.

Q: What breaks when secrets are hard-coded into code or deployment pipelines?

A: The organisation loses control over distribution, visibility, and retirement. Hard-coded secrets get copied into builds, tickets, logs, and forks, which makes revocation slow and incomplete. The result is an access path that outlives the team’s ability to account for it.

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.

Technical breakdown

Why third-party secrets become enterprise trust bridges

A third-party secret is not just a string stored in a vault. It is a trust bridge that authorises one organisation’s system to act inside another organisation’s environment. API keys, SSH keys, certificates, and access tokens all carry different blast radii, but the core failure mode is the same: the secret inherits trust from the relationship, not from the actual use case. When that relationship is broad, the secret often ends up broader than necessary. That creates a hidden identity layer that IAM teams rarely govern with the same rigor as human accounts.

Practical implication: inventory every external secret as a governed identity with an owner, scope, and expiry condition.

How exposure, reuse, and overprivilege compound NHI risk

Exposure is the entry point, but reuse and overprivilege determine impact. A secret hard-coded into a repository, pasted into a ticket, or shared across multiple systems can be copied far faster than teams can revoke it. If the same secret authenticates several applications, one compromise can cascade across multiple services. Overprivilege makes the damage worse because the secret can do more than the original integration required. In NHI terms, the problem is not only credential theft. It is credential scope that was never reduced to match the business function.

Practical implication: pair secret discovery with scope reduction so exposed credentials are not also high-impact credentials.

Why DevOps speed breaks third-party secret lifecycle control

CI/CD pipelines amplify third-party secret risk because they accelerate creation, replication, and distribution. Secrets move through code, build systems, deployment automation, and runtime environments, often without a clean offboarding path. That makes lifecycle governance difficult: teams can create a secret in minutes, but retire it only after hunting for every dependent integration. This is why detection alone is insufficient. The control failure is not visibility in isolation. It is the lack of an enforceable process that ties discovery, prioritisation, revocation, and reissue together across the full lifecycle of the NHI.

Practical implication: build secret retirement into pipeline change control, not into post-incident cleanup.

Threat narrative

Attacker objective: The attacker aims to turn trusted partner access into persistent unauthorized access across one or more enterprise systems.

1. Entry occurs when a third-party secret is exposed in code, configuration, or an external collaboration surface and is then collected by an attacker.
2. Escalation follows when that secret has broader permissions than the original task required, allowing the attacker to access more systems than intended.
3. Impact occurs when the compromised external identity is used to extract data, disrupt services, or pivot into connected environments through trusted integrations.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Secret exposure is only the first failure, not the real control collapse. The deeper issue is that organisations often discover external credentials faster than they can explain why those credentials existed, who approved them, and when they should have died. That is a lifecycle failure in NHI governance, not just a detection failure. The practitioner conclusion is to treat exposure as evidence of weak lifecycle design, not as a standalone alert to clear.

Overprivileged third-party access creates identity blast radius that most teams still underestimate. A vendor token with administrative reach is not a convenience, it is a concentration of risk across every connected system it can touch. The article’s examples show how access scope can exceed business need long before an incident occurs. The practitioner conclusion is to measure third-party privilege by downstream impact, not by the number of integrations supported.

Secret sprawl is now a supply chain security problem with identity characteristics. The combination of cloud growth, microservices, and CI/CD has made secret distribution faster than governance can keep up. That means the issue spans IAM, PAM, and software delivery, which is why separate teams often miss the full picture. The practitioner conclusion is to govern external secrets as part of the broader identity supply chain, not as isolated DevOps hygiene.

Ephemeral credential trust debt: The assumption that temporary secrets remain trustworthy until manually reviewed was designed for slower, human-paced operations. That assumption fails when third-party secrets are copied into pipelines and collaboration tools at machine speed, then remain active after their original use case ends. The implication is that lifecycle review alone cannot keep pace with the trust debt created by modern integration patterns. The practitioner conclusion is to stop assuming manual oversight can absorb the volume and speed of modern secret creation.

From our research:

• 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.
• For the broader risk picture, see 52 NHI Breaches Analysis for repeated failure patterns in secret exposure, overprivilege, and lifecycle gaps.

What this signals

Third-party secrets should now be treated as a lifecycle-managed extension of enterprise identity, not a narrow DevOps issue. The practical shift is toward continuous discovery, scoped access, and faster offboarding when a partner relationship changes. Teams that cannot explain where external secrets live, who owns them, and when they expire are already operating with avoidable identity risk.

Identity blast radius: the real metric is no longer how many secrets exist, but how far one secret can propagate if exposed. That means security teams need to align NHI discovery with PAM-style privilege review and pipeline controls that limit replication across repositories, build systems, and runtime environments.

The governance lesson is that visibility without revocation is incomplete control. Organisations should watch for signs that secrets persist after their business purpose ends, because that is where exposure turns into sustained access and where external trust becomes a repeatable attack path.

For practitioners

• Inventory third-party secrets as governed identities Map every external token, key, certificate, and SSH secret to an owner, business purpose, and expiry condition. Include secrets in cloud services, code repositories, tickets, and collaboration tools so there is a single view of where they exist and why they are active.
• Reduce privilege before exposure happens Review external secrets for excessive permissions and replace broad administrative access with task-scoped rights. If one secret authenticates multiple applications, split the access path so compromise of one integration does not create uncontrolled lateral reach.
• 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. Offboarding external access should be a governed workflow, not a manual follow-up task.
• Scan collaboration surfaces and pipelines continuously Extend discovery beyond repositories to tickets, documentation, build logs, and CI/CD variables because that is where third-party secrets commonly drift. Make the scan results actionable by routing findings to the team that can revoke or rotate the credential immediately.

Key takeaways

• Third-party secrets are a non-human identity problem because they grant external systems real authority inside the enterprise.
• The main failure pattern is not exposure alone, but exposure plus overprivilege, duplication, and slow lifecycle offboarding.
• IAM and PAM teams should govern external secrets as lifecycle objects with ownership, scope reduction, and enforced retirement.

Key terms

• Third-party secret: A third-party secret is a credential or token issued to, shared with, or embedded by an external party so systems can communicate. In identity terms, it is a non-human identity that must be governed for scope, ownership, and retirement, not treated as a simple configuration value.
• Secret sprawl: Secret sprawl is the uncontrolled spread of credentials across code, tickets, documents, pipelines, and runtime systems. It increases the chances of exposure, duplication, and unmanaged reuse, which makes revocation slower and identity governance far harder to enforce.
• Identity blast radius: Identity blast radius is the amount of damage a single identity or secret can cause if it is compromised. For non-human identities, it is shaped by privilege scope, reuse across applications, and how quickly the credential can be rotated or revoked.

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.

👉 The full Entro Security post covers exposure paths, remediation guidance, and rotation considerations in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or maturing governance across your programme, it is worth exploring.