Notifications
Clear all
Topic starter
22/06/2026 5:01 pm
TL;DR: Dynamic Identifiers replace reusable secrets with short-lived, single-use confirmation tokens that bind approval to a specific session, while QIDs package the signed QR envelope and validation metadata used to verify authenticity, according to Scramble ID. That shift makes replay, forwarding, and fake-prompt abuse materially harder because the identity proof expires, cannot be reused, and must match the originating session.
NHIMG editorial — based on content published by Scramble ID: Dynamic Identifiers
By the numbers:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
Questions worth separating out
Q: How should security teams design session-bound confirmation flows?
A: Design them so the confirmation is tied to one live session, one device proof, and one short expiry window.
Q: Why do dynamic identifiers reduce replay risk compared with OTPs?
A: They reduce replay risk because the identifier is not a bearer secret and cannot be reused after success.
Q: What do teams get wrong about QR-based approval flows?
A: They often assume the QR image itself is trustworthy.
Practitioner guidance
- Classify DIDs as identifiers, not secrets Update identity design standards so teams do not route Dynamic Identifiers through secret-management controls or secret-rotation workflows.
- Bind confirmation to the originating session Require explicit session binding in every approval flow, including web, voice, and cross-device journeys.
- Validate the QID before trust changes Make signature and metadata validation atomic in the verifier so a scanned QR cannot change access state until authenticity checks succeed.
What's in the full article
Scramble ID's full article covers the operational detail this post intentionally leaves for the source:
- The exact session-binding cryptography used to tie a DID to websocket, call, or link context.
- Recommended TTL ranges and verifier behaviour for expired, late, or mismatched confirmations.
- The complete QID structure, including signature and validation metadata fields.
- Implementation guidance for emitting presented, confirmed, timeout, and mismatch events.
👉 Read Scramble ID's analysis of dynamic identifiers and QID session binding →
Dynamic identifiers and session binding: are your controls ready?
Explore further
22/06/2026 5:14 pm
Dynamic identifiers are a governance pattern, not just a UX pattern. The article shows that identity confirmation can be made safer by separating what is displayed from what is trusted. That distinction matters because IAM programmes still over-rotate on code issuance and under-specify the session and device assertions that make confirmation meaningful. For practitioners, the control question is whether approval state is bound tightly enough to the originating interaction.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure.
A question worth separating out:
Q: How do you know if a confirmation flow is actually phishing resistant?
A: Look for three things: the proof is bound to the right session, it requires an enrolled device or equivalent cryptographic proof, and it expires quickly after use. If any of those are missing, the flow may still be convenient, but it is not materially resistant to relay or forwarding attacks.
👉 Read our full editorial: Dynamic identifiers change session-bound confirmation in identity
