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: This is an analysis of how Japan’s iPhone my number card changes the practical boundary between mobile wallet convenience and legally recognised identity proofing.
Why it matters: It matters because identity teams must distinguish consumer wallet behaviour from regulated proofing, credential issuance, and assurance requirements across human IAM programmes.
By the numbers:
- 2028 年冬頃までに、本人確認にかかわる新サービスの提供開始や本人確認手法の導入、法改正が目白押しとなります。
- 2025 年 6 月 24 日にデジタル庁より「 iPhone のマイナンバーカード」提供開始に関するお知らせが公開されました。
👉 Read Cybertrust Japan's analysis of iPhone my number card and Apple Wallet identity
Context
iPhone my number card is a mobile identity proofing capability, not simply a payment-wallet feature. The article explains that Japan’s current model separates what lives in Apple Wallet from what is legally recognised as my number card functionality, and that separation matters for organisations building identity and verification flows.
For IAM teams, the key question is how regulated proofing, platform integration, and user convenience interact. This is primarily a human identity topic, but it has lifecycle implications for onboarding, attribute verification, and future authentication journeys as the government extends the model through 2028.
Key questions
A: Treat mobile identity as a proofing channel with a defined assurance level, not as a generic wallet feature. Separate the legal identity method from the device presentation layer, then write policy so relying parties know exactly what they are trusting and why.
Q: When should IAM teams re-evaluate identity verification flows for mobile credentials?
A: Re-evaluate flows whenever the proofing method, legal basis, or acceptance rule changes. If a mobile credential is expanding into new services or jurisdictions, onboarding, recovery, and re-verification should be reviewed before production reliance increases.
Q: What breaks when organisations treat a mobile wallet as equivalent to government identity proofing?
A: Trust breaks first. Teams may accept a presentation layer as if it were an assurance method, which weakens onboarding, recovery, and audit decisions. The result is a policy mismatch between what the user sees and what the relying party can safely accept.
Q: Who is accountable for identity assurance when mobile proofing methods change?
A: The relying party remains accountable for deciding what evidence is acceptable, even when the government or platform vendor supplies the proofing mechanism. Compliance, IAM, and product owners should jointly define the acceptance standard and the audit trail.
Technical breakdown
Public personal certification versus wallet presentation
The article distinguishes between the certificate used for public personal certification and the card-information layer exposed through the mobile form factor. That separation matters because a wallet can present data or interface elements without becoming the legally recognised identity method itself. In practice, this is a federation and assurance problem: a system may accept mobile-backed claims, but only if the underlying proofing method is within the approved policy boundary. The distinction also helps explain why implementation details differ across service providers and why user experience alone is not a trustworthy measure of assurance.
Practical implication: map which parts of your verification flow require legal identity proofing and which parts are only presentation or convenience.
Why iPhone my number card is not Apple Wallet
Apple Wallet and the iPhone my number card are related in the user experience, but they are not the same identity construct. The article says the legal and technical implementation paths differ, including approval, delivery, and service-provider obligations. That means organisations should not treat a wallet-held credential as interchangeable with a government-issued identity proofing mechanism. For IAM and compliance teams, the important issue is assurance provenance, not whether the credential is displayed on the same device as a payment card.
Practical implication: revise policy language so controls refer to proofing source and assurance level, not to the device wallet alone.
Lifecycle pressure from evolving mobile identity methods
The article points to 2028 changes that will expand or alter identity methods, which makes lifecycle governance more relevant than a one-time integration project. When identity proofing channels change, onboarding, revocation, attestation, and customer-service procedures all need review. This is a human identity lifecycle issue with downstream effects on access provisioning and account recovery. Organisations that build around a single mobile proofing assumption today may find their workflows brittle when newer methods arrive.
Practical implication: treat mobile identity support as a lifecycle programme and reassess enrolment, recovery, and revocation rules before policy changes land.
NHI Mgmt Group analysis
Mobile identity is becoming a regulated proofing channel, not just a convenient form factor. The article shows that the iPhone my number card is being positioned inside a legal identity framework, with separate handling for public personal certification and card information. That means practitioners cannot evaluate it as a consumer-wallet feature alone. The correct lens is human identity assurance, where proofing source and legal recognition matter more than device convenience. The implication is that mobile identity policy must be written around assurance boundaries, not brand-led user experience.
Apple Wallet and government identity credentials are not operationally equivalent. Cybertrust Japan’s summary makes clear that the mobile card and Apple Wallet follow different approval and implementation paths. That distinction exposes a recurring governance error: teams often conflate possession of a device with identity proofing strength. In practice, the trust model is determined by the credential issuer, the legal basis, and the relying party’s acceptance rules. The implication is that organisations should separate presentation from proofing in policy and architecture.
Lifecycle governance will become harder as Japan’s identity methods expand through 2028. The article’s timeline shows that proofing methods, legal rules, and service obligations will continue changing rather than stabilising around a single design. That creates a moving target for enrolment, recovery, and assurance mapping. Human IAM teams should assume that current onboarding and recovery workflows are temporary, not final. The implication is that identity programmes need change control for proofing methods, not just implementation work.
Digital identity programmes must plan for coexistence, not replacement, across physical card, mobile card, and future methods. The article notes that Android will need separate support and that newer options, including the next-generation resident card, are being considered. That means the real problem is not one credential replacing another, but a governance model that can handle multiple acceptable proofing paths at once. The implication is that relying parties need acceptance rules by identity method, not a single default flow.
Proofing controls fail when organisations confuse transaction convenience with identity assurance. The article repeatedly separates the service experience from the legally recognised method. That separation is the governing assumption that security teams must preserve. If a business treats mobile convenience as equivalent to assurance, it will overestimate the strength of onboarding and recovery controls. The implication is that assurance tiers should be explicit in every identity journey.
From our research:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs , Why NHI Security Matters Now.
- From our research: 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs , Key Challenges and Risks.
- For a broader baseline on identity exposure, see Ultimate Guide to NHIs , What are Non-Human Identities for the full definition set and lifecycle context.
What this signals
Assurance tiers will matter more than device form factors. As mobile identity methods spread, identity teams should expect regulators, auditors, and relying parties to ask for clearer proofing provenance rather than simpler user journeys. The programme risk is not mobility itself, but weak policy separation between presentation and legal identity acceptance.
Identity proofing change control needs to be treated like any other lifecycle dependency. When government methods shift, the downstream impact lands on onboarding, support, recovery, and audit evidence. Teams that do not track proofing-method change as a governed dependency will end up with brittle processes and inconsistent trust decisions.
With 69% of organisations now having more machine identities than human ones, according to our Ultimate Guide to NHIs, the broader lesson is that identity programmes are already managing multiple identity classes at once. That makes careful method-specific governance for human proofing even more important.
For practitioners
- Separate proofing from presentation in policy Document which flows accept a legally recognised proofing method and which flows only use a mobile presentation layer. Keep the approval rules and relying-party obligations explicit in the control set.
- Review onboarding and recovery paths now Map how identity enrolment, re-verification, and account recovery will change as mobile identity methods expand through 2028. The goal is to remove dependence on a single proofing route before the policy changes arrive.
- Define acceptance rules by identity method Create method-specific trust policies for physical card, mobile card, and future resident-card variants. Do not let a device form factor decide assurance automatically.
- Align IAM and compliance teams on assurance tiers Translate the legal and technical differences between certificate-based proofing and wallet presentation into control language that audit, help desk, and product teams can all use.
Key takeaways
- The article’s core point is that mobile identity must be judged as a regulated proofing method, not as a wallet convenience feature.
- The biggest governance risk is conflating presentation, legal recognition, and relying-party acceptance into one control decision.
- IAM teams should prepare for multiple coexisting proofing methods by making assurance levels, recovery paths, and acceptance rules explicit.
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, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the technical controls, while GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63A | The article centers on identity proofing and enrollment for a human identity use case. |
| NIST CSF 2.0 | PR.AC-1 | Access and identity decisions depend on clear identity proofing and authentication governance. |
| NIST Zero Trust (SP 800-207) | The topic affects trust decisions at the identity boundary in a zero-trust model. | |
| GDPR | Art.32 | The article touches personal identity data and assurance handling in a regulated context. |
Apply Art.32-style safeguards to identity data flows and constrain access to proofing-related attributes.
Key terms
- Identity Proofing: Identity proofing is the process of establishing that a person is who they claim to be before granting access or issuing a credential. In practice, it combines evidence collection, validation, and assurance scoring so relying parties can make a defensible trust decision.
- Assurance Level: An assurance level is the degree of confidence an organisation assigns to an identity assertion or credential. Higher assurance usually requires stronger evidence, better source trust, and tighter lifecycle controls, especially when the identity method is used for regulated or high-risk transactions.
- Relying Party: A relying party is the organisation or service that accepts an identity assertion and acts on it. It remains responsible for deciding which proofing methods are acceptable, how much trust to place in them, and what audit evidence is needed when those methods change.
- Action Layer: The action layer is the point where an identity moves from asking for access to doing something with that access. For AI agents, this layer matters because tool use can happen faster than human review, and the meaningful risk appears when actions are chained across systems.
What's in the full article
Cybertrust Japan's full blog covers the operational detail this post intentionally leaves for the source:
- The full Japanese explanation of how the iPhone my number card maps to legal identity proofing rather than consumer wallet behaviour.
- The step-by-step differences between Apple Wallet usage, public personal certification, and the card-information functions described in the article.
- The implementation and approval distinctions for service providers that need to support the new mobile identity model.
- The forward-looking discussion of how 2028 policy and product changes may alter identity verification journeys.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 12, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org