A phishable credential is any login factor that can be tricked, copied, or relayed by an attacker, such as passwords, OTPs, SMS codes, or push approvals. These factors may improve security over a password alone, but they still depend on secret sharing and are vulnerable to interception or social engineering.
Expanded Definition
A phishable credential is a login factor that can be captured, relayed, or socially engineered by an attacker, including passwords, one-time codes, SMS messages, and push approvals. In NHI security, the term matters because an agent, workload, or automation pipeline may be protected by a factor that appears stronger than a password but still depends on secret disclosure or human confirmation.
Definitions vary across vendors when authentication is layered, because some products label OTP-based or push-based flows as “multi-factor” even though they remain phishable under adversary-in-the-middle or consent phishing conditions. The distinction is important in identity governance: a phishable credential can authenticate a session, but it does not necessarily resist real-time interception, replay, or coercion. The most useful external baseline is the NIST SP 800-63 Digital Identity Guidelines, which separates authenticator strength from phishing resistance.
For NHI programs, this concept often overlaps with secret handling, delegated access, and human approval paths. A system can look compliant while still relying on an approval tap, a shared token, or a code that an attacker can capture through a fake login prompt. The most common misapplication is treating any second factor as phishing-resistant, which occurs when teams ignore whether the factor can be relayed in real time.
Examples and Use Cases
Implementing phishing resistance rigorously often introduces friction in login and recovery flows, requiring organisations to weigh usability and operational speed against interception risk.
- Password plus SMS code for a service account portal, where a phisher can redirect the code in real time.
- Push approval for an administrator login, where consent fatigue can turn the factor into an attacker-controlled grant.
- OTP shared with a support channel during incident recovery, which creates an exposure path outside intended access controls.
- Legacy API access protected by a manually entered token, which may be copied from logs, chat, or clipboard sync.
- Credential relay attacks against cloud identities, a pattern discussed in the LLMjacking: How Attackers Hijack AI Using Compromised NHIs research note and reinforced by the OWASP Non-Human Identity Top 10.
In practice, teams also encounter secret distribution problems that make phishable credentials easier to steal, especially when access material is copied into chat tools or emailed during onboarding. NHIMG’s Guide to the Secret Sprawl Challenge and the Ultimate Guide to NHIs — Static vs Dynamic Secrets show why static, human-transcribable factors remain vulnerable even when they are wrapped in formal IAM workflows.
Why It Matters in NHI Security
Phishable credentials are a major weak point because NHI environments multiply the number of places where a stolen factor can be reused: CI/CD pipelines, cloud consoles, agent orchestration layers, and recovery channels. Once a phishable factor is accepted as sufficient proof, an attacker does not need to break the system, only to persuade a human or intercept the session at the right moment. That risk is amplified when the credential unlocks privileged automation or connects directly to secrets and tokens.
NHIMG research shows that only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, and 23.7% report sharing secrets through insecure methods such as email or messaging applications. That combination is dangerous because phishable factors often sit upstream of broader secret exposure. The 2024 Non-Human Identity Security Report connects this maturity gap to dynamic credential demand, while NIST SP 800-53 Rev 5 Security and Privacy Controls frames the control expectation for authentication, access restriction, and credential lifecycle discipline.
Organisations typically encounter the true impact only after a relay, takeover, or approval abuse event exposes downstream workload access, at which point phishable credential handling becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST-NI-600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Phishable login factors often expose the same secret risks covered by NHI credential controls. |
| NIST SP 800-63 | AAL2 | The guideline distinguishes phishing-resistant authenticators from relayable factors like OTPs. |
| NIST CSF 2.0 | PR.AA-1 | Identity proofing and authentication practices must resist interception and replay. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification, not trust in a single captured factor. | |
| NIST-NI-600-1 | GenAI systems need authentication patterns that withstand prompt and consent abuse. |
Replace relayable factors with phishing-resistant access paths and review secret handling for NHI-02 exposure.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
