Attended Use Case

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.

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?