Cisco breach exposes how public NHI secrets break DevOps trust

At a glance

What this is: Cisco's public-facing DevHub exposure shows how leaked NHI secrets can turn a developer support environment into an access path for sensitive data.

Why it matters: IAM teams need to treat exposed secrets as an identity governance issue because NHI compromise can bypass perimeter controls, expand DevOps blast radius, and destabilise downstream human and workload access decisions.

👉 Read Oasis Security's analysis of the Cisco NHI breach and exposed DevHub secrets

Context

NHI secrets exposure is a governance problem before it is a tooling problem. When credentials, tokens, certificates, or private keys sit in a public-facing environment, the identity layer has already failed because access is no longer bounded by intended ownership or lifecycle controls. In this case, the primary keyword is non-human identities, because the compromise centers on machine credentials and their operational context.

Cisco's DevHub was designed to support third-party developers, but the exposed material gave an attacker a practical path into sensitive data. That makes this a DevOps security issue as much as an access issue: secret sprawl, unclear ownership, and long-lived credentials combine to create a breach surface that conventional perimeter thinking does not close. The starting posture is unfortunately typical for cloud and hybrid environments that grow faster than their identity hygiene.

Key questions

Q: What breaks when exposed NHI secrets are left in public DevOps environments?

A: Publicly exposed NHI secrets break the assumption that internal trust boundaries still protect machine credentials. Once tokens, keys, or certificates are readable outside intended control, attackers can authenticate directly, move into adjacent systems, and copy data without exploiting a software flaw. The result is faster compromise, wider blast radius, and harder containment.

Q: Why do service accounts and API tokens create more risk when they are long-lived?

A: Long-lived service accounts and API tokens create more risk because exposure and exploitation can happen long before defenders notice. If the credential remains valid after discovery, the attacker can reuse it repeatedly and pivot through connected systems. The longer the lifetime, the larger the window for abuse and the harder it is to prove containment.

Q: How do security teams know if secret rotation is actually working?

A: Secret rotation is working only when teams can prove that each credential has an owner, an expiry path, and a tested revocation process. If rotation causes outages, leaves unknown dependencies behind, or cannot be completed quickly after exposure, the control is not operationally mature. Effective rotation reduces usable lifetime without breaking legitimate workloads.

Q: Who is accountable when exposed machine secrets are found in a public repository or portal?

A: Accountability should sit with the team that owns the workload, repository, or portal where the secret was exposed, supported by the identity or platform team that controls rotation and access policy. NHI governance works when ownership, remediation authority, and service dependency knowledge are all clear before the next incident.

Technical breakdown

Public secret exposure turns a support environment into an access path

A public-facing development or support environment becomes dangerous when it contains reusable secrets. Hard-coded credentials, API tokens, certificates, and private keys are not just sensitive files. They are identity-bearing artefacts that can authenticate a caller, reach internal systems, or reveal trust relationships inside the DevOps stack. Once those values are exposed, the attacker does not need a software vulnerability in the classic sense. The secret itself becomes the access vector, and the environment that was meant to help external developers becomes a bridge into higher-value systems.

Practical implication: eliminate public exposure of identity-bearing secrets and inventory every external-facing repository, portal, and image store.

Why long-lived NHI credentials widen the breach window

Long-lived non-human identities increase the time between exposure and containment. If a token, key, or certificate remains valid beyond the moment it is discovered, the attacker can test, replay, and pivot before defenders react. That is why lifecycle discipline matters as much as detection. The issue is not only whether a secret was leaked, but whether the secret can still be used, where it is authorised, and whether ownership is clear enough to support safe revocation without breaking legitimate workloads.

Practical implication: tie every secret to a known owner, usage scope, and expiry path so revocation can happen without guesswork.

Identity mapping is the control that makes secret discovery actionable

Discovering an exposed secret is only the first step. Security teams need to map that secret to the workload, service, or integration that uses it, otherwise remediation becomes either too slow or too disruptive. Identity mapping links the secret to its runtime context, including dependencies, blast radius, and downstream consumers. Without that context, teams either leave exposed credentials active too long or rotate them blindly and break production. This is where NHI governance crosses into DevOps reliability: the same control that limits exposure also preserves operational continuity.

Practical implication: maintain identity-to-secret mapping so every rotation decision can be made in context, not by manual guesswork.

Threat narrative

Attacker objective: The attacker aimed to extract and monetise sensitive Cisco and customer data by abusing exposed non-human identity secrets.

1. Entry occurred when the threat actor found publicly exposed NHI secrets in Cisco's DevHub environment, including hard-coded credentials, certificates, API tokens, and private keys. Credential access followed the exposure because those secrets could be used directly rather than stolen through malware or phishing.
2. Escalation likely came from using the exposed machine credentials to explore adjacent DevOps resources and sensitive data stores tied to the environment. The attack path did not require a traditional exploit chain once the secret set was available.
3. Impact was the download and attempted sale of Cisco data and customer data, showing that one exposed NHI secret set can create broad confidentiality loss across internal and third-party-facing systems.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

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

NHI Mgmt Group analysis

Exposed NHI secrets are a lifecycle failure, not just a leak. This breach worked because credentials, tokens, and keys existed in a place where they could be consumed outside their intended trust boundary. A secret that is visible to the wrong audience has already lost its governance value, even before it is used. The practitioner conclusion is that secret inventory, ownership, and offboarding are one control chain, not separate chores.

Standing credential exposure window: the core failure mode here is that machine credentials remained usable long enough to matter after exposure. That assumption was designed for environments where discovery and revocation happen in a stable order. It breaks when public availability and persistent validity overlap, because the attacker can exploit the window faster than the organisation can close it. The implication is that exposure duration is itself a security variable.

Identity blast radius grows when DevOps resources are treated as low-risk by default. Public developer environments often sit outside the same scrutiny applied to production identity systems, yet they can contain the keys to higher-value assets. Once a support portal, image repository, or configuration store carries secrets, the blast radius spans tooling, pipelines, and customer-facing data. Practitioners should treat every externally reachable DevOps surface as part of the identity perimeter.

Secrets are not merely credentials, they are control-plane assets. A token or private key can silently authorise machine-to-machine access, which means compromise often looks like legitimate use until the downstream impact appears. That is why NHI governance cannot stop at detection. The field needs stronger assumptions about where secrets live, who can read them, and how quickly their authority expires. The practitioner conclusion is to govern secrets as runtime identities.

Oasis Security's breach framing reinforces a broader market reality: visibility alone is incomplete without governance context. Discovery tools can find exposed values, but remediation depends on knowing what those values unlock, who owns them, and what breaks when they are revoked. That places NHI governance, DevOps operations, and access lifecycle management in the same decision loop. Practitioners should align those functions before the next exposure event.

From our research:

• The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
• That same body of research shows enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, pointing to recurrence rather than one-off failure.

What this signals

Exposed secret governance is becoming a board-level resilience issue, not a niche DevOps hygiene task. With 72% of organisations reporting or suspecting an NHI breach, the operational question is no longer whether exposure happens, but whether the organisation can revoke authority fast enough to limit secondary impact. Teams should expect more scrutiny on ownership, revocation speed, and dependency mapping across developer-facing systems.

Standing credential exposure window is the right phrase for the gap this incident illustrates. When a secret remains valid after it becomes public, the gap is not discovery, it is duration. That means programmes should measure time-to-revocation with the same seriousness they apply to time-to-detect, especially for public portals and cloud support surfaces.

For practitioners

• Search every external-facing DevOps surface for exposed secrets Include portals, package repositories, container images, configuration files, and documentation stores. Treat hard-coded credentials, certificates, API tokens, and private keys as identity assets that require immediate ownership assignment and cleanup.
• Map each secret to a named workload owner and runtime dependency Document which service, integration, or pipeline uses the secret, what systems it can reach, and what will fail if it is revoked. That context lets teams rotate safely instead of guessing.
• Shorten the usable lifetime of exposed non-human credentials Use tighter expiry, rotation triggers, and narrow scope for secrets that can reach public or semi-public environments. Long-lived keys should never be the default for developer support or hybrid access paths.
• Build incident playbooks around secret ownership, not just secret detection When a secret is found in the wild, the first task is to identify the authoritative owner and the affected trust chain. That reduces containment delays and prevents accidental outages during rotation.

Key takeaways

• This breach showed that exposed NHI secrets can turn a public DevOps surface into a direct path to sensitive data.
• NHIMG research indicates the problem is widespread, with 72% of organisations reporting or suspecting an NHI breach and compromised environments averaging 2.7 incidents.
• The limiting control is not discovery alone, but ownership-linked rotation that can revoke authority without breaking the workloads that depend on it.

Key terms

• Non-Human Identity: A non-human identity is any machine or software credential that can authenticate or authorise access, including service accounts, API keys, tokens, certificates, and workload identities. In practice, it is a runtime identity that must be governed across creation, use, rotation, and offboarding just like any other access path.
• Standing Credential Exposure Window: The standing credential exposure window is the period between when a secret becomes visible outside intended control and when its authority is fully revoked. The longer that window remains open, the more likely an attacker can reuse the credential, pivot into connected systems, or copy data before remediation completes.
• Identity Mapping: Identity mapping is the process of linking a secret or credential to the exact workload, repository, service, or integration that depends on it. That mapping tells defenders who owns the credential, what it unlocks, and what will break if it is rotated, which makes safe remediation possible.
• Blast Radius: Blast radius is the amount of damage a compromised identity can create across systems, data, and downstream dependencies. For non-human identities, it is shaped by credential scope, credential lifetime, and how much trust is embedded in the environments that can read or use the secret.

Deepen your knowledge

NHI secret discovery, ownership mapping, and safe rotation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a programme to handle exposed machine credentials, it is worth exploring.

This post draws on content published by Oasis Security covering the Cisco breach and exposed non-human identities: Cisco Breach: Non Human Identities (NHI) Compromise and Implications for DevOps Security. Read the original.