TL;DR: Japan’s Digital Agency has set out how the iPhone my number card will combine public personal certification and card surface information, while separating it from Apple Wallet, and notes further changes through 2028, according to Cybertrust Japan’s summary of the 2025 update. The operational issue is not the mobile wallet label itself, but which identity proofing and attribute sources are legally recognised and how organisations must adapt their verification flows.
At a glance
What this is: Cybertrust Japan explains that Japan’s iPhone my number card update distinguishes Apple Wallet from the legally recognised identity proofing functions and sets a longer transition path through 2028.
Why it matters: Identity and access teams need to understand that mobile presentation, legal proofing, and service-provider implementation are not the same control, especially when identity evidence must be mapped to approved sources.
Context
This is an identity proofing and digital credential governance change, not simply a mobile wallet feature update. The article focuses on how Japan’s legal and operational rules distinguish the iPhone my number card from Apple Wallet, and why that distinction matters to service providers that rely on verified identity attributes.
For IAM and verification teams, the key issue is the source and legal status of identity evidence. The article says the iPhone-based card can support public personal certification and card-surface information, but the implementation path differs from Apple Wallet and changes continue across 2025, 2026, and 2028.
That makes this a programme design question as much as a user-experience question. Organisations that consume identity proofing signals will need to map which claims are accepted, how they are delivered, and which workflows must change when the legal method and the device surface are not the same thing.
Key questions
Q: How should organisations decide whether a mobile identity method is acceptable for onboarding?
A: Base the decision on the legally recognised proofing method and the assurance it provides, not on whether the credential appears in a wallet or on a phone. If the service cannot name the accepted method and the evidence it produces, the onboarding rule is too vague for regulated identity use.
Q: What are the main governance risks in wallet-based identity flows?
A: The main risks are weak issuer trust, poor revocation handling, inconsistent assurance levels, and unclear consent records. If those controls are not explicit, selective disclosure can create uncertainty about what the relying party is allowed to trust, which turns portability into fragmented decision-making instead of stronger governance.
Q: What should teams review before supporting a new mobile identity credential?
A: They should review acceptance policy, evidence provenance, legal basis, and service-provider implementation dependencies. The key question is whether the credential changes how identity is proven or only how it is presented, because those two cases require different controls.
Q: How do organisations keep identity proofing rules aligned when the law changes over time?
A: Use versioned policy and staged implementation governance. Track legal recognition, technical support, and customer-facing workflow updates separately, so a partial rollout does not become an unexamined permanent assumption in the access journey.
Technical breakdown
Legal identity proofing versus wallet presentation
The article draws a sharp line between identity proofing functions and wallet presentation. In practice, a wallet can store or present credentials, but that does not make every stored item a legally recognised proofing method. For IAM teams, the important distinction is between the transport or user surface and the trusted assertion that downstream systems accept. That distinction matters when a government-backed identity source is being exposed through a consumer device, because the trust decision still depends on the approved method, not the icon on the screen.
Practical implication: Map each verification step to the legally accepted proofing method, not to the wallet interface the user happens to open.
What changes when card-surface information becomes mobile
The article says the iPhone my number card includes both public personal certification and card-surface information, but those functions are not interchangeable. Public personal certification is about authenticated identity use, while card-surface information is the static or displayed information associated with the card. When those elements move onto a phone, organisations need to separate what is being asserted, what is being shown, and what is being signed or approved. That separation is essential for customer onboarding, regulated service access, and any workflow that depends on attribute provenance.
Practical implication: Treat displayed identity attributes as evidence input, then confirm which attributes can actually drive an authorised decision.
Why phased legal change creates implementation risk
The article describes a staggered schedule through 2028, with changes affecting new services, proofing methods, and legal definitions over time. Phased change often creates a governance gap because teams assume one mobile identity pattern will cover all future cases. In reality, the service-provider obligations, approval path, and supported proofing channels can diverge by date and use case. That means design decisions made for the first rollout may not hold when later legal or technical changes arrive.
Practical implication: Build your identity programme so proofing rules, service integration, and legal acceptance can be updated independently.
NHI Mgmt Group analysis
Identity proofing is being decoupled from the device wallet layer: The article shows that the legal question is not whether an identity lives inside Apple Wallet, but whether the proofing method itself is recognised. That matters because governance failures often begin when presentation and assurance are treated as the same control. Practitioners should separate credential display from proofing authority in their design.
Card-surface data and public personal certification are different trust objects: The article’s distinction between the two means teams cannot treat every mobile identity signal as equivalent. One is a governed certification path, the other is contextual card information, and downstream acceptance should differ accordingly. This is a classic attribute provenance problem, not a UI problem, so verification policy must reflect the source of each claim.
Phased legal rollout creates an identity lifecycle problem, not a one-time integration task: The article’s 2025 to 2028 schedule implies that support for mobile proofing will evolve over multiple policy and implementation stages. That creates drift risk if organisations freeze their onboarding logic after the first release. The right lens is lifecycle governance across legal recognition, technical integration, and customer-facing verification.
Digital identity modernisation now depends on source-of-truth governance: The strongest signal in the article is that Japan is defining what counts as accepted proofing, not merely changing how a card is stored. That pushes IAM teams to think in terms of authoritative sources, assurance boundaries, and method-specific acceptance rules. The practitioner conclusion is simple: if the accepted source is unclear, the verification workflow is not ready.
Mobile identity programmes need method-specific policy, not channel-specific assumptions: A phone-based identity method does not automatically inherit the semantics of the wallet, the device, or the app. The article illustrates why identity policy must be written around assurance method and legal basis, then mapped to channels afterward. Practitioners should expect more, not less, policy fragmentation as mobile identity options expand.
What this signals
Method-specific acceptance will become the deciding control: As mobile identity options expand, the governance challenge shifts from whether a credential can be shown on a device to whether a specific proofing method is acceptable for a specific service. Teams should expect policy to become more granular, not less, because the same device surface can carry different assurance outcomes.
The practical lesson for IAM programmes is to separate identity evidence, user experience, and legal recognition into distinct control layers. That approach reduces the risk of building a verification flow that looks modern but cannot survive a regulator, auditor, or service-provider review.
For practitioners
- Define method-level acceptance rules Document which identity proofing methods are legally accepted for each service, and do not infer acceptance from the presence of a wallet or phone-based display alone.
- Separate proofing from presentation Review onboarding and authentication flows so card-surface information, wallet presentation, and public personal certification are handled as different trust inputs.
- Rework service-provider dependencies Check which application and web-service journeys rely on a single mobile identity path, then identify where alternate proofing methods will be needed as legal rules change.
- Plan for phased policy change Build a change calendar that tracks legal recognition, technical support, and customer communications separately through the 2025 to 2028 transition period.
Key takeaways
- The article is really about proofing governance, not about mobile wallet branding or device convenience.
- Japan’s update separates legally recognised identity evidence from the Apple Wallet layer, which changes how service providers should think about trust.
- IAM teams need method-specific policy and phased rollout planning so a new mobile identity channel does not outrun the controls that govern it.
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 CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63A — Enrollment and Identity Proofing | The article centres on how identity proofing methods are legally recognised and consumed. |
| SP 800-63C — Federation | The article concerns how identity assertions are carried through service-provider integrations. | |
| Recommendation — Align onboarding rules to the accepted proofing method and assurance level for each service. Map mobile identity assertions to the federation path that actually receives and evaluates them. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | This is about how identity evidence becomes an access decision in downstream services. |
| Recommendation — Tie service access decisions to documented evidence sources and authorisation rules. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity Management | The article is fundamentally about identity governance and the management of recognised identity methods. |
| Recommendation — Document which identity methods are accepted and keep the policy aligned to legal change. | ||
Key terms
- Identity proofing: The process of verifying that a person is who they claim to be before granting or restoring access. In higher-risk recovery paths, proofing can include stronger evidence checks such as government ID validation or liveness-based facial verification so the assurance level matches the sensitivity of the request.
- Public Personal Certification: Public personal certification is a formal identity assurance mechanism that lets a service rely on a recognised, verified personal identity claim. It is not the same as a wallet presentation layer. For practitioners, the key question is which claims are certified, by whom, and under what legal basis the certification can be accepted.
- Card-Surface Information: Card-surface information is the identity data shown or carried on a card or card-like interface, such as name or date of birth. It may support a verification flow, but it is not automatically a certified proofing method. Organisations should treat it as evidence input unless policy explicitly elevates it.
- Identity Provenance: Identity provenance is the record of how an agent was created, what authority it received, and what actions it performed over time. It turns agent activity into an auditable chain of trust that supports compliance, incident response, and post-event accountability.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on July 12, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org