The proofing step stops at the device boundary, so the organisation cannot reliably capture and transfer IC card evidence into the identity platform. That creates a break in the assurance chain, especially in regulated onboarding where the verification result must be attributable, traceable, and complete.
What Stops at the Device Boundary
When an iPad workflow has no external card reader, the proofing process can still collect whatever the tablet itself can see, but it cannot complete the full card-based evidence transfer. That means the organisation loses a reliable bridge from the physical credential to the identity record, which is the part that turns a local scan into auditable proofing evidence.
For regulated onboarding, that boundary matters because the proofing outcome is not just “did the user show something” but “can the evidence be captured, preserved, and attributed in a way the identity platform can trust later.” Without the reader, the workflow becomes device-limited rather than evidence-complete.
Why the Assurance Chain Fails
The assurance chain breaks when the system cannot move from observation to verified evidence. In practice, an external card reader is often what lets the app read the card consistently, validate it against the intended proofing flow, and pass a result that downstream systems can rely on. Identity Proofing and KYC Guide is the most direct reference for how document evidence, proofing strength, and onboarding assurance fit together.
This is not just a usability issue. It changes the integrity of the onboarding record, because the organisation may end up with an incomplete verification path, a weaker assurance level, or a result that cannot be defended in audit terms. In card-based proofing, the quality of the evidence transfer is part of the control, not a nice-to-have transport detail.
Missing hardware can also push teams into workarounds that look convenient but are harder to govern, such as manual re-entry, screenshots, or out-of-band validation. Those options may produce a business outcome, but they usually weaken traceability and make it harder to prove that the same identity was checked against the same evidence at the same time.
What Practitioners Should Treat as Broken
The first thing that breaks is evidentiary continuity: the organisation cannot cleanly show how the card evidence moved from the physical object into the identity workflow. The second is control consistency: proofing success may vary by device, app version, or operator behaviour rather than by policy. The third is downstream trust, because onboarding, approval, and exception handling all depend on the result being complete and attributable.
That is why this should be treated as an identity assurance defect, not a simple peripheral failure. If the reader is missing, unavailable, or unsupported, the team should assume the proofing path is degraded until the evidence chain is restored. NIST SP 800-63 Digital Identity Guidelines remains the clearest external reference point for assurance-driven identity proofing expectations, while NHI Lifecycle Management Guide helps frame the broader operational requirement to keep identity evidence, ownership, and lifecycle state aligned.
Risk and Threat Considerations
When the proofing step cannot capture card evidence reliably, the main risk is false assurance: the organisation may believe it has completed a governed verification when it has only completed a partial device interaction. That creates exposure in regulated onboarding, exception handling, and later dispute resolution, where missing or weak evidence becomes a control gap.
Failure mechanism: the workflow cannot transfer trustworthy card-derived evidence into the identity platform, so the record loses continuity, traceability, or completeness.
Impact: onboarding decisions may rest on incomplete verification, audits may fail to reconstruct the proofing path, and the organisation may have to re-proof users or accept a weaker trust posture.
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 ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Identity proofing assurance and evidence quality are central to this onboarding failure. |
| Recommendation — Apply assurance-level proofing requirements and verify the evidence chain before accepting onboarding results. | ||
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | External onboarding relies on proofing and authentication of the person being enrolled. |
| Recommendation — Use external-user identity proofing controls to ensure the verified subject matches the onboarding record. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity records must remain attributable and governed across the proofing lifecycle. |
| A.5.17 — Authentication information | The proofing workflow depends on trustworthy authentication and evidence handling. | |
| Recommendation — Maintain governed identity records and retain proofing evidence that supports later audit and review. Protect proofing-related authentication information and ensure it is captured without integrity loss. | ||
Practitioner Guidance
What to verify: confirm that the proofing flow can produce a complete, replayable evidence trail, not just a successful screen result. If the reader is absent, test whether the platform records the same proofing artefacts, timestamps, and operator context that regulated onboarding expects.
Decision rule: if card evidence cannot be captured and transferred with traceability intact, treat the onboarding step as incomplete and route it to an approved fallback rather than accepting a partial success. That fallback should be policy-defined, not improvised by the operator.
Practitioner takeaway: the control objective is evidence continuity, so the question is not whether the iPad can “do something useful”, but whether it can produce proofing output the organisation can trust, defend, and audit later.