Notifications
Clear all
Topic starter
24/06/2026 9:37 pm
TL;DR: Credential stuffing made up 24.3% of login attempts in Okta’s State of Security Incident Report 2024, while the same technique increasingly targets API keys and service accounts that hold elevated access across automation and integration paths. The real issue is not only reused human passwords but the governance assumptions behind static non-human credentials.
NHIMG editorial — based on content published by Entro Security: The anatomy of a credential stuffing attack, with insights and countermeasures
By the numbers:
- Credential stuffing attacks accounted for 24.3% of all login attempts.
Questions worth separating out
Q: How should security teams reduce credential stuffing risk across human and machine identities?
A: Treat reuse as the common failure mode.
Q: Why do service accounts make credential stuffing more dangerous than it looks?
A: Service accounts often hold broader privileges than user accounts and are trusted by workflows, APIs, and pipelines.
Q: What breaks when secrets are hardcoded or widely shared?
A: Hardcoded or shared secrets break revocation, accountability, and blast-radius control.
Practitioner guidance
- Eliminate shared and hardcoded machine credentials Move API keys, tokens, and service-account secrets out of source code, configuration files, and team chat.
- Add secrets detection to development and CI/CD pipelines Scan repositories, build logs, and deployment artefacts for exposed secrets before they can be replayed.
- Rotate credentials on a defined lifecycle, not an ad hoc basis Set rotation rules by credential type and privilege level, then tie them to offboarding, vendor changes, and environment changes.
What's in the full article
Entro Security's full blog covers the operational detail this post intentionally leaves for the source:
- A step-by-step explanation of credential stuffing versus password spraying for practitioners building detection logic.
- Specific countermeasure guidance for bot detection, including behavioural signals and IP reputation analysis.
- Secrets management tactics for hardcoded credentials in CI/CD and infrastructure as code workflows.
- Examples of how compromised NHIs can be used to access cloud storage, deployment pipelines, and other privileged systems.
👉 Read Entro Security's analysis of credential stuffing across human and NHI access →
Credential stuffing and NHI sprawl: what IAM teams miss?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 6:44 am
Credential stuffing is no longer just a consumer login problem, it is a machine identity problem. The same reuse economics that make password reuse dangerous for users also make shared API keys, tokens, and service accounts vulnerable when they are copied across systems and left in place. That moves the issue from authentication nuisance to identity governance failure, because the compromised object is often a workload credential with real operational privilege. Practitioners should treat replay risk as part of the NHI control plane, not a separate security corner case.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
A question worth separating out:
Q: How do organisations know whether credential stuffing controls are working?
A: Look for fewer reused secrets in code and configuration, lower volumes of anomalous login attempts, faster secret rotation after exposure, and clear ownership for every service credential. A healthy programme can revoke a compromised credential quickly and see the change reflected across pipelines, APIs, and monitoring.
👉 Read our full editorial: Credential stuffing is now an NHI governance problem
