An attended use case is a verification or transaction flow where a person and a verifier interact in real time, either face to face or through a live remote channel. In mobile identity programs, it helps define scenarios where the credential is presented under direct human oversight.
How Attended Use Case Works
An attended use case is a live verification or transaction flow, so the defining feature is not just that a person is present, but that the person is actively participating while the verifier observes and confirms the event in real time. That human oversight changes how assurance is established, because the flow depends on immediate observation rather than deferred review.
This pattern is common in identity programs that need stronger confidence than unattended self-service can provide. The verification may happen face to face or through a supervised remote channel, but in both cases the core idea is that the credential presentation or transaction is occurring under direct human control.
Where Attended Use Case Fits in Identity Verification
The term is most useful when distinguishing supervised flows from unattended ones. In practical terms, it helps separate scenarios that can tolerate self-asserted steps from those that require a verifier to witness the event, assess the person, and decide whether the transaction should proceed.
That distinction matters because the assurance value comes from the interaction itself. If the verifier is not present in real time, the use case is no longer attended in the sense this term describes, even if the same identity proofing or transaction policy is involved.
In mobile identity programs, the attended model often supports higher-assurance enrollment, credential presentation, or exception handling. It is especially relevant where a program needs a controlled checkpoint for identity evidence, device interaction, or transaction approval.
Common Variations and Operational Boundaries
Attended does not always mean physical in-person. A live remote session can still qualify when the verifier is actively present and able to observe the interaction as it happens. What matters is the immediacy of oversight, not the channel.
That said, attended use cases still need clear boundaries. A live meeting with no real decision authority is not enough, and an asynchronous review process is not attended even if someone eventually looks at the evidence. The term is about the timing and oversight model, not just the existence of a human somewhere in the workflow.
Why the Attended Model Changes Assurance
Because a verifier is present, attended flows can support stronger judgment, exception handling, and interaction-specific checks than purely automated flows. They also create a more explicit chain of responsibility for who observed the event and accepted the outcome.
This makes the model useful when trust depends on immediate human confirmation, such as confirming presentation quality, resolving ambiguity, or deciding whether the presented evidence is sufficient for the transaction at hand. It is a procedural assurance pattern as much as a technical one.
Risk and Threat Considerations
Attended use cases reduce some forms of abuse, but they do not remove risk. A weak live process can still be defeated by poor verifier judgment, superficial review, social engineering, session hijacking in remote channels, or allowing the human reviewer to become a rubber stamp.
Failure mechanism: The control fails when real-time oversight is treated as a formality instead of an active verification step, allowing an attacker or ineligible participant to pass through on the strength of process theater rather than evidence.
Impact: The result can be unauthorized enrollment, fraudulent transaction approval, weakened trust in the credential lifecycle, and downstream exposure whenever the attended event is assumed to provide higher assurance than it actually did.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 and NIST SP 800-53 Rev 5 set the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines assurance and supervised identity proofing concepts for attended verification flows. |
| Recommendation — Use supervised identity-proofing requirements to define when live verification is required. | ||
| NIST SP 800-53 Rev 5 | IA-12 — Identity Proofing | Attended verification often serves identity proofing where a human reviewer confirms presented evidence. |
| IA-2 — Identification and Authentication (Organizational Users) | Attended use cases often support stronger authentication decisions during live verification. | |
| Recommendation — Apply identity proofing controls to require the right level of live verifier oversight. Align live verification steps with authentication requirements that match the assurance target. | ||
| GDPR | EU General Data Protection Regulation | Attended identity flows may process biometric or identity evidence and require lawful handling. |
| Recommendation — Ensure live verification flows handle personal data with appropriate purpose and protection. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Attended use cases are a controlled access and verification pattern that depends on governed approval. |
| Recommendation — Define approval authority and access conditions for attended verification workflows. | ||
Practitioner Guidance
Governance implication: Treat “attended” as a defined operating mode, not a vague service label. Programs should specify what counts as live oversight, who the verifier is, what authority they hold, and what evidence must be observed before the event is accepted.
What to watch for: The main failure signal is when staff begin approving cases without truly observing the interaction or when remote sessions drift into delayed review. If the verifier cannot intervene in real time, the use case should not be treated as attended.
Related resources from NHI Mgmt Group
- How do IAM teams decide whether an AI use case needs new controls or better NHI hygiene?
- How do organisations decide whether encrypted computation is enough for a use case?
- How do security teams decide whether biometrics are appropriate for a use case?
- How should organisations centralise AI use case and model inventories?
