Notifications
Clear all
Topic starter
25/06/2026 5:05 pm
TL;DR: Dark web monitoring is being framed as a way to detect exposed secrets across repos, vaults, chat, and cloud assets, with Avast cited by Entro Security on the low resale value of most advertised exploits. The real issue is not visibility alone but the trust assumptions that let secrets escape governance in the first place.
NHIMG editorial — based on content published by Entro Security: Dark web monitoring: Prevent your secrets from falling into the wrong hands
Questions worth separating out
Q: How should security teams respond when exposed secrets are found on the dark web?
A: Treat the finding as a credential lifecycle incident, not just an alert.
Q: Why is dark web monitoring not enough to secure secrets?
A: Because monitoring only detects leakage after the secret has already escaped.
Q: What do organisations get wrong about exposed API keys and tokens?
A: They often assume the main issue is where the secret was found, when the deeper issue is who still trusts it.
Practitioner guidance
- Map every secret to an owner and issuing system Build a lineage record for each API key, token, password, or certificate so security teams can identify the issuing system, business owner, and downstream services before an exposure event occurs.
- Test revocation across all trust dependencies For every secret type in scope, confirm that revocation at the source actually disables access in connected services, integrations, and automation jobs that still trust the credential.
- Expand discovery beyond code repositories Include chat tools, ticketing platforms, cloud assets, vaults, and collaboration systems in secret discovery so leakage is not missed outside traditional source-control scanning.
What's in the full article
Entro Security's full blog covers the operational detail this post intentionally leaves for the source:
- Specific product workflow for scanning vaults, repositories, chat, cloud assets, and ticketing systems for exposed secrets
- Automated remediation path details for detecting and responding to dark web leakage
- Secret lineage views showing ownership, enablement status, permissions, correlated services, and risk levels
- The vendor's framing of how its monitoring feature set fits into a broader secrets protection workflow
👉 Read Entro Security's blog on dark web monitoring and exposed secrets →
Dark web monitoring and secrets exposure: what IAM teams should act on?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 5:35 pm
Dark web monitoring is a detection control, not a secrets governance strategy. The article is strongest when it frames monitoring as a way to find exposed credentials after they have already left the control plane. That is useful, but it does not solve secret creation, distribution, ownership, or revocation. For NHI and workload identity programmes, the real programme failure is assuming visibility equals control. Practitioners should treat monitoring as an alerting layer on top of lifecycle governance, not a substitute for it.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and they are 13% more likely to be categorised as critical than code-based leaks.
A question worth separating out:
Q: Who should own response when a secret is leaked outside the organisation?
A: The business or platform team that owns the issuing system should own remediation, with security coordinating validation and containment. If no owner can be identified, the organisation has a governance gap as well as an exposure problem. Dark web findings should route through a named secret owner, not a generic queue.
👉 Read our full editorial: Dark web monitoring exposes the secret sprawl problem
