SIM Swap Attack: What Actually Happened, and How to Prove It

What a SIM swap is, precisely

A mobile subscription consists of three things that are easy to conflate: the number (MSISDN), the subscriber identity held on the SIM or eSIM (the IMSI and the authentication key that proves possession of it), and the record in the carrier's subscriber database that binds the two together and says which credentials are live. Normal service works because the network looks up the number, finds the currently provisioned credentials, and challenges the handset to prove it holds the matching key. A swap rewrites that binding in the carrier's own database, so the challenge goes to a different key - one that is now sitting in the attacker's handset.

Nothing is broken, cracked or decrypted in the process. That is the part victims find hardest to accept, and it is why bank fraud teams sometimes treat a swap as customer negligence: from the network's point of view a swap is a legitimate administrative transaction executed by an authorised agent against a request that passed whatever identity checks the carrier had in place. The attacker did not defeat cryptography. They defeated a help-desk script.

Two details matter for evidence. First, the transaction is recorded, because carriers must be able to audit changes to subscriber identity - and since 2023 in the United States the FCC requires them to retain records of SIM-change requests together with the authentication measures used to approve them. Second, the transaction carries a precise timestamp generated by the carrier's systems, and it is almost always earlier than the first fraudulent login. Those two facts are what make a reconstruction possible at all: there is a moment when the number changed hands, and it was logged by a party with no reason to lie about it.

Why the number, not the phone, is the target

The number is valuable because it became an identifier rather than a channel. Somewhere along the way, "the person who can receive SMS sent to this number" stopped being a way to reach you and became a way to prove you are you, and then it became a database key: phone-first signups, phone-based account recovery, the number as the primary handle in messaging apps, the number printed on invoices and left in breach dumps for a decade.

Three properties make it worse than a password. It is public - you hand it to delivery drivers, it is on your website, it is in every breach that ever touched a marketing list. It is portable - one successful request moves it in minutes, and the legitimate owner then has no channel at all, including no channel on which to be told that something is wrong. And it is trusted upstream: when an exchange, a bank or an email provider sends a code, the integrity of that code depends entirely on the assumption that only you hold the number, an assumption the carrier can invalidate without informing the relying party.

There is also an asymmetry that shapes every case we work. The attacker needs one weak link - one agent who accepts a caller ID, one retail store that reads back a date of birth, one leaked bill - while the defender needs every link strong at once. Carrier authentication has improved, and the FCC order forced specific improvements, but the attacker only has to find the branch that has not finished migrating, and they can try branches until one works at the cost of a few phone calls.

The three technical routes: replacement SIM, eSIM provisioning, port-out

Most public explanations treat all number takeover as one thing. Investigatively they are different crimes with different evidence, different custodians and different remedies, and identifying the route early decides which records to request first.

Replacement SIM. The attacker persuades the victim's existing carrier to issue a new physical SIM against the same subscription, usually by walking into a retail location with a plausible story and whatever identity documents a leaked profile can support, or by calling the support line and answering knowledge-based questions harvested from breached data. The old SIM is deactivated by the activation of the new one, so the victim sees no service or a handset complaining that the SIM is not provisioned. Evidence lives with the carrier: the order record, the channel (retail, telesales, online), the store and agent identifier, the identity documents captured, the activation timestamp, and the verification method that was accepted.

eSIM remote provisioning. The same outcome with no plastic: the attacker obtains an activation code or QR profile from the carrier and provisions the subscription onto an eSIM in their own device. Carriers increasingly support transferring an existing eSIM between devices, which is convenient for customers and is also a provisioning path that has to be authenticated as strictly as a retail SIM issue. The evidence looks like a provisioning event in the carrier's eSIM platform, with an activation-code history and the requesting channel, and it is easy to miss because there is no physical SIM order to find.

Port-out. The number moves to a different carrier entirely. The losing carrier releases it, the gaining carrier provisions it, and the routing data that tells the world where to deliver calls is updated. Port-out fraud is a distinct offence in the FCC's rules alongside SIM swapping for exactly this reason: the actor is not impersonating the subscriber inside one company, they are exploiting the interoperability obligation that exists so that customers can change providers without losing their number.

A fourth route, SIM cloning, is largely historical. Cloning required extracting the authentication key from a physical card, which needs possession of the card and, in modern networks, defeats that are not practical at consumer scale. If someone claims a victim's SIM was cloned remotely, the more likely explanation is a swap or a provisioning event, and the investigation should be aimed there. The distinction matters because a cloning narrative is a common way to make a mundane carrier fraud sound exotic.

How the attacker gets past carrier authentication

The technical step is trivial once the human step succeeds, so the human step is the whole attack. In practice it takes one of five shapes, and knowing which shape a case fits tells you what to ask the carrier for.

Retail impersonation. A person presents at a store with a story - lost phone, travelling, new device - and documents that satisfy the store's script. Retail fraud is attractive because store staff are measured on activation volume, and because identity checks at a counter are often weaker than the ones the fraud team would apply on the phone.

Call-centre social engineering. The attacker calls, opens with a distressed narrative, supplies account details harvested from a breach or from the victim's own public footprint, and steers the agent toward the fastest resolution path. The failure is not a broken system, it is an agent under time pressure choosing the path that ends the call.

Insider access. A retail employee, dealer or contractor with legitimate access to subscriber records performs or facilitates the change. These cases are the most damaging and also the most provable, because the carrier's own access logs attribute the transaction to a named account - and because a carrier that discovers an insider has every reason to cooperate.

Compromised dealer or reseller systems. Third-party retail and dealer portals sit inside the carrier's authentication perimeter but not always inside its security programme. An attacker with credentials to a dealer portal can submit changes that look like ordinary retail traffic, which is why the channel field in the record matters more than the request itself.

Authentication downgrade by persistence. Not a single request, but a sequence: a first attempt that fails and generates a note, a follow-up call that cites the earlier call, an escalation that offers more identifying detail each time, until an agent with authority makes an exception. This shape is precisely why the FCC order requires carriers to have a documented process for responding to failed authentication attempts rather than leaving each failure to the judgement of the next agent.

What the attacker nearly always has is a data profile: name, address history, date of birth, last four digits of an account number, an email address, sometimes a partial bill. Every one of those is a knowledge-based answer, and knowledge-based answers are the weakest form of identity proof precisely because they are the items most likely to be in a breach. A well-run carrier has moved past them; the ones that still accept them are where cases come from.

What a stolen number actually unlocks

The damage follows the account graph, and the account graph almost always starts at email. A typical sequence: the number is swapped, the attacker triggers a password reset on the email account that has the number as its recovery method, receives the code, resets the password, and now owns the identity that every other service uses to prove ownership. From there the order is usually financial before social, because financial accounts have the shortest window before a human notices.

What is reachable, roughly in the order we see it:

• Email. The pivot account. Once it falls, every reset link in the victim's digital life is addressed to the attacker, and the notifications that follow are deleted before the victim can see them.
• Banking and card controls. One-time codes, transaction confirmations, and - worse - the add-a-new-payee flows that use a code as the only control.
• Cryptocurrency exchanges and wallets. Withdrawal confirmations, new-address allow-listing and account recovery. This is where losses are largest and least recoverable, and where the attacker's preference for speed shows: the first withdrawal often happens within an hour of the swap.
• Messaging identity. WhatsApp, Telegram and Signal registrations are keyed to the number. A new registration can take over the account, and the victim's contacts then receive messages from a familiar identity.
• Social and advertising accounts. Business pages, ad accounts with payment methods attached, and handles with resale value.
• Registrar and hosting. Domain account recovery, DNS control, and the email that administers both.
• Government and tax portals. Identity-verification flows that treat a code to the number as proof of presence.
• Voicemail. The forgotten second channel. If voicemail is reachable from another line and still on a default or guessable PIN, password-reset calls that leave a spoken code are readable without any swap at all.

Two consequences follow. A victim who secures the number and stops is only half done: the accounts reached during the window have to be checked for persistence - new forwarding rules, new recovery addresses, new app passwords, new trusted devices - because the attacker's second visit is usually easier than the first. And the loss is often provable in a way a bank will accept, but only with a timeline: the swap happened at a timestamp the carrier will confirm, the transfers happened after it, and the victim's own device was demonstrably not the one that authorised them.

Telling a swap from an outage, a dead phone or a bad eSIM

The first question in every case we take is whether the number was actually taken, because a surprising share of panicked calls are hardware faults, network outages, unpaid bills or a mis-provisioned eSIM transfer. The distinguishing feature is scope. An outage affects everyone on the site or the network; a swap affects exactly one line and leaves the rest of the household working.

• No service, but the carrier's own app or portal shows a new SIM or device. Strong indicator of a replacement SIM, especially when the activation date shown is not yours.
• A handset reporting that the SIM is not provisioned, or an eSIM profile that disappears. Consistent with either a swap or a provisioning error; the carrier's provisioning history separates them.
• Calls and texts fail while data on Wi-Fi works normally. The subscription is gone and the device is fine.
• An email or text from the carrier announcing a SIM change or a port request. The most useful single signal, and one the FCC now requires carriers to send - if it went to the number being taken it may never arrive, so make sure the carrier has an email address that is not that mailbox.
• Password reset emails you did not request, or a mailbox that logs you out. The swap has already been used. Treat it as an active account takeover, not a telephony problem.
• WhatsApp announcing that the number is registered on a new device. Registration follows the number, so this is confirmation of the takeover rather than the cause of it.
• Bank codes that never arrive while other messages do. Selective non-delivery to one sender is a pattern of interception or a sender-side block, not a swap; the pattern of failures is diagnostic.

If more than one of those applies and the carrier's records show a change you did not request, stop diagnosing and start preserving. Photograph the handset's status bar and any error text, note the times, and do not reset the device. The last known state of a handset is occasionally useful, and a factory reset destroys the one artefact the victim still controls.

The first hour: a sequenced playbook

Order matters, because several of these steps close a door another step still needs open, and because the attacker is working the same list from the other side.

1. Write down the time you noticed and what you saw. Keep a one-line log in a document on a device that was not involved. Every later claim - to the bank, the carrier, the police, the exchange - will be checked against the carrier's activation timestamp, and a contemporaneous note is worth more than a reconstructed one.
2. Call the carrier's fraud desk, not sales or general support. Ask for four things in one call: the number locked or a port freeze applied, the subscription restored to a SIM you control, the change or port request record including channel, store, agent and identity documents, and written confirmation of what happened. Get a case reference and the agent's name.
3. Secure the email account from a different device on a different network. Change the password, revoke all sessions, remove the phone number as a recovery method, and check forwarding rules and app passwords. Do this first if the swap has clearly been used, because the mailbox is the attacker's route back in.
4. Financial accounts next. Bank, cards, payment apps. Freeze cards if codes were intercepted, open a fraud case with a reference, and put the unauthorised-transaction dispute in writing so the clock is documented. If money moved, ask the bank to attempt a recall the same day; the chance of recovery drops sharply once the funds leave the receiving institution.
5. Exchanges and wallets. Disable withdrawals or freeze the account, then remove any newly added address or device. If the exchange confirms withdrawals by text to the number, say so explicitly in the ticket: until the number is back, that confirmation channel belongs to someone else.
6. Messaging apps. Re-register on your own device, enable two-step verification with a PIN that is not sent by SMS, and tell close contacts that any message from the number in the last few hours was not you.
7. Police report. Many carriers and banks require a case number before they will release records or process a claim, and a report is the hook for later legal process. File it even if the local force says it cannot investigate; the reference is the point.
8. Preserve, do not clean up. Export the mailbox if you can, screenshot account activity pages, keep the carrier emails, and keep the handset as it is. Wiping the device in frustration is the most common way victims destroy evidence that would have helped them.

The records the FCC order now forces carriers to keep

In the United States the evidentiary position improved materially because of one rulemaking. The FCC adopted its SIM swap and port-out order in WC Docket No. 21-341 on 15 November 2023, published at 88 FR 85794, revising its Customer Proprietary Network Information and local number portability rules. The requirements are specific enough to be quoted at a carrier, which is exactly what a victim or an investigator should do.

Carriers must adopt secure methods of authenticating a customer before redirecting a number to a new device or provider. They must have documented processes for responding to failed authentication attempts, train staff on SIM swap and port-out fraud, and prevent employees who receive inbound customer communications from accessing customer proprietary network information until authentication is complete. They must notify customers when a SIM change or port-out request is made, offer customers the option to lock their account against SIM changes and ports, and give notice of the protection mechanisms available. Where fraud occurs they must provide a clear way to report it, investigate and remediate promptly, and give the customer documentation of it. And they must keep records of SIM change requests and of the authentication measures used to approve them.

Compliance was tied to the effective date and to OMB approval of the information collections, which was issued on 15 January 2025; a request to suspend enforcement until 10 March 2025 was denied. The practical consequence for a case today is that the record you want exists and has a name you can ask for: the SIM change request record, the authentication method accepted, the activation timestamp, the channel, and the fraud case documentation.

What to do with that: send the request in writing, identify yourself as the subscriber or the subscriber's authorised representative, state the date range, name the records, and set a response date. Ask specifically for the authentication method used and for the channel - those two fields turn "someone got in" into "someone was let in". Carriers will release subscriber records to the subscriber; they will not release internal logs, agent identifiers or call recordings without legal process, and asking for those in the first letter is the fastest way to get a refusal that stalls everything else.

Outside the United States the rules differ but the shape of the record does not: a carrier that allows a number to move must be able to show who authorised it. In the EU the GDPR gives the subscriber a right of access to personal data processed about them, which covers the activation record; in the UK a subject access request does the same work. The mechanism changes, the ask does not.

What a forensic investigation reconstructs

An investigation does not reverse a swap. It produces a defensible account of what happened, in what order, attributable to whom as far as the evidence allows, and what it cost - which is what a bank dispute, an insurance claim, a police referral or a civil action actually needs. The work divides into four evidence families, and the value is in correlating them rather than in any one of them.

• Carrier-side records. The change request, the channel and staff account that processed it, the documents or answers presented, the authentication method recorded, the activation and deactivation timestamps, and any prior failed attempts. Prior failures are underrated: three failed authentications followed by a successful one in a store is a different story from a single clean request.
• Account-side records. Identity-provider logs for the mailbox - logins, password resets, MFA changes, recovery-method changes, forwarding rules created - with IP addresses and user agents. Usually the easiest to obtain, because the victim controls the account and most providers offer a self-service export.
• Financial-side records. Bank and exchange transaction logs, new payee or withdrawal-address creation, and the support tickets raised at the time. Exchanges keep device and IP metadata for withdrawals; a law-enforcement request or a court order can retrieve it, and a polite support ticket will not.
• Chain-side records. For cryptocurrency losses, destination addresses, first hop, clustering and exchange deposit addresses - public data that can be analysed without any legal process, and the reason crypto cases are often the most tractable despite being the least recoverable.

The reconstruction then does three things with that material. It builds a single timeline normalised to UTC, with the source of every timestamp noted. It tests the timeline for consistency - does the first fraudulent login follow activation, is the attacker's IP consistent across accounts, does an exchange withdrawal precede or follow the victim's own activity that day. And it produces an evidence index: what was obtained, from whom, when, in what format, with a hash where the artefact is a file, so a third party can check the work rather than take it on trust.

What it does not do, and should not claim to do, is identify a person from an IP address. An IP address identifies a connection at a time, and attribution beyond that needs the access provider's records through legal process. Reports that jump from an IP to a name are the main reason forensic reports get rejected in disputes.

Legal process: what can be obtained, and by whom

The boundary here is not a matter of preference, it is the difference between an investigation and an offence. Carrier subscriber records are protected by law - in the United States as customer proprietary network information under 47 U.S.C. 222 and 47 CFR 64.2001 et seq. - and obtaining them by deception or by unauthorised access to a carrier system is itself a violation, under the Computer Fraud and Abuse Act at 18 U.S.C. 1030 among other provisions. An investigator who social-engineers a carrier "to prove a point" has committed the same class of act as the attacker and destroyed the case in the process.

What is available, in ascending order of friction:

• Consent and self-service. The subscriber's own portal, data export and subject access request. Fastest, free, and covers most of what a victim needs. For a business number, a written authorisation from an officer of the business.
• Preservation letters. A written request that a party preserve records pending legal process, sent early, before retention windows expire. Cheap, lawful, and often the difference between a case and an anecdote.
• Subpoena. Civil subpoenas to carriers, email providers and exchanges for subscriber and transactional records, in the jurisdiction where the case is filed. The standard route for a civil recovery action or an insurance dispute.
• Court orders and warrants. Needed for content, real-time data, and in many jurisdictions for records that reveal location. Obtained by law enforcement, or on application in civil proceedings where the court allows it.
• Cross-border requests. Where the provider sits outside the forum, mutual legal assistance or the provider's own law-enforcement channel; timelines are measured in months, which is why preservation letters matter so much at the start.
• Law-enforcement referral. The IC3 complaint, the local police report and, in the US, an FCC complaint about the carrier's handling each create a record and sometimes a route to carrier cooperation that a private party cannot open.

Two practical notes. The order in which you seek records should follow retention windows rather than the story: carrier provisioning records have shorter retention than financial records, so carrier preservation goes out first. And every request should be narrow. A request for "all records relating to my account" invites a refusal or a bill; a request naming the SIM change request, the authentication method, the channel and a two-week window gets answered.

Three clocks: where these cases are won and lost

Most disputed cases do not turn on whether a swap happened. They turn on whether the loss is attributable to the swap, and that question is answered by three clocks that never agree by default and have to be reconciled deliberately.

The carrier clock records the provisioning event: an activation timestamp generated by network systems, usually UTC internally and rendered in local time in reports, with the timezone sometimes that of the account's billing address rather than of the store. The account clock records identity-provider events: logins and resets, timestamped by the provider's servers, usually UTC, occasionally rendered in the user's last known local time. The financial clock records transactions: authorisation times from the card network or exchange, frequently in the acquirer's timezone, and with authorisation time differing from settlement time by hours.

A one-hour error in reconciling those clocks is enough to let a bank argue that the victim authorised a transfer before the number was taken. The fix is procedural: convert everything to UTC using each source's stated offset, record the conversion, and present the timeline with the original timestamps alongside. Where an offset is unknown, say so rather than assuming; a stated assumption can be tested, an unstated one destroys credibility.

There is a second, subtler clock: the attacker's. Cases have a recognisable shape in time - reconnaissance and carrier probing days or weeks before, the swap, then a burst of activity in the first thirty to ninety minutes, then a gap while the attacker moves from seizing accounts to monetising them, then a second burst when they return for anything missed. When a victim's logs show activity in the gap, it is often the attacker returning rather than the victim's own use, and that is exactly the kind of detail that changes the outcome of a dispute.

Prevention that measurably works

Prevention advice is abundant and mostly interchangeable, so this list is ordered by how much each measure actually changes the outcome, with the honest limit of each stated.

• Move authentication off SMS. Passkeys and hardware security keys first, authenticator apps second. This is the one change that makes a swap unprofitable: if no account accepts a code sent to the number, taking the number buys the attacker almost nothing. NIST's digital identity guidance classifies PSTN out-of-band - SMS and voice - as a restricted authenticator for exactly this reason.
• Remove the number as a recovery path. Passkeys help only if the fallback is not a text message. Audit the recovery settings on every account, including the ones you forgot, and where a number must stay on file, make sure it is not the only route.
• Use the carrier's account lock, port freeze or number lock. Since the FCC order, US carriers must offer a lock that blocks SIM changes and ports and must tell customers about it. A lock raises the cost of an attack from one phone call to a process that requires unlocking first. Its limit: an insider or a compromised dealer portal can still act, and some carriers make unlocking as easy as the lock.
• Set a carrier account PIN, and a number-transfer PIN where it is a separate thing. Weak if it is a four-digit default, useful if it appears on no document you ever handed anyone.
• Ask how eSIM transfer is authenticated. Whether moving an existing eSIM to a new device needs an in-store check or an authenticated request decides whether that path is a convenience or a hole.
• Separate identities. A dedicated email address for financial accounts, never used publicly, removes the number and the public address from the same discovery path. Unglamorous, and it works.
• Store recovery codes offline. Printed or in an encrypted vault, not in the mailbox a reset would compromise.
• Put number-change alerts on both channels. Carrier alerts to an email address, and account alerts to a second channel, give you the timestamp the rest of the case depends on.
• SIM PIN. Worth setting for a stolen handset, because it stops the physical card being moved to another device - but it does nothing against a remote swap, and advice that presents it as the fix is wrong.

What does not work

Several widely repeated measures do not address the attack, and believing they do is worse than not having them, because it discourages the measures that matter.

A SIM PIN does not stop a swap. It locks the card, not the subscription. A carrier-issued replacement arrives with a new PIN, and the attacker never needs the old card.

IMEI tracking does not detect a swap. The IMEI identifies a handset; the number moved to a different handset entirely. Tracking your own device tells you where your phone is, not where your number went.

Alerts sent to the compromised number are useless by construction. If the carrier's security SMS goes to the number being taken, it goes to the attacker. Verify the alerts are configured to a different channel.

Apps that claim to detect SIM swaps mostly detect the aftermath. They can tell you that your number is not receiving messages. They cannot tell you before the carrier does, and the carrier is required to tell you.

Recovery services that promise to swap the number back, or to retrieve crypto for a fee paid up front, are a second fraud. The legitimate path is the carrier's fraud process, a police report and, where money moved, the receiving institution's recall process. Anyone offering to reverse a swap by social-engineering the carrier is offering to commit the same offence again with your money.

If your product still uses SMS OTP

If you run a service, a swap is not only a customer problem: it is a vulnerability in your authentication design, and the attacker's path runs through your recovery flow. Four changes reduce exposure substantially, and none of them requires rewriting the login page.

Stop using the phone number as an identifier. Identify accounts by an internal ID and let the number be one contact attribute among several, so that losing the number cannot become losing the account.

Never let a single SMS code authorise a security-relevant change. Password reset is bad enough; changing the recovery email, adding a withdrawal address, enrolling a new authenticator or lifting a lock should require a second factor of a different type, and ideally a delay with notification to the previous channel.

Notify both the old and the new channel on any change, including a change of number itself, and log which method authenticated each sensitive action. That log is what you will need when a customer disputes a transaction six weeks later, and it is the same reasoning the FCC applied to carriers.

Treat repeated failed verification as a signal. A user who fails an SMS challenge three times and then succeeds from a new device on a new network is either travelling or being attacked, and the difference is worth a step-up rather than a shrug.

For high-assurance flows - payments, administrator access, healthcare, anything with a regulator watching - the direction of travel is clear: NIST treats PSTN out-of-band as restricted, the EU's strong customer authentication regime has been moving away from SMS as a sole factor for years, and passkeys are now supported by every major platform. The migration is unglamorous and it removes an entire class of loss.

Recovery after the number comes back

Getting the subscription restored ends the outage and starts the cleanup. The attacker had a window, and the question is what they left behind in it.

Verify the number works in both directions, and confirm with the carrier that no port request or forwarding is pending. Then work outward from the pivot: change the mailbox password from a clean device, revoke every session, remove unknown recovery addresses and app passwords, check for forwarding rules and mailbox delegates, and read the sent folder for messages you did not send. In messaging apps, re-register and enable two-step verification with a PIN, and review linked devices. In financial accounts, review payees, standing orders, trusted devices and any app or API connections, not just the password. For social and advertising accounts, review admins, roles and payment methods. For domains, review registrar contacts, DNS records and, most importantly, the email address that administers the registrar.

Two things are routinely missed. Voicemail: reset the PIN and delete any greeting or forwarding an attacker configured, because a voicemail PIN is a second key to every call-based code. And recovery codes: if the attacker saw them while inside the mailbox, they are compromised, and only regenerating them helps.

Finally, expect a second attempt. Attackers keep victim profiles and return weeks later, when attention has faded and the new lock has been quietly removed by a helpful support agent. Keep the carrier lock on, keep alerts on a channel that is not the number, and treat any unsolicited contact about your account as hostile until verified through a channel you initiated.

Cost, duration and what an engagement delivers

Costs vary with what has to be obtained and how, so these are bands rather than quotes, and a firm that gives a fixed price before seeing the records is guessing.

A single-consumer case where the evidence is confined to carrier confirmation records, the victim's own account exports and a bank dispute typically runs in the low thousands of dollars over two to four weeks, most of which is waiting for responses. A case that needs a court order to a carrier and a subpoena to an exchange moves into five figures and six to twelve weeks, and the legal process is the majority of the elapsed time rather than the analysis. A cryptocurrency case with meaningful tracing adds a separate workstream and depends on how many hops and exchanges the funds passed through. None of these include legal fees, and none come with a promise of recovery: the report establishes what happened and what it cost, which is what a dispute or a claim needs, while getting money back is decided by institutions.

What the engagement should produce, and what to insist on: a UTC-normalised chronology with a source for every timestamp; an evidence index naming each artefact, its custodian and its hash; an analysis of the carrier record identifying the channel and authentication method that allowed the change; a consistency assessment of the account-side logs; an attribution statement with explicit confidence levels and no leap from IP to identity; and a referral pack that a police officer, a bank fraud team or a solicitor can use without translation. A report without the evidence index, or without stated confidence, is a narrative rather than a forensic product.

If you are dealing with this now, our digital forensics engagement is built around exactly that chronology and evidence-index output for number and account takeover cases, and where files or deleted material have to be recovered, the data recovery service covers the artefact side. If you are unsure whether what happened is a swap at all, the detection walkthrough in our phone hacking detection guide covers the adjacent signs, and the account-side reconstruction in our email hacking investigation guide picks up where the carrier record stops. Send us the timeline and the carrier's confirmation and we will tell you what is obtainable before you spend anything on process.

What we will not do

We work on numbers and accounts the client owns or is authorised in writing to investigate: their own, their minor children's with parental authority, or a business's with an officer's authorisation. We do not swap numbers, we do not impersonate subscribers to carriers, we do not purchase or accept carrier records obtained by deception, and we do not monitor another adult's phone or messages without their consent or a court order. We also do not guarantee outcomes - no investigation can promise that funds are recovered or that an attacker is identified, and any provider that does is selling something other than forensics.

Those limits are not squeamishness. Evidence obtained by deception is unusable in most proceedings, so an investigation built on it fails the only test that matters, and a provider willing to break that rule for you is a provider willing to break it against you. The lawful routes - consent, preservation letters, subpoenas, court orders, law-enforcement referral - are slower, which is why the first hour matters so much: everything after it is about how much can still be proved.

Auf Deutsch: this guide is also published in German — SIM-Swap-Betrug erkennen und nachweisen.