iPhone My Number Card changes are reshaping identity verification

At a glance

What this is: This is Cybertrust Japan’s analysis of how iPhone My Number Card support is likely to change the way identity verification documents are used across mobile devices and related proofing flows.

Why it matters: It matters because identity teams will need to reconcile mobile document support, assurance, and lifecycle governance across human identity processes without assuming the same verification method works identically across platforms.

By the numbers:

• An internal survey found that 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• Only 5.7% of organisations have full visibility into their service accounts.
• Certificate expiry is the leading cause of outages for 45% of organisations.
• 69% of organisations now have more machine identities than human ones.

👉 Read Cybertrust Japan's analysis of My Number Card changes for mobile identity verification

Context

Mobile identity proofing is becoming a moving target because policy, device capability, and document acceptance are changing on different timelines. For IAM teams, the key issue is not whether a phone can store or present a credential, but whether the organisation can trust the verification step across platforms, issuance states, and future document formats.

This article tracks how Japan’s My Number Card usage is expected to expand on iPhone and Android, while noting that implementation details will continue to evolve. That makes the problem one of identity governance and assurance, with knock-on effects for onboarding, re-verification, and support workflows that depend on consistent proofing standards.

Key questions

Q: How should organisations secure mobile identity verification without over-sharing personal data?

A: Use data minimisation, auditable consent, and strong binding between the presenting user, the device, and the relying party. The goal is to verify identity without turning every interaction into a reusable data export. Mobile identity should disclose only what the transaction requires, and consent should be revocable in a way that downstream systems can actually enforce.

Q: Why does mobile document support create identity governance risk?

A: Because the same identity outcome can rely on different verification paths across platforms, which makes assurance harder to standardise. If iPhone, Android, and legacy documents are accepted under different conditions, identity teams must manage policy drift, exception handling, and downstream trust decisions instead of assuming one proofing model fits all.

Q: What breaks when identity proofing is weak?

A: Weak proofing lets the organisation issue credentials to the wrong person or entity, which means later access controls are protecting an assumption that was never verified. In practice, that leads to fraud risk, onboarding mistakes, and downstream trust problems that access reviews cannot fully repair. Proofing is the foundation, not an optional pre-step.

Q: Who should own mobile identity verification policy?

A: Ownership should sit with identity and access governance, with input from security, compliance, and the teams running customer or employee onboarding. If the policy affects regulated identity proofing, the accountable group must also define how acceptance criteria, support exceptions, and downstream access decisions are reviewed and updated.

Technical breakdown

Mobile identity verification depends on platform-specific assurance paths

When identity proofing moves onto mobile devices, the security question shifts from card possession alone to the assurance path behind the transaction. A phone can present a document, but the organisation still needs to know how authenticity is established, what chip or wallet function is used, and where the trust boundary sits between device, issuer, and verification service. Human identity programmes often assume a stable proofing pattern; mobile document support breaks that assumption because platform capabilities and regulatory acceptance can differ by ecosystem.

Practical implication: Map each mobile verification flow to its assurance source before allowing it into onboarding or step-up processes.

Document acceptance is a lifecycle issue, not a user-experience detail

The article implies that identity documents will expand in phases, with different support timelines for iPhone, Android, and card formats. That is an identity lifecycle problem because the accepted proofing method may change after issuance, during renewal, or when a legacy card format is retired. Governance teams need to manage what evidence is acceptable at each stage, how exceptions are approved, and how downstream systems respond when a document type becomes obsolete or restricted.

Practical implication: Treat document acceptance rules as governed lifecycle policy, not ad hoc support guidance.

Verification consistency across devices affects IAM control design

If mobile identity verification behaves differently across device families, then enrollment, re-authentication, and recovery flows can no longer assume one common user journey. IAM teams must account for fallback methods, support escalation, and proofing parity when a user switches devices or operating systems. This is especially important where identity proofing feeds account recovery, regulated onboarding, or access to sensitive services, because inconsistency creates both fraud risk and operational friction.

Practical implication: Design fallback and recovery paths that preserve assurance when mobile proofing capabilities differ by platform.

NHI Mgmt Group analysis

Mobile identity assurance is becoming a policy problem before it is a technology problem. The article shows that support for My Number Card verification will expand through staged releases, which means the real control point is governance over when a method is considered trusted enough for use. IAM teams should read this as a reminder that assurance depends on acceptance policy, not just feature availability.

Platform-specific proofing creates a fragmentation risk for human identity programmes. iPhone and Android will not necessarily expose the same identity verification path at the same time, and that asymmetry complicates standardisation. The implication is that organisations may need separate evidence rules, support logic, and exception handling for the same identity outcome.

Document lifecycle and identity lifecycle are now tightly coupled. When card formats, wallet support, or chip-read flows change, the verification step itself changes shape. That matters for onboarding, re-verification, and recovery because a proofing method that worked at issuance may not remain the right control later in the lifecycle.

My Number Card modernisation sharpens the case for governed fallback, not uncontrolled workaround. If identity teams allow local exceptions whenever a device or document path is unavailable, assurance becomes inconsistent across channels. Practitioners should treat the fallback path as a governed policy surface, not a support convenience.

Mobile verification should be evaluated as part of the broader identity assurance stack. This topic sits across human IAM, regulated identity proofing, and workflow governance. The practical conclusion is that teams need to coordinate policy, support, and downstream access decisions before mobile identity methods become business critical.

From our research:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how quickly governance breaks down when identity inventories are incomplete.
• The 52 NHI breaches Report shows how governance failures compound when identities outlive their intended control window.

What this signals

Mobile proofing is moving the control point from device capability to policy governance. Teams that rely on static acceptance criteria will struggle as verification methods change across platforms and release windows. The safer approach is to define how proofing evidence is approved, retired, and recovered before mobile support becomes embedded in downstream IAM workflows.

For identity programmes, the real risk is not feature parity but assurance drift. When the same verification outcome can be reached through different device paths, support teams and policy owners must prevent inconsistency from spreading into onboarding and account recovery. This is where a governed lifecycle model matters more than a one-time implementation decision.

For practitioners

• Define platform-specific proofing policy Write separate acceptance rules for iPhone, Android, and legacy card workflows so identity proofing does not rely on a single assumed device path. Make the policy explicit for onboarding, re-verification, and support escalation.
• Review fallback verification paths Document what happens when a preferred mobile verification method is unavailable, including who approves the exception and what evidence is required before account creation or recovery proceeds.
• Align document retirement with lifecycle controls Track when an identity document format, chip flow, or wallet-based method becomes deprecated and ensure downstream systems stop treating it as equivalent to current verified identity evidence.
• Test consistency across support channels Validate that help desk, onboarding, and recovery teams apply the same assurance standard when users present the same identity evidence through different devices or operating systems.

Key takeaways

• Mobile identity verification is now a governance issue because acceptance paths will change by platform and by release stage.
• The main operational risk is assurance drift, where the same identity outcome is treated differently across iPhone, Android, and legacy document flows.
• Identity teams should govern fallback methods, lifecycle retirement, and downstream trust rules before mobile proofing becomes business critical.

Key terms

• Identity proofing: Identity proofing is the process of collecting and validating evidence that a person is who they claim to be. In practice, it sets the assurance level that later authentication and recovery steps depend on, so changes in proofing method can affect trust across the whole identity lifecycle.
• Assurance Level: An assurance level is the degree of confidence an organisation has that an identity proofing or authentication outcome is accurate. Higher assurance usually means stronger checks, more evidence, and more governance overhead. The key is matching assurance to the transaction risk, not applying one standard everywhere.
• Fallback Verification: A secondary identity check used when the primary authentication factor is unavailable or fails. Its security matters because attackers often target the fallback path, and weak recovery logic can become the easiest way to obtain legitimate access.
• Identity Lifecycle Governance: Identity lifecycle governance is the set of processes that create, change, review, rotate, and revoke access across human and non-human identities. It matters because access risk usually increases when lifecycle events are slow, incomplete, or disconnected from the systems that rely on them.

What's in the full article

Cybertrust Japan's full blog post covers the implementation detail this post intentionally leaves for the source:

• A phased timeline for which mobile identity verification methods are expected to work on iPhone and Android.
• The document and wallet support implications behind My Number Card verification changes.
• The specific examples of identity documents and card formats that will need policy review as the rollout progresses.
• The practical support considerations for organisations that need to adapt onboarding and verification workflows.

👉 Cybertrust Japan's full post covers the rollout timeline, device differences, and document support considerations.

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.