Paper credentials are easy to lose and counterfeit, while poorly controlled digital records can still be exposed if identity checks are weak. The main risks are fraud, broken trust at verification points, and privacy loss through overexposure of personal health data. A secure health pass should minimize copies, use authoritative sources, and make verification dependable in real time.
Why paper health credentials are easy to fake or lose
Paper credentials fail because they are physical objects with weak built-in control. They can be copied, altered, photographed, or handed to someone else without leaving a strong audit trail, so the verifier has to trust the document itself rather than the issuing system behind it. That makes fraud and identity confusion much easier at clinics, borders, workplaces, and event check-in points.
The verification problem gets worse when the paper artifact is treated as the source of truth. Without a dependable way to check issuance, expiry, revocation, or ownership, a credential can still look valid after the underlying status has changed. A secure health pass depends on the API Key Management Guide style principle of lifecycle control, except here the object is a health credential rather than an API key: if the record cannot be checked against an authoritative source, trust erodes quickly.
Paper also introduces simple operational loss. It can be damaged, misplaced, duplicated for convenience, or shared between people, and those failures are hard to detect once they happen. In practice, the weakest point is usually not the document design but the absence of a reliable verification channel at the point of use.
Why poorly controlled mobile records still create privacy and trust exposure
Digital does not automatically mean secure. If a mobile health record sits in an app with weak identity checks, broad device access, poor session control, or easy export paths, it can be exposed just as readily as paper, only at larger scale. The main difference is that compromise can happen quietly, through screenshotting, forwarded links, shared accounts, or a stolen unlocked device, rather than through visible physical theft.
That is why the control question is not whether the record is “in an app”, but whether access is bounded and verification is authoritative. A mobile credential should be tied to a trustworthy source and verified in real time, not cached in ways that create stale copies. The same design logic used for Secrets Management Guide and Guide to the Secret Sprawl Challenge applies here: once copies spread, control gets harder and exposure grows.
For health data specifically, overexposure matters because the record usually contains personally sensitive information, not just a pass/fail status. If the mobile implementation reveals more than the verifier needs, privacy loss becomes part of the security failure, especially when screenshots, cached records, or app logs preserve data after the intended transaction ends.
What makes verification dependable instead of merely convenient
Reliable verification requires three things: an authoritative issuer, a check that is hard to fake, and a result that is fresh enough to reflect current status. If any one of those is weak, the credential can still be presented but cannot be trusted with confidence. That is where paper and loosely managed mobile records diverge from a properly governed pass, because they often optimise for convenience while underinvesting in proof of authenticity.
For this reason, verification should be designed to answer a narrow question, such as “is this record valid now and bound to this person?”, rather than exposing the full underlying health record. The less data a verifier receives, the smaller the privacy blast radius if the record is intercepted or stored. A secure design also limits reuse, because a credential that can be copied into multiple contexts loses the assurance value that made it useful in the first place.
Risk and Threat Considerations
Paper and poorly controlled mobile records create a combined fraud and privacy problem. The risk is not only that someone can present a fake or copied credential, but that weak controls can turn a routine verification into a data exposure event, especially when records are cached, shared, or handled without strong authentication.
Failure mechanism: Attackers and opportunists exploit weak issuance checks, duplicate copies, screenshots, forwarded files, and unverified trust at the point of inspection. Once a record can be copied without authoritative revalidation, it becomes easier to counterfeit, reuse, or expose.
Impact: Organisations can admit the wrong person, reject the right one, or expose sensitive health information beyond what the verifier actually needs. The result is broken trust, fraud risk, and avoidable privacy loss.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Health records and credentials can leak through copies, screenshots, and uncontrolled storage. |
| NHI-07 — Long-Lived Secrets | Stale paper or cached mobile records create lasting exposure when status changes. | |
| NHI-10 — Human Use of NHI | Manual sharing, forwarding, and screenshotting often bypass intended credential controls. | |
| Recommendation — Reduce credential leakage by minimizing copies and validating records against an authoritative source. Use short-lived, revocable records and recheck validity at presentation time. Restrict human handling paths that let users copy or reuse health credentials outside the intended flow. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Verification must establish current identity or assertion validity with appropriate assurance. |
| Recommendation — Apply assurance and phishing-resistant verification patterns so the credential is checked against a trusted source. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle controls are needed to prevent stale or copied records from remaining usable. |
| IA-2 — Identification and Authentication (Organizational Users) | Verification points must reliably authenticate the user or presenter before accepting the record. | |
| AC-3 — Access Enforcement | Poorly controlled mobile records need enforcement over who can view or present them. | |
| Recommendation — Manage issuance, expiry, renewal, and revocation so records stop working when they should. Require strong authentication at the verification point before accepting a health credential. Enforce access conditions so only intended users and verifiers can view the record. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control is central when records can be viewed or forwarded beyond their intended audience. |
| A.8.12 — Data leakage prevention | The subject is fundamentally about avoiding overexposure of personal health data. | |
| Recommendation — Define and enforce access rules that limit who can retrieve or display the credential. Apply leakage controls to prevent screenshots, exports, and unintended sharing of the credential. | ||
| OWASP ASVS | V6 — Authentication | A mobile credential is only trustworthy if the user and verifier are strongly authenticated. |
| Recommendation — Require strong authentication before allowing issuance, viewing, or verification actions. | ||
Practitioner Guidance
What to verify: Confirm that the credential is checked against an authoritative source at presentation time, not accepted because it looks plausible or was previously seen. If the system cannot prove current validity, treat it as a trust problem, not a usability issue.
Decision rule: If a credential can be copied, forwarded, or photographed and still function, its assurance level is too low for sensitive health use. If a verifier needs more than the minimum status signal, redesign the flow so the pass reveals less and proves more.
What good looks like: There should be minimal copying, clear expiration or revocation behaviour, and a verification path that is dependable even when the user changes devices or the record is refreshed. The best control is the one that makes the trusted state easy to check and hard to clone.
Practitioner takeaway: For digital health credentials, the real risk is not paper versus app, it is whether the credential remains authoritative, current, and narrowly disclosed at the point of verification.
Related resources from NHI Mgmt Group
- What breaks when browser-stored credentials are not controlled?
- What breaks when identity credentials are stored only in a user-controlled wallet without strong governance?
- How should security teams handle hardcoded or poorly stored credentials in applications and automation scripts?
- What are the main implementation risks when moving from physical identity documents to a mobile digital wallet?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
