Borrowed legitimacy is when an attacker uses a valid account, session, or trusted application path to appear normal inside the environment. The danger is not simply access, but access that blends into expected behaviour and delays detection while the attacker moves toward data or administrative targets.
Expanded Definition
Borrowed legitimacy describes a compromise pattern where an adversary does not need to invent a new identity path. Instead, they use an account, session, token, or trusted application route that already looks acceptable to controls, logs, and operators. In NHI security, this matters because the attacker’s behaviour can resemble routine machine activity, especially when the path belongs to a service account, API client, CI/CD job, or delegated application.
This term is closely related to identity impersonation, but it is narrower in practice: the legitimacy is “borrowed” from a real, permitted source, not created through brute force alone. Definitions vary across vendors when this behavior is grouped with session hijacking, token theft, or trusted-path abuse, so practitioners should focus on the operational effect rather than the label. NIST SP 800-53 Rev. 5 treats related risks through access control, audit, and credential management expectations, which is why borrowed legitimacy is best understood as a control failure across identity lifecycle, not only a detection problem.
The most common misapplication is assuming any valid authentication event is low risk, which occurs when teams ignore who is using the credential path and what the session is actually doing.
Examples and Use Cases
Implementing detection for borrowed legitimacy rigorously often introduces more telemetry, tighter correlation logic, and additional response friction, requiring organisations to weigh faster anomaly detection against operational overhead.
- A compromised CI/CD runner uses its normal deployment token to reach production resources, blending in as expected automation. The CI/CD pipeline exploitation case study shows how trusted build paths can become attacker cover.
- An attacker steals a service account token from a code repository and reuses it to call internal APIs with no obvious login failure.
- A cloud workload authenticates correctly, but the session is diverted to enumerate secrets, pivot laterally, or alter permissions.
- A trusted integration account is used during off-hours to access data that the application normally never touches, making the behaviour look like system maintenance.
- A valid Git credential is reused after exposure in source history, similar to patterns seen in Millions of Misconfigured Git Servers Leaking Secrets, where exposed secrets become legitimate-looking entry points.
These scenarios are usually not noisy at the point of entry. The challenge is that the attacker operates through a real identity path that security tools may already trust.
Why It Matters in NHI Security
Borrowed legitimacy is a core NHI risk because it turns identity trust into concealment. When a service account, API key, certificate, or delegated workload credential is abused, defenders may see successful authentication instead of compromise. That is why NHI controls must go beyond issuance and include rotation, offboarding, privilege trimming, and continuous verification. NHIMG research shows that 97% of NHIs carry excessive privileges, which gives a borrowed path far more reach than most organisations expect. The same research also shows that only 5.7% of organisations have full visibility into their service accounts, making suspicious use hard to distinguish from normal automation.
This risk is especially severe in environments where secrets are stored in code, CI/CD systems, or misconfigured repositories, because the attacker can inherit the trust already attached to those credentials. The practical lesson is that borrowed legitimacy often persists until a control failure becomes visible in data access, privilege escalation, or integrity impact. Organisations typically encounter the consequence only after an unusual action is attributed to a trusted account, at which point borrowed legitimacy 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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Borrowed legitimacy commonly depends on exposed or misused secrets and trusted machine identities. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access limits how far a borrowed account or token can move laterally. |
| NIST Zero Trust (SP 800-207) | None | Zero Trust assumes authenticated activity still requires continuous verification and context checks. |
| NIST SP 800-63 | AAL2 | Assurance levels help frame how strong the credential and session proofing must be for machine access. |
| OWASP Agentic AI Top 10 | A1 | Agentic systems can abuse delegated tools and sessions that appear legitimate to downstream controls. |
Match NHI authentication strength to the sensitivity of the workload and enforce stronger proof where needed.
Related resources from NHI Mgmt Group
- Why do borrowed sessions create risk for AI agents?
- What breaks when agents rely on shared credentials or borrowed user identities?
- How should organisations reduce the risk of borrowed identities in high-value environments?
- What breaks when an AI system uses borrowed user credentials for CMMC-scoped work?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
