The Weakest Factor You Do Not Control: SIM Swap, eSIM Porting and the Mobile Carrier as an Account Takeover Surface in 2026

There is a control in almost every bank's authentication estate that the bank did not build, cannot test, cannot monitor, and cannot fix. It is the mobile number. It sits behind password resets, one-time passcodes, out-of-band confirmations, device enrolment, contact-centre verification and — in many institutions — the final approval step for high-value payments. Its integrity depends entirely on the identity, fraud and customer-service processes of a mobile network operator with whom the bank has no contractual relationship and, in most cases, no data-sharing arrangement at all.

SIM swap is not a new attack, and the industry has periodically declared it managed. What has changed through 2026 is the surface. The migration to embedded SIM profiles has removed the physical constraint that once slowed the attack down: there is no plastic to post, no store to visit, no courier delay. An eSIM profile can be provisioned to a device in minutes, remotely, through a self-service channel, which converts a logistics problem into a pure identity-verification problem — and identity verification against a carrier is exactly what generative tooling and industrial-scale breach data have made easiest.

The consequence is a compressed attack window and a much weaker relationship between the bank's control and the risk it is supposed to mitigate. Institutions that hardened their login journeys with phishing-resistant factors have generally left recovery, enrolment and contact-centre verification leaning on the number. That is the door now being used, and it is a door in a building the bank does not own.

Regulatory and Market Context

The authentication framework is clear about outcomes and largely silent about supply chains. Strong customer authentication requirements demand independent elements from knowledge, possession and inherence categories, and dynamic linking for remote payment transactions.

A one-time passcode delivered by text is conventionally treated as a possession factor, and the assumption underneath that treatment is that possession of the number implies possession of the device. eSIM provisioning is a direct and increasingly routine assault on that assumption. Supervisory commentary in several jurisdictions has for some time discouraged reliance on messaging-based codes where stronger factors are available, and firms should read the direction as settled even where the rules have not yet caught up.

Operational resilience and third-party risk frameworks impose a second set of expectations that are more awkward than they first appear. Where an important business service depends on a third party, firms are expected to identify the dependency, understand it and manage it. A bank whose customer authentication depends on mobile network integrity has such a dependency, and in most cases it has never been mapped, because the carrier is not a supplier of the bank — it is a supplier of the customer. That is a genuine structural gap in third-party risk methodology rather than an oversight by any individual firm.

Telecoms regulation has moved, though unevenly. Several jurisdictions have imposed enhanced identity verification and delay requirements on porting and SIM replacement, and some have mandated or encouraged data-sharing interfaces that allow financial institutions to query whether a number has recently changed SIM or been ported. Where these interfaces exist and are consumed, they are among the highest-value fraud controls available for the cost. Coverage across operators, virtual network operators and jurisdictions remains partial, and the customer-consent and data-protection basis for querying is handled differently from market to market, which is the practical obstacle firms most often cite.

What the Data Is Showing

TrustSphere's engagement data shows a consistent sequence, and its most important property is that most of it happens outside the bank's field of view. It begins with target selection, which is rarely random: attackers work from breach and social data to identify individuals with both a plausible balance and an identifiable carrier, and business owners, cryptocurrency holders and recently publicised individuals are over-represented. The bank sees nothing.

The second stage is carrier compromise, achieved through one of three routes: social engineering of a customer-service agent using breached identity data, self-service provisioning of an eSIM using compromised carrier account credentials, or insider assistance at the retailer or operator, which remains a persistent and under-reported factor.

The bank sees nothing here either, though the customer usually sees the one observable symptom — loss of service — and very often interprets it as a network fault.

The third stage is the takeover, and it is fast. Observed intervals between successful port and first attempted account access are frequently under thirty minutes and cluster heavily outside business hours. The attacker uses the number precisely as the bank intended it to be used: to receive a reset code, to confirm a device enrolment, to satisfy an out-of-band confirmation. Every control performs exactly as designed. Nothing in the authentication log looks anomalous, because nothing anomalous happened at the authentication layer.

The fourth stage is monetisation, which shows a distinctive shape: contact-detail changes performed early, payments structured to remain below intervention thresholds, and a marked preference for destinations that settle quickly and irreversibly. Where an institution offers a new-payee cooling-off period, attackers wait it out — the port is stable and the customer, having lost service, is frequently in a shop being told the problem will resolve shortly.

Two secondary findings deserve attention. First, the loss-of-service symptom is a genuinely high-quality signal that is almost never captured: customers routinely contact the bank about something unrelated while unknowingly in the middle of a takeover, and no contact-centre workflow asks the question. Second, in a meaningful minority of cases the customer's carrier account had itself been compromised weeks earlier through credential reuse, which means the attack chain began at a service the bank has no visibility of and the customer does not think of as security-relevant.

Implications for Financial Institutions

The first implication is that message-based one-time passcodes should be reclassified in the institution's own risk model as a weak possession factor rather than a possession factor, and that reclassification should have consequences. It does not follow that they must be removed — they remain necessary for customers without smartphones and for assisted channels — but they should not be sufficient on their own for account recovery, device enrolment, contact-detail change or high-value payment approval. Where a stronger factor is available for a customer, the weaker path should be disabled for that customer rather than retained as a convenience, because an attacker will always select the weakest available route.

The second is that carrier signals should be consumed wherever the market provides them. A query returning recent SIM-change or porting activity for a number, applied at recovery, enrolment and high-value payment, is one of the few controls in this domain that directly addresses the actual attack rather than its symptoms. Where formal interfaces are unavailable, partial substitutes exist — network-based authentication checks, silent verification methods and device-binding approaches that tie a session to the handset rather than to the number.

The third is that device binding is the more durable architectural answer and should be the strategic direction. If trust is anchored to a cryptographic key held in a specific device's secure hardware rather than to a telephone number, porting the number achieves nothing. The migration cost is real and the fallback paths are where the risk concentrates, but firms that have moved materially in this direction report the attack becoming uneconomic rather than merely harder.

The fourth is that contact-centre and digital workflows should actively surface the one symptom the customer can see. A short, standard question — has your phone lost service unexpectedly in the last day — costs nothing, and in engagement work it has proved to be one of the most productive single interventions available, because it converts a symptom the customer has misattributed into an alert the institution can act on. The corresponding operational discipline is that a customer reporting loss of service should never be verified by a code sent to that number.

The fifth is that the post-recovery window needs its own monitoring regime. The interval between a successful takeover and the first payment is short, but it is not zero, and the behavioural signature within it is distinctive: contact detail changes, new payee additions, unusual hours, and device characteristics that do not match the customer's history. Institutions that treat a completed authentication as the end of the risk assessment have no coverage of the only period in which they could still intervene.

Conclusion

The mobile number became a security control by accident, at a time when possessing a number implied possessing a device and changing one required physical logistics. Neither condition holds. eSIM provisioning has removed the friction that was doing most of the work, and the identity checks that remain are performed by organisations with different incentives, different threat models and no visibility of what the number is protecting.

The response is not to abandon the number — for a large part of the customer base there is no immediate alternative — but to stop treating it as sufficient. Reclassify it as weak, remove it as a standalone path for recovery and enrolment where a stronger option exists, consume carrier change signals where they are available, move trust towards device-bound keys as the strategic destination, and ask the customer the one question that reveals the attack while it is still in progress. The bank cannot fix the carrier's controls. It can stop depending on them.

Suggested Next Steps

• Reclassify message-based one-time passcodes as a weak possession factor in the internal risk model, and remove them as a sufficient standalone control for account recovery, device enrolment, contact-detail change and high-value payment approval wherever a stronger factor is available to that customer.

• Integrate carrier SIM-change and porting signals into recovery, enrolment and payment decisioning in every market where an interface exists, and evaluate network-based or silent verification alternatives where it does not.

• Adopt device-bound cryptographic authentication as the strategic direction, and explicitly design and monitor the fallback paths, since these will become the attack surface during and after migration.

• Add a standard loss-of-service question to contact-centre and digital service workflows, with an absolute rule that any customer reporting unexpected loss of mobile service is never verified by a code sent to that number.

  
  

Sources: PSD2 and UK strong customer authentication requirements including dynamic linking; European Banking Authority guidelines on ICT and security risk management and on fraud reporting; Financial Conduct Authority and Prudential Regulation Authority operational resilience policy; National Cyber Security Centre guidance on multi-factor authentication and SMS-based codes; Ofcom and international telecoms regulator measures on SIM replacement and number porting verification; GSMA guidance on eSIM provisioning security; UK Finance fraud reporting; FBI Internet Crime Complaint Center advisories on SIM swapping; TrustSphere Risk Index — April 2026.

TrustSphere Risk Index — Vendor Spotlight: Prove

Prove scores 6.9 out of 10 in the TrustSphere RiskTech Index 2026, in the Identity and Authentication category. The capability profile is unusually specific: Identity Verification and Liveness 8, Device Intelligence 9, Client Lifecycle Orchestration 8, eKYC 8, Fraud Detection 7, Document Authentication 6, with Transaction Monitoring 4 and Watchlist Screening 3. The Device Intelligence 9 is the assessment's finding and it reflects something particular — phone-centric identity signals rather than browser or handset fingerprinting.

The proposition is identity and authentication anchored to the mobile line itself, using carrier-sourced signals: how long the number has been held by the subscriber, whether the subscriber identity matches the presented customer identity, and — most relevantly here — whether the number has recently been ported or had its SIM changed. This is the category of control that addresses SIM swap at its actual mechanism rather than at its consequences, and there are few alternatives that do.

The fit is direct. The single most valuable signal in this typology is tenure: a number that has been continuously associated with the same subscriber for years behaves very differently as a risk object from one whose SIM profile changed forty minutes ago. Applied at account recovery, device enrolment, contact-detail change and high-value payment approval, that signal converts a control the bank cannot see into a control it can score. Institutions that consume it report the most improvement precisely where engagement work identifies the weakness — the recovery path, not the login.

The second relevant property is that the check can be performed without adding customer friction. Unlike step-up verification, a tenure or recent-change query is invisible to a legitimate customer and produces no abandonment cost, which materially changes where in the journey it can be deployed. Controls that are free at the point of use tend to get applied broadly, and breadth is what this typology requires, since the attacker chooses the path.

The limitations are real. Carrier coverage is the whole ball game: signal quality depends on which operators, virtual network operators and jurisdictions are covered and on how quickly the underlying data reflects a change. A control that covers the major operators in one market and little else creates an obvious selection effect, and attackers locate coverage gaps rather quickly. Buyers should test coverage against their own customer base's actual carrier distribution, including virtual operators and prepaid segments, rather than against national market share.

Second, the control addresses the number and nothing else. It does not help where the attacker has compromised the device itself, does not address recovery paths that never touch the number, and does not detect an insider-assisted port that leaves the subscriber record unchanged. It should be treated as one input to a risk decision rather than as a determination.

Third, the data protection basis for querying carrier data varies by jurisdiction and is the most common reason implementations stall. Firms should engage privacy counsel early on the lawful basis, the customer transparency requirement and the retention position, because these questions are considerably harder than the integration.

The questions to press are: what is your carrier coverage in each of our markets, including virtual network operators and prepaid, and what proportion of our specific customer base would return a usable signal; what is the latency between a SIM change or port occurring and it being reflected in your response; how do you handle numbers held on business or family accounts where subscriber identity will not match the customer; what is the false-positive profile for legitimate customers who have recently changed device or provider; and what lawful basis and customer transparency model do you recommend in our jurisdictions?

The verdict is that Prove's 6.9 reflects a genuinely differentiated capability aimed at the precise mechanism of this attack. It is not a complete answer — nothing addressing a third party's identity processes can be — but it is the closest thing available to visibility of a control the institution depends on and does not own. Its value is bounded almost entirely by coverage, and coverage is a question of fact that buyers can and should establish before purchase.

TrustSphere Risk Index — Vendor Spotlight: Okta

Okta scores 6.7 out of 10 in the TrustSphere RiskTech Index 2026, in the Identity and Access Management category. The capability profile is weighted to access rather than to financial crime: Client Lifecycle Orchestration 9, Identity Verification and Liveness 7, Device Intelligence 7, Fraud Detection 6, eKYC 6, Document Authentication 5, with Transaction Monitoring 3 and Watchlist and Sanctions Screening 2. The orchestration score is the substance of the assessment; the low financial-crime scores are a category boundary rather than a criticism.

The proposition is enterprise and customer identity infrastructure: authentication, authorisation, lifecycle management and policy orchestration across workforce and consumer estates, with phishing-resistant and passkey-based factors, adaptive policy, and increasing emphasis on session and post-authentication risk. For this typology the relevant capability is the policy layer, because the defining institutional failure here is not a missing factor but an inconsistent one.

The relevance is straightforward and often underestimated. SIM swap succeeds because the attacker picks the weakest available route to the account, and in most institutions the weakest route is not the login — it is recovery, enrolment or an assisted channel that was configured separately, often years earlier, by a different team. A platform that expresses authentication and recovery requirements as central policy rather than as per-channel configuration is the mechanism by which an institution can actually enforce the reclassification of message-based codes described above, rather than merely agreeing to it in a paper.

The second relevant property is device-bound credentials as the strategic destination. Passkeys anchored in device secure hardware are not portable with a telephone number, which removes the mechanism this attack depends on entirely. The realistic assessment is that migration takes years and that the fallback path carries the risk throughout, but the direction is correct and the platform layer is where the migration is coordinated.

The third is continuous session evaluation. This typology's post-authentication window — contact changes, new payees, unusual hours, unfamiliar device characteristics — is where intervention remains possible after every authentication control has been satisfied legitimately. Identity platforms that re-evaluate risk during a session, rather than deciding once at the door, provide the hook for that intervention, though the decision itself belongs to the fraud estate.

The limitations should be clear. This is identity infrastructure and not a fraud platform: the low transaction monitoring and screening scores are honest. It will not consume carrier porting signals natively, will not score a payment, and will not tell an institution that a customer's number changed hands. Its contribution is to make policy enforceable and consistent, and the quality of the policy remains the institution's problem.

Second, the assisted channels are where this typically fails in practice. Contact centres and branches frequently sit outside the identity platform's reach, running their own verification scripts, and an attacker with a ported number and good breach data will find that path. Buyers should treat contact-centre integration as a primary requirement rather than a later phase, because otherwise the platform hardens the routes that were already strongest.

Third, migration risk is genuine. During a transition both old and new paths exist, and attackers actively seek the legacy route. The transition plan needs explicit monitoring of legacy-path usage and a defined decommissioning date with executive ownership, not an aspiration.

The questions to press are: how are contact-centre and branch-assisted verification paths brought under central policy rather than left as exceptions; can policy consume external risk signals such as carrier porting data as a decision input; what is the supported architecture for elevating requirements on a defined customer population for a defined window in response to an emerging threat; how is post-authentication session risk re-evaluated and how are those signals exposed to fraud systems; and what is the recommended pattern for retiring legacy recovery paths safely?

The verdict is that Okta's 6.7 accurately reflects strong orchestration and limited financial-crime depth. Against SIM swap it is the enforcement layer rather than the detection layer: paired with Prove's carrier signals it becomes possible both to know that a number changed hands and to have every channel act on that knowledge consistently. Either alone leaves the institution with a policy it cannot apply, or a signal nothing consumes.

TrustSphere helps financial institutions design and deploy intelligent fraud and financial crime detection solutions. Visit www.trustsphere.ai