An unattended use case is a transaction or verification flow that occurs without a live human reviewer present at the moment of access or presentation. For mobile driver’s licences, this usually means remote digital interactions where the system must validate the credential and supporting signals automatically.
What an Unattended Use Case Is in Practice
An unattended use case is a verification or transaction flow that must succeed without a person manually checking the credential at the point of presentation. That makes the system itself responsible for deciding whether the signal set is strong enough to trust.
This matters because unattended flows are not just a convenience feature, they change the trust model. The design has to assume latency, remote presentation, replay attempts, and inconsistent device or network conditions, while still producing a reliable accept or reject outcome.
Why Unattended Flows Need Strong Automated Verification
The core challenge is that no reviewer can compensate in real time for weak evidence, so the automated checks must carry the full burden of validation. For mobile driver’s licences and similar digital credentials, that usually means combining credential integrity checks, issuer trust validation, presentation context, and fraud-resistant verification signals.
When the flow is unattended, the control surface moves from human judgment to protocol design and signal quality. If the system accepts too little evidence, it creates a false accept path; if it demands too much, it turns a useful digital flow into a brittle one that fails for legitimate users.
How Unattended Use Cases Differ From Human-Reviewed Verification
In a human-reviewed flow, an operator can notice anomalies, ask follow-up questions, or spot mismatches that the system did not explicitly model. In an unattended flow, those judgments must be pre-authored into the workflow, policy, and verification logic.
That difference affects both assurance and user experience. The unattended model is usually faster and more scalable, but it also makes hidden assumptions more dangerous because there is no live fallback at the moment of decision. This is why unattended verification is often paired with stricter issuer validation, stronger presentation rules, and careful handling of edge cases.
Common Design Boundaries and Failure Modes
Unattended use cases work best when the credential can be checked against trustworthy data sources and the presentation channel is resistant to tampering. They become weaker when the verifier cannot confirm freshness, context, or provenance with enough confidence.
Typical failure modes include stale or replayed presentations, incomplete device or session assurance, weak identity binding, and overreliance on a single signal. A good unattended design treats those as workflow risks, not minor implementation details, because they determine whether the automated verdict is defensible.
Risk and Threat Considerations
Unattended verification concentrates risk in the automated decision path, so any weakness in validation, freshness, or issuer trust can be exploited at scale. The main concern is that a forged, replayed, or insufficiently bound presentation may be accepted without anyone noticing at the moment of use.
Failure mechanism: An attacker targets the automated acceptance logic, for example by replaying a valid presentation, abusing a weak trust check, or exploiting a gap between credential validity and current session reality.
Impact: False acceptance can expose downstream systems, enable unauthorized access, or undermine confidence in the entire unattended channel, especially where the flow is used repeatedly across high-volume verification events.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Unattended verification depends on authenticated access decisions for the relying system. |
| IA-5 — Authenticator Management | Unattended flows depend on trustworthy credentials, tokens, and their lifecycle controls. | |
| AU-2 — Event Logging | Automated acceptance decisions need traceable records for later review and dispute handling. | |
| Recommendation — Use IA-2 to require strong authentication before unattended access decisions are made. Apply IA-5 to manage credential issuance, rotation, and revocation for unattended verification. Log unattended verification outcomes and supporting signals for audit and investigation. | ||
| NIST SP 800-63 | Digital Identity Guidelines | The subject is a digital identity verification flow that hinges on assurance and presentation rules. |
| Recommendation — Use the Digital Identity Guidelines to align unattended verification with assurance and binding requirements. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Remote unattended verification fails when presentation or session authentication is weak or replayable. |
| Recommendation — Harden authentication paths so unattended verification cannot be bypassed with weak or replayed credentials. | ||
Practitioner Guidance
What to watch for: Treat unattended use cases as assurance workflows, not just digital convenience. The practical question is whether the system can validate enough current, context-aware evidence to stand on its own when no human is present.
Governance implication: Assign clear ownership for the trust policy, fallback handling, and exception path so that unattended decisions are reviewable when assurance assumptions change. If the system cannot explain why it accepted a presentation, the flow is usually too weak for unattended use.
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?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
