Organisations should treat the mobile credential as the controlled delivery channel, not the test itself. They need consent, strong owner matching, secure issuance, and audit receipts so the result is tied to the right person and can be shared safely. The goal is to reduce manual handling, prevent misassignment, and keep the individual in control of disclosure.
Why identity proofing changes when a health result is delivered in a mobile credential app
When a health result is issued into a mobile credential app, the proofing problem shifts from “did we test someone?” to “did we bind the result to the correct person, device, and disclosure channel?” The app becomes part of the controlled issuance path, so organisations need stronger owner matching, secure enrollment, and a way to prevent a valid result from being attached to the wrong user or copied into an uncontrolled channel.
That means proofing has to cover both the person and the wallet-like app environment that will receive the result. If the app is treated as a convenience layer only, misassignment becomes the main failure mode: the result may be genuine, but the recipient or sharer may not be. Consent and auditability matter because the organisation is not just recording a test outcome, it is creating a shareable assertion about an individual’s status.
Operationally, the key design choice is whether the app is acting as a presentation layer, a verification layer, or both. The more the organisation relies on the app to carry trust across settings, the more it needs secure issuance, reproofing for exceptions, and clear rules for revocation and re-issuance when a device changes, a credential is lost, or ownership is disputed.
How to share results without losing individual control
Result sharing should be consent-driven, purpose-limited, and traceable. The person should be able to disclose the result selectively, while the organisation retains enough evidence to prove what was issued, to whom, when, and under what assurance level. NHIMG’s guide to non-human identities is useful here because the same governance pressure appears whenever a credentialed channel is used to carry an identity assertion rather than a raw record.
Secure sharing also depends on receipt design. A good implementation logs issuance, access, and presentation events without exposing unnecessary personal or clinical detail. Where the result can be forwarded, printed, or screen-captured, the organisation should assume the original trust boundary may be lost and should prefer short-lived presentation references, revocation paths, and recipient verification over static links or reusable files.
For health-testing workflows, the safest model is to minimise manual handling after the result exists. The app should receive the result through a tightly controlled issuance path, then let the individual decide whether to present it, export it, or withhold it. That preserves autonomy while reducing the chance that staff mediate disclosure in ways that create confusion, delay, or privacy exposure.
What good control looks like in practice
Good control combines identity proofing, secure issuance, and auditable presentation into one workflow. The organisation should be able to confirm that the right person enrolled the app, that the result was issued to the intended record, and that any subsequent sharing followed the user’s consent. The result should be easy to verify, but not easy to repurpose outside its intended context.
A practical implementation usually needs three things: strong initial owner matching, lifecycle handling for lost or replaced devices, and a clear exception path when the mobile channel cannot be trusted. NHIMG’s NHI lifecycle management guide is relevant because issuance, rotation, revocation, and offboarding are the same control problems even when the “credential” is a health result rather than a service secret.
The other useful check is whether the recipient can prove provenance without needing access to more data than necessary. If the verification experience forces over-disclosure, the design is too broad. If it is too opaque, staff cannot trust the result. The balance point is a verifiable assertion with a narrow, documented disclosure path.
Risk and Threat Considerations
The main risks are misassignment, unauthorized disclosure, and weak lifecycle control over the mobile credential. Once a health result is tied to a sharable app, any failure in enrollment, consent, device handling, or revocation can create a privacy incident even if the underlying test was accurate.
Failure mechanism: Weak owner matching or poor device binding can attach a valid result to the wrong person, while reusable links, screenshots, or stale credentials can let a result escape its intended sharing boundary.
Impact: Organisations can expose sensitive health information, create false acceptance or refusal decisions, and lose confidence in the credibility of the result channel, especially if users can no longer prove what was shared or withdrawn.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | The subject hinges on identity proofing, binding, and controlled disclosure. |
| Recommendation — Enforce identity binding and access governance for issuance, presentation, and revocation of the result. | ||
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | External users must be strongly bound to the mobile credential before issuance. |
| IA-5 — Authenticator Management | The mobile credential needs lifecycle controls for issuance, revocation, and replacement. | |
| AC-3 — Access Enforcement | Sharing controls depend on enforcing who may view or present the result. | |
| Recommendation — Use IA-8 to verify the recipient before issuing the health result into the app. Manage the credential lifecycle so lost or replaced devices can be revoked and reissued safely. Enforce disclosure rules so only the intended holder can present or share the result. | ||
| GDPR | Art.5 — Principles relating to processing of personal data | Health-test results are sensitive personal data and must be shared with purpose limitation and minimisation. |
| Recommendation — Limit collection and sharing to the minimum necessary and keep disclosure purpose-bound. | ||
Practitioner Guidance
What to verify: Confirm that the enrollment flow produces a durable binding between the individual, the device, and the result record before any result is issued into the app. If the organisation cannot evidence that binding, do not treat the mobile channel as authoritative.
Decision rule: If the result can affect access, attendance, or compliance decisions, require revocation and re-issuance capability from day one, not as a later enhancement. If the app cannot support that lifecycle, fall back to a controlled manual process for exceptions.
Practitioner takeaway: Treat the mobile app as a controlled disclosure mechanism, not as proof by itself, and design the workflow so identity proofing, consent, and audit trail all survive device loss, forwarding, and user disputes.
Related resources from NHI Mgmt Group
- How should organisations handle mobile identity proofing without confusing it with wallet convenience?
- How should organisations use mobile driver’s licenses in identity proofing?
- How should organisations handle fake document risk in identity proofing workflows?
- How should organisations secure mobile identity verification without over-sharing personal data?
