Organisations should use a privacy by design model that stores credentials on the user’s device, encrypts each attribute separately, and lets the holder choose what to disclose in each situation. The verifier should receive only the minimum data needed for the transaction. That approach reduces unnecessary data collection, supports selective disclosure, and gives users practical control over personal information.
Why Mobile ID Needs User-Controlled Disclosure
Mobile ID only gives users meaningful control when the wallet, the issuer, and the verifier are designed around data minimisation rather than convenience. If a deployment asks for a full identity record when only age, residency, or account ownership is needed, the system quietly turns a privacy feature into a broad data capture channel. The design goal is not just authentication; it is limiting unnecessary exposure while still proving the claim the transaction actually requires.
That is why selective disclosure matters operationally. When each attribute is separately protected and the holder can choose what to reveal, the verifier gets less data to retain, forward, or misuse. Current guidance suggests this is one of the most practical ways to reduce over-collection in mobile credential ecosystems. NIST’s Security and Privacy Controls is useful here because the privacy outcome depends on disciplined access, logging, and minimisation controls around the disclosure flow.
In practice, many programmes discover that “user choice” disappears as soon as a verifier defaults to requesting the whole credential instead of the smallest acceptable claim.
How Selective Disclosure Works in Practice
A well-designed mobile ID deployment separates credential storage from disclosure. The credential remains on the user’s device, usually protected by device security and cryptographic keys bound to that wallet. When a verifier needs evidence, the wallet assembles only the claims needed for that specific interaction, rather than sending the entire identity payload. That can mean proving over-18 status, confirming a membership claim, or asserting a licensed status without exposing the rest of the record.
Attribute-level encryption is important because it prevents one disclosure decision from automatically revealing everything else. Each attribute should have its own protection boundary, and the wallet should make disclosure decisions in context, not just on a fixed policy screen. The verifier should also be designed to request only the minimum necessary data, because privacy by design fails when every downstream system assumes it is entitled to collect a copy of the source credential. The Ultimate Guide to NHIs — Standards is relevant as a governance reference for minimisation, lifecycle discipline, and control expectations around stored credentials and trust boundaries.
- Issue only the attributes needed for the transaction.
- Bind disclosure to the verifier’s stated purpose and trust level.
- Keep device-held credentials encrypted and scoped to the wallet.
- Log the transaction outcome without copying unnecessary personal data into the verifier’s system.
Where this breaks down is in environments that treat mobile ID as a scanned document replacement, because document-style workflows tend to normalise full-data capture even when the business need is narrow.
Common Design Tradeoffs and Edge Cases
Tighter disclosure controls often improve privacy but can add friction for verifiers, integrators, and support teams. Some transactions genuinely need more than one attribute, and some regulated use cases require stronger provenance or audit evidence than a basic selective-disclosure flow can provide. The design challenge is to distinguish those cases from legacy habits that request excess data simply because the system is capable of receiving it.
There is also a trust tradeoff. If the user controls what is shared, the verifier must rely more heavily on cryptographic assurance, policy enforcement, and issuer trust than on visual inspection or centralised database lookups. That is usually the right direction, but it requires stronger integration discipline. Best practice is evolving toward contextual disclosure rules, shorter retention at the verifier, and user prompts that make the impact of each disclosure clear before consent is given.
One practical edge case is revocation or freshness. A privacy-preserving mobile ID still needs a way to show that a credential or claim remains valid without exposing more identity data than necessary. Organisations should be careful not to solve that with blanket identifier collection, because “just in case” data retention quickly defeats the original privacy objective.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 — Identity Management, Authentication and Access Control | Selective disclosure depends on tightly scoped access to identity claims. |
| PR.DS-1 — Data-at-Rest Protection | Credential storage on-device requires strong protection of stored identity data. | |
| PR.DS-5 — Data Leakage Prevention | The design goal is to prevent unnecessary identity data from leaving the wallet. | |
| Recommendation — Restrict verifier access to only the claims needed for each transaction. Encrypt mobile credentials and protect stored attributes at rest. Minimise disclosure paths so unverifiable extra data is not shared. | ||
| CIS Controls v8 | 6.3 — Data Protection | Mobile ID should limit collection and sharing of personal data to what is needed. |
| 4.1 — Establish and Maintain a Secure Configuration Process | Wallet and verifier behavior must be configured to avoid default over-sharing. | |
| Recommendation — Apply data protection controls to limit collection, retention, and sharing. Configure mobile ID workflows to request the minimum required attributes. | ||
| NIST SP 800-63 | IAL2 — Identity Assurance Level 2 | User-controlled disclosure is tied to identity proofing and attribute assurance. |
| AAL2 — Authenticator Assurance Level 2 | Mobile wallet access must protect the user-controlled credential from misuse. | |
| Recommendation — Use the appropriate assurance level for the claims each verifier needs. Protect wallet access with an authenticator strong enough for the disclosed claims. | ||
Practitioner Guidance
What to prioritise: Start with the verifier’s data request, not the wallet UI. If the transaction can be completed with a single claim, remove every other field from the default path so the disclosure model is genuinely minimised.
What to verify: Check that each disclosed attribute has a clear purpose, a defined retention limit, and a traceable trust relationship back to the issuer. If a verifier cannot justify why it needs the full credential, treat that as a design defect rather than a policy preference.
Common mistake: Teams often preserve privacy on paper but leak it in implementation by copying wallet outputs into logs, CRM systems, or fraud tools. That creates a second disclosure channel that users never agreed to.
Practitioner takeaway: The strongest mobile ID deployments do not ask users to “trust privacy”; they make over-collection unnecessary by design, then prove that unnecessary data never enters the transaction in the first place.
Related resources from NHI Mgmt Group
- How should organisations implement mobile ID so it improves user convenience without weakening identity assurance?
- How can organisations prove they have control over agent actions?
- What are the signs that a mobile ID programme is not delivering the privacy and security it promises?
- How do organisations operationalise NHI ownership at scale?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
