They should separate contextual detection from identity proof. Risk scoring decides when to challenge, but the access decision should rely on a stronger mechanism at high risk, such as liveness verification or another resistant proofing method that cannot be easily shared or intercepted.
Why This Matters for Security Teams
zero trust programmes often get identity proof wrong at the exact moment risk spikes. They may detect unusual device posture, location, or session behaviour, then still rely on the same weak login artifact to prove identity. That creates a gap between challenge timing and proof strength. NIST SP 800-207 Zero Trust Architecture frames access as continuous verification, not a one-time trust event, which makes the quality of proof at the point of access critical.
For human users, a high-risk access request should not be treated as equivalent to a normal one. For NHIs, the issue is even sharper because secrets can be copied, replayed, or embedded in automation. NHIMG research shows that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, yet only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. In practice, many security teams encounter identity abuse only after a valid credential has already been replayed across systems, rather than through intentional proof hardening at access time.
How It Works in Practice
Zero trust programmes should separate two decisions: whether to increase scrutiny, and how to prove identity. Risk engines can use context such as geo-velocity, device health, impossible travel, or workload anomalies to decide whether the session needs stronger proof. The actual access grant should then rely on a proofing method resistant to sharing and interception, such as liveness verification for humans or cryptographic workload identity for NHIs.
For workforce access, stronger proof may mean phishing-resistant authentication paired with step-up verification. For machine access, the more durable control is workload identity, where the system proves what the agent or service is through signed tokens, attestation, or SPIFFE-based identities rather than static secrets. The Guide to SPIFFE and SPIRE explains why cryptographic identity is better suited to service-to-service trust than shared credentials. That aligns with the OWASP Non-Human Identity Top 10, which treats credential exposure and over-privilege as recurring failure modes.
- Use risk signals to trigger step-up challenges, not to replace proof.
- Prefer resistant proofing methods that cannot be easily forwarded, copied, or replayed.
- For NHIs, issue short-lived, scoped credentials tied to workload identity rather than reusable static secrets.
- Re-evaluate access at request time, not only at login, so the decision reflects current context.
This guidance breaks down in environments that still depend on shared service accounts, legacy VPN access, or flat networks where identity cannot be bound cleanly to the requesting workload.
Common Variations and Edge Cases
Tighter identity proof often increases friction, so organisations must balance user experience against the risk of credential replay and session takeover. Current guidance suggests there is no universal standard for every access scenario: the right proofing method depends on whether the subject is a person, a device, or an autonomous workload.
One common edge case is step-up authentication that is triggered correctly but still satisfied with the same factor the attacker already possesses. That weakens the control. Another is service-to-service access where a team assumes zero trust has been implemented because TLS is in place, even though the underlying identity is a long-lived secret stored in code or CI/CD. NHIMG research notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, which makes point-of-access proof especially fragile during automation-heavy workflows.
For NHIs, best practice is evolving toward ephemeral credentials, short TTLs, and policy enforcement at request time. For humans, organisations should favour resistant proofing that is hard to phish or relay. For both, the key mistake is treating risk scoring as identity proof rather than a trigger for stronger proof. That distinction is what keeps zero trust from becoming a policy label without operational teeth.
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 CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-7 | Zero trust access decisions depend on proving identity at request time. |
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture centers on continuous verification and dynamic access decisions. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Point-of-access proof for NHIs fails when shared or long-lived secrets are used. |
Require stronger proof when context changes and verify access continuously, not once.
