Check whether the device or token is truly bound to the user, whether loss or theft can be revoked quickly, and whether shared or unmanaged devices are excluded. If the possession factor cannot be reliably enrolled and revoked, the assurance gain is far weaker than it appears.
Why This Matters for Security Teams
Possession-based authentication looks simple on paper, but teams have to judge whether the factor is actually bound to the claimant, whether revocation is fast enough to matter, and whether the device can be trusted in the first place. That is why current guidance from NIST Cybersecurity Framework 2.0 pushes organisations toward measurable identity assurance rather than assuming a token alone equals strong authentication.
The practical problem is that “something you have” is often a laptop, phone, browser session, hardware key, or app token, and each carries different assurance. A stolen device with a persistent session is not the same as a phishing-resistant cryptographic authenticator with reliable device binding and remote revocation. NHI Mgmt Group has also shown how secrets frequently linger in exposed places, with only 20% of organisations having formal offboarding and revocation processes for API keys in the Ultimate Guide to Non-Human Identities, which is a useful reminder that possession controls fail when lifecycle management is weak. In practice, many security teams discover the gap only after a lost token, copied cookie, or unmanaged device has already been used successfully.
How It Works in Practice
Teams usually decide possession-based authentication is strong enough by testing four things: binding, revocation, resistance to replay, and operational scope. Binding asks whether the authenticator is cryptographically tied to the device or user session, rather than merely stored on it. Revocation asks how quickly the factor can be invalidated after theft, compromise, or employee offboarding. Replay resistance checks whether a copied token, cookie, or exported credential can be reused elsewhere. Operational scope asks whether the method is permitted on managed endpoints only, or whether shared and personal devices are also in play.
In practice, strong possession factors are often paired with device posture checks, hardware-backed keys, and short-lived sessions. That is why JetBrains GitHub plugin token exposure matters as an example: the possession of a valid token was not enough to guarantee safety once the token escaped its intended control boundary. For broader identity governance, NIST CSF 2.0 is strongest when organisations map possession factors into access policies, logging, and response workflows instead of treating them as standalone proof of trust.
A useful decision pattern is:
- Accept possession-based authentication for low- to moderate-risk access only when the factor is device-bound and revocable within minutes, not days.
- Treat browser sessions and exported tokens as weaker than hardware-backed authenticators because they are easier to copy and harder to contain.
- Require step-up checks for privileged actions, especially where the session can be hijacked or the endpoint cannot be enrolled reliably.
- Prefer phishing-resistant authenticators where the threat model includes social engineering, token theft, or session replay.
These controls tend to break down in bring-your-own-device environments with weak endpoint management, because the organisation cannot consistently prove device state or revoke possession quickly enough.
Common Variations and Edge Cases
Tighter possession controls often increase user friction and support overhead, so organisations have to balance stronger assurance against operational reality. That tradeoff is especially visible when teams compare hardware security keys, mobile push approvals, and software tokens.
Best practice is evolving, but current guidance suggests treating mobile push as weaker than cryptographic possession factors when the app can be proxied, SIM-swapped, or enrolled on an unmanaged phone. Hardware-backed authenticators are usually stronger, yet they still depend on lifecycle discipline, because a lost key that is not revoked promptly provides only temporary protection. Shared kiosks, call centres, and contractor fleets are harder still, since the possession factor can be valid while the surrounding device and session context remain untrusted.
For this reason, teams should not ask only “is there possession?” but “is possession meaningful under our operating conditions?” If the answer depends on manual revocation, inconsistent endpoint control, or exceptions for high-risk users, the factor is probably not strong enough on its own. That concern aligns with broader NHI governance, where exposed credentials and weak offboarding routinely turn nominally strong authentication into a liability rather than a control.
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 SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Identity proofing and authenticator strength shape whether possession is trustworthy. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Weak credential lifecycle makes possession factors easier to steal and reuse. |
| NIST SP 800-63 | AAL2 | Authenticator assurance levels help judge whether possession evidence is strong enough. |
Enforce short-lived, revocable possession credentials and review offboarding for stale secrets.
Related resources from NHI Mgmt Group
- How do teams evaluate whether wallet-based authentication is actually improving security?
- How do IAM teams decide whether a SaaS management platform is strong enough for governance?
- How do teams decide whether browser-based app integration is good enough?
- What do teams get wrong about token-based authentication in microservices?
