The Identity Layer You Don't Own and Can't Patch
A patch fixes a flaw on a device you manage. It does nothing about the part of your identity stack that lives inside a carrier's customer-service workflow, where a phone number can change hands because a call center support agent was convinced to move it.
That is the uncomfortable shape of mobile identity in 2026. The phone number remains embedded in too many authentication and recovery flows — the destination for one-time passcodes, password resets, and account-recovery steps — and control over who holds that number sits with the carrier, not the enterprise. SIM-swap and port-out fraud are the mechanism that turns that arrangement into account takeover, and they require no exploit, no malware, and no CVE.
Do the uncomfortable audit before the weekend. Pick the accounts that would hurt if they fell: executive email, identity provider admin, finance, cloud consoles, anything that can move money or reset access. Then strip away the security theater. If the phone number behind one of those accounts moved to someone else's device tonight, would your program stop the takeover, or would it just document the loss after the fact?
Field Evidence
The phone number is identity infrastructure the enterprise does not control.
SIM-swap fraud works by getting a carrier's call center support agent to move a victim's number to an attacker-controlled SIM or eSIM. Port-out fraud moves the same number to a different carrier entirely. Either way, the attacker now receives the calls and texts meant for the victim, including the one-time passcodes protecting email, banking, and enterprise accounts.
That is the control gap. Your enterprise can harden the device, tighten the policy, and audit the identity provider. But if account recovery still trusts SMS, a carrier support workflow can become the path around your entire stack.
The FCC's enforcement materials describe the downstream weakness plainly: SMS-based recovery turns number takeover into account takeover. The exposure is not inside the enterprise stack. It is the dependency your stack created on an identity asset someone else can reassign.
The federal rules exist. Enforcement and implementation still matter.
The FCC adopted its SIM Swap and Port-Out Fraud Order in November 2023, with requirements for secure customer authentication before SIM changes or number ports, customer notification, account-lock options, employee training, and fraud-response processes. The compliance timeline was complicated by Paperwork Reduction Act and OMB review, but the direction of federal policy is settled: carriers are expected to harden the process by which numbers are reassigned. Major US carriers now offer account-lock, number-lock, SIM-protection, or port-out-protection features.
For an enterprise, the takeaway is not "the rules exist" — it is that carrier-side controls are not consistent enough to carry crown-jewel account recovery.
eSIM made the swap quieter, and the QR code is the new seam.
The eSIM insights' "eSIM is leaving telecom behind" frame names the commercial sprawl security teams now have to account for. Once eSIM becomes a travel product, fintech feature, enterprise control layer, event add-on, device requirement, and embedded checkout experience, the phone number follows it into more onboarding flows, recovery paths, customer journeys, and operational handoffs the enterprise does not fully own.
The move from physical SIM cards to eSIM changed the fraud surface by removing one of the few remaining points of friction in a number takeover: the need to obtain, ship, insert, or physically handle a card. Remote provisioning now lets a number move to a new device through a QR code or device-to-device transfer, both standard user flows designed to make legitimate activation faster.
That convenience has a security cost. If the wrong person can trigger the transfer, receive the provisioning path, or exploit a weak carrier support workflow, the number can move before the victim or the enterprise has a practical chance to see what happened. The identity provider may still treat the phone number as stable and trusted while the recovery codes, one-time passcodes, and verification messages are already landing on the attacker's device.
The QR code is not the whole problem. It is the visible seam in a broader trust chain: who requested the transfer, who approved it, where the provisioning path was exposed, and whether any party outside the carrier can detect the reassignment fast enough to matter. As eSIM moves further into travel, finance, enterprise management, and embedded customer journeys, the identity surface sprawls with it.
An exploited Android flaw still belongs in the same conversation.
CVE-2025-48595, an Android Framework integer-overflow vulnerability that can allow local privilege escalation and code execution, was added to CISA's Known Exploited Vulnerabilities catalog on June 3, 2026, with a federal remediation deadline of June 6, 2026 and confirmed active exploitation. Federal agencies are bound by that date under Binding Operational Directive 22-01; enterprises should treat it as the reference point.
The reason it belongs in this issue is simple: device compromise and number takeover both end at the authentication layer. One gives the attacker control through the endpoint. The other gives the attacker control through the recovery path. Either way, the account is the prize.
The Control Gap
Run the Token Persistence Audit against your accounts that would hurt most if lost.
Most enterprise mobile programs still start with the device: managed, patched, encrypted, compliant. That view misses the carrier-held phone number sitting outside the program but inside the recovery path. Executive email, the identity provider, financial systems, privileged admin consoles, and cloud control planes may all depend on a number the enterprise does not own and cannot reassign back once an attacker controls it.
For each crown-jewel account, trace what happens if the attacker controls the phone number on file. Check the primary factor, the fallback factor, and the account-recovery path. If an SMS one-time passcode, text-message recovery link, or support-assisted reset can get them in, then a carrier workflow your enterprise cannot see has become an access path into the account.
The correction is operational, not theatrical: remove phone numbers from second-factor and recovery flows for accounts that matter, move those accounts to phishing-resistant authentication, and leave SMS only where the business impact is low enough to justify the exposure. A phone number can stay useful for convenience. It should not be the control standing between an attacker and a critical account.
The full identity-layer methodology is in the 2026 Mobile Risk Report →
Founders Read
For years the standard advice was "turn on two-factor authentication," and SMS was good enough because it raised the bar over a password alone. That was true then. It quietly stopped being true once attackers industrialized the carrier side — building target profiles from data brokers, scripting the social-engineering call, and exploiting the fact that a phone number can be moved by a process the account owner has no visibility into.
What gets me is how durable the blind spot is. A security team can run a mature device program — managed, patched, encrypted — and still leave executive accounts recoverable through a text message to a number a stranger can talk a call center into reassigning. The device side gets the attention because it is the side the enterprise controls. The carrier side gets ignored because it is the side it doesn't.
The honest move is to stop treating the phone number as a security control and start treating it as a convenience an attacker can take. Then protect the accounts that matter accordingly.
— William
One Thing Worth Doing This Week
Map the SMS recovery path for your ten highest-value accounts.
List the ten accounts whose loss would do the most damage — the identity provider, executive and finance email, privileged cloud and admin consoles, the wire-transfer system. For each, answer one question: if an attacker controlled the phone number on file, could they get in or reset their way in? Check both the second-factor setting and the account-recovery flow, because recovery is where SMS often hides even when the primary second factor is something stronger.
Sort the results into two columns. Column one: accounts where a number takeover changes nothing because they use phishing-resistant authentication with no SMS fallback. Column two: accounts where a number takeover is a way in. Column two is your actual SIM-swap exposure, and it is almost always shorter to fix than it looks — usually a recovery-flow change, not a platform migration.
The output is a board-reportable list of which crown-jewel accounts depend on an identity asset the enterprise does not own, and a plan to cut that dependency. That is a stronger answer than "we have MFA," because it names exactly which MFA would survive a carrier failure and which would not.
Every Friday. Five items. One action.
📬 Subscribe to The Friday Brief on LinkedIn — Every Friday's issue, delivered to your LinkedIn notifications.
If SMS is still in the recovery path, the carrier is part of your identity stack whether your architecture diagram admits it or not.
Which of your crown-jewel accounts would survive a carrier handing your number to someone else?
#MobileSecurity #CISO #IdentitySecurity #SIMswap #cybersecurity