TL;DR: Credential theft from reused passwords, infostealers, personal laptops, AI tools, and unprotected apps still creates account risk even when the original breach was old, according to 1Password. The important shift is that protecting identity now depends on layered controls, unique credentials, MFA, passkeys, and secret handling beyond the login screen.
At a glance
What this is: This is a 1Password article arguing that credential exposure remains a live account-risk problem even after older breaches, because reused credentials and secret sprawl still create exposure beyond the login screen.
Why it matters: It matters because IAM and NHI programmes have to govern where credentials live, how they are reused, and how quickly exposed secrets can be replaced across user, workload, and household contexts.
Context
Credential exposure is the problem of secrets being copied, reused, or stolen in places other than the intended authentication flow. In practice, that means the risk often starts long before a login page and continues after a breach is disclosed, especially when passwords are reused or stored in weakly governed locations.
For IAM teams, this is not just a consumer password hygiene issue. The same pattern shows up across personal accounts, household access, development environments, and infrastructure secrets, which is why credential handling has to be treated as a lifecycle control rather than a one-time login control.
Key questions
Q: What should teams do first when reused credentials may already be exposed?
A: Reset the affected passwords or tokens immediately and remove any reuse across related accounts. If the same secret appears in personal, shared, or production environments, rotate it everywhere it was reused so the original exposure cannot be replayed later.
Q: Why do old identity records still create account takeover risk?
A: Old records remain useful because usernames, email addresses, and names can be matched with other breach corpora and credential stuffing lists. If users reuse passwords, the attacker may gain access without needing the original breach to include login data. That is why exposed profile data should be treated as an input to account takeover campaigns, not as harmless history.
Q: How should security teams protect non-human identities from infostealers?
A: Security teams should reduce the value of any stolen credential by combining secret discovery, short-lived issuance, runtime attestation, and narrow authorization scope. The goal is not to prevent every theft. It is to make stolen NHI material expire quickly and fail outside the context where it was issued.
Q: How should organisations govern passwords, passkeys, and secrets together?
A: They should manage them as one identity trust chain, not as separate security projects. That means common ownership, shared lifecycle rules, and unified exception handling for enrolment, recovery, rotation, and revocation. The goal is to keep the same identity policy consistent whether the credential is a password, a passkey, or a runtime secret.
Technical breakdown
Why reused credentials remain exploitable after an old breach
A reused password is still valid even if the breach that exposed it happened years ago, because attackers do not need the original incident to stay active. Once a credential is known, it can be replayed anywhere the same secret was reused, and infostealers make this worse by harvesting passwords, session data, and stored secrets from endpoints and apps. The technical issue is not breach age. It is whether the same credential can still authenticate across multiple services without detection or revocation. That turns one exposure event into an extended account-risk window.
Practical implication: inventory credential reuse across user accounts and shared systems, then remove duplicate secrets before they become a replay path.
How infostealers expand credential exposure beyond the browser
Infostealers are endpoint malware that harvests secrets from places users do not think of as authentication systems, including personal laptops, AI tools, and unprotected applications. That broadens the attack surface from classic login forms to cached credentials, local storage, clipboard data, and exported tokens. The important shift is that secret compromise can happen without a cloud-provider breach or direct password guessing. Once stolen, those credentials can be used for account takeover, session theft, or secondary compromise depending on what the secret unlocks and whether MFA or device binding blocks reuse.
Practical implication: treat endpoints and unmanaged apps as credential collection points and reduce what can be stolen locally.
Why secrets handling now matters for both human and infrastructure accounts
The article’s mention of API keys, database logins, cloud secrets, SSH keys, and passkeys shows that account risk now spans both human and non-human identities. Human login risk and infrastructure secret risk share the same core failure mode: secrets are stored, copied, and reused in places where lifecycle control is weak. That creates a governance gap, because a team can have strong login policies and still leave workload credentials exposed in plaintext, browser stores, or shared channels. In modern identity programmes, credential handling is one control plane across people and systems, not two separate problems.
Practical implication: govern passwords, passkeys, tokens, and infrastructure secrets as one lifecycle domain instead of separate hygiene tracks.
Threat narrative
Attacker objective: The attacker wants unauthorized access to accounts, credentials, and the downstream systems or data those secrets protect.
- Entry occurs when an attacker obtains reused passwords or other exposed credentials from leaked data, infostealers, or unprotected applications.
- Credential abuse follows when the stolen secret is replayed against services that still accept it because it has not been rotated or invalidated.
- Impact occurs when the attacker gains unauthorized account access or uses the exposed secret to reach additional personal or infrastructure assets.
Breaches seen in the wild
- PyPI admin GitHub token leak 2024: A PyPI admin's GitHub token with admin rights over Python and PyPI repos sat in public Docker images for 15 months before JFrog found it.
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Credential exposure is now a lifecycle problem, not a password problem: Old breach data remains dangerous because credentials survive the incident that exposed them. Reuse, local storage, and weak offboarding keep secrets valid long after the original leak is forgotten. The programme implication is that identity governance has to manage secret provenance, not just authentication events.
Endpoint compromise is now part of identity compromise: Infostealers collapse the old boundary between endpoint security and access governance by harvesting credentials from personal laptops, AI tools, and unprotected apps. That means account risk is created outside the login screen and often outside the IAM team’s traditional visibility. Practitioners should treat endpoint secret exposure as an identity source-of-truth problem.
Secret sprawl is the named concept that explains this risk pattern: credentials now exist in browsers, password reuse sets, developer tools, household accounts, and infrastructure automation. Once secrets sprawl, revocation becomes slower than exposure, and the attack window stays open longer than most review cycles assume. The implication is that governance has to assume distributed secret custody, not a single protected vault.
Human and non-human identities now share the same failure mode: the article’s guidance on MFA, passkeys, password managers, and Secrets Automation shows that the same exposed-secret logic applies across personal accounts and workload credentials. That convergence matters because teams that separate human IAM from NHI governance miss the fact that the secret, not the user interface, is the real control boundary. Practitioners should align lifecycle controls across both domains.
Strong login controls do not compensate for weak secret distribution: MFA and passkeys reduce replay risk, but they do not fix plaintext storage, reused passwords, or exposed API keys. A mature programme has to control where secrets live, how they move, and how quickly they are replaced when compromise is suspected. The practitioner conclusion is clear: identity security now starts with secret custody.
What this signals
Secret custody has become the control plane: IAM programmes can no longer assume that credential risk begins and ends at login. Once credentials are copied into browsers, endpoint caches, AI tools, and infrastructure files, the governing question becomes where the secret exists, who can replay it, and how quickly it can be removed from circulation.
The practical consequence is that password policy alone is no longer a sufficient control story for either human or non-human identities. Teams need a lifecycle view that spans issuance, storage, reuse, detection, and revocation, because exposed secrets do not respect the boundary between consumer identity and workload identity.
For practitioners
- Use unique credentials everywhere Eliminate password reuse across personal, family, developer, and production accounts so one exposed secret cannot unlock multiple services.
- Enable MFA and passkeys broadly Require MFA wherever it is available and move to passkeys for services that support them, especially where password replay would otherwise remain viable.
- Remove plaintext infrastructure secrets Automate secure delivery of API keys, database logins, and cloud secrets so they are not copied into files, chats, or shared environments.
- Monitor for exposed or reused secrets Use breach monitoring and credential health checks to find weak, reused, or exposed secrets before attackers can replay them.
- Treat household accounts as part of the identity perimeter Review family or shared accounts with the same discipline used for individual accounts, because reused credentials in one household can still create account risk.
Key takeaways
- Credential exposure remains dangerous long after the original breach because reused secrets still authenticate if they are not rotated or invalidated.
- The article’s examples point to a broader risk pattern that includes infostealers, endpoint storage, family accounts, and infrastructure secrets, not just leaked passwords.
- IAM teams should govern secret custody end to end, because layered authentication only works when exposed credentials are actually removed from circulation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on exposed credentials leaking beyond intended custody. |
| NHI-07 — Long-Lived Secrets | Reused passwords and lingering secrets keep old breaches actionable. | |
| NHI-10 — Human Use of NHI | The article covers human reuse of passwords and shared credential habits. | |
| Recommendation — Scan for leaked secrets and revoke any credential that appears outside approved storage. Shorten secret lifetimes and eliminate credentials that remain valid after exposure. Separate human credential handling from workload secret handling and stop cross-use. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential rotation and authenticator lifecycle are central to the article’s guidance. |
| Recommendation — Enforce authenticator rotation and revoke exposed credentials under IA-5. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account lifecycle and reuse reduction sit at the heart of the article. |
| Recommendation — Review account and credential assignments to remove reuse and stale access. | ||
Key terms
- Credential exposure: The condition where a secret, token, key, or certificate becomes visible to a system or user that should not have direct access to it. In AI-assisted workflows, exposure can happen through prompts, files, or agent-accessible directories, which makes containment and runtime gating essential.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
- Infostealer: An infostealer is malware built to collect credentials, session material, tokens, and other authentication data from infected systems. In NHI programmes, the risk is not only theft but reuse, because harvested workload secrets can unlock cloud access long after the initial infection.
- Secrets Automation: Secrets automation is the managed delivery, storage, and rotation of infrastructure credentials without relying on plaintext handling. It reduces the chance that API keys, database logins, or cloud secrets remain usable after exposure. The goal is to shorten the time a secret stays valid and make manual leakage less likely.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org