Sim Card unique Identification

Thank you for the interesting post.

Unfortunately, without knowing anything about your app, it seems like a privacy issue as would be a problem if third-party apps could access unique SIM identifiers (such as the ICCID, IMSI, IMEI, or phone number) due to privacy and security policies.

You can ask and check for wifi or cellular access and make sure the user has internet access. Because you cannot rely on local APIs, your app must handle states where the SIM cannot be verified (e.g., Airplane mode with Wi-Fi on).

Hope this helps answer your question?

Albert
  Worldwide Developer Relations.

What Albert said plus…

Most folks who ask about this are trying to satisfy some government or industry security regulation. Is that the case here? If so, which one?

One example of such regulation is UPI, which has a specific affordance in the Messages UI framework, namely the -setUPIVerificationCodeSendCompletion: method.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks, Albert and Quinn, for the responses.

To add context: this app is owned by Safaricom, and one of its core functions is mobile money transfer. We can identify the phone number linked to the SIM card only when the user is on mobile data (because they are on our network). This check is critical for confirming that the transaction SIM is physically in the device.

Because of this, during onboarding we allow only mobile data. After login, users can transact over Wi-Fi.

The gap is this: if a user powers off the phone, swaps the SIM card, and then opens the app on Wi-Fi, we cannot confirm whether the current SIM is the original one. Transactions can still continue.

In a fraud scenario, if someone social-engineers a user’s app PIN, they could switch off the phone, insert a different SIM, and access the user’s app over Wi-Fi.

Albert, we already have the checks you mentioned, but there is still a loophole as long as we cannot uniquely verify the SIM card.

Quinn, this is mainly an industry-level security capability we want: ensuring the app is operating with the same SIM used during onboarding, whether the user is on Wi-Fi or mobile data.

We have the API that exposes subscriber.identifier, however our observation is that this value represents a subscription/slot reference rather than a stable identifier for the SIM itself. From our use case (fintech fraud prevention), we are trying to determine whether there is any supported way to derive a consistent, privacy-preserving identifier for the currently inserted SIM.

Specifically:

Is there any mechanism to obtain a hashed or tokenized representation of the SIM/subscriber identity (e.g., ICCID/IMSI-derived, but not exposing raw values)?

Alternatively, are there any Apple-recommended approaches to uniquely distinguish between different SIM cards over time on the same device, while remaining compliant with platform privacy constraints?

Our goal is not to access sensitive data directly, but to have a stable signal that allows us to detect when the SIM has changed, particularly for high-risk scenarios such as session hijacking on a previously trusted device.

Is there any mechanism to obtain a hashed or tokenized representation of the SIM/subscriber identity … ?

No.

You could file an enhancement request for that, but I don’t fancy its chances. Such an API could be used for fingerprinting, which is something that Apple is actively working against. See the footnote about entropy at the bottom of this reply.

are there any Apple-recommended approaches to uniquely distinguish between different SIM cards over time … ?

No, but an ER along those lines seems more viable to me.

The gap is this

One way to close that gap would be for you to stand up a web service that allows your app to request some sort of authorisation token when that service is accessed over WWAN. Your app could then force that request to run over WWAN, get the token, and apply it to the real requests running over Wi-Fi. This would eat a small amount of mobile data, but much less than it would if you forced the entire transaction to run over WWAN.

Forcing a request to run over WWAN is not trivial, but it’s definitely possible, especially when it’s a low-complexity request like this one. See Extra-ordinary Networking > Running an HTTP Request over WWAN.

Obviously such a design would need a proper security audit — to limit the lifetime of these tokens, protect against replay attacks, and so on — but I think the overall approach is feasible.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"