Practical IT

Your Number, Their SIM: A 45-Minute Port-Out Lockdown

Core IT Nov 14, 2026

Photo: Francisclarke, CC BY-SA 4.0, via Wikimedia Commons

A mobile number used to be just a way to ring the office. Now it is a key. It opens Microsoft 365, resets passwords, confirms bank payments and receives the six-digit code that stands between an attacker and your email. If someone else controls that number, even for an hour, they can do a lot of damage without ever setting foot in your building.

The awkward part is that many small UK businesses do not really know who owns their mobile accounts. The number might sit in a former employee's name, on someone's personal direct debit, or under a generic login that nobody has touched since the last phone upgrade. That is the gap a SIM swap walks through. This is a 45-minute lockdown you can run this week, with no consultants and no new software.

Why a SIM swap is an IT problem, not just a phone problem

A SIM swap happens when someone persuades your mobile provider to move your number onto a SIM they control. Sometimes they use a PAC code. Sometimes they use a convincing story about a lost phone. Once the number moves, calls and texts go to them. Your phone shows no service, and you assume the network is having a bad day.

Meanwhile, the attacker requests a password reset on your email. The reset code arrives by text. They read it. They are in. From there they can reset Microsoft 365, approve a bank transfer, or send invoices from your actual address. If SMS is your fallback authenticator, the mobile number is not a backup. It is a front door with a weak lock.

None of this requires a sophisticated criminal. It requires a business that has never checked who can port its numbers, and a provider that has never been asked to put a lock on the account.

The 45-minute audit: who actually owns the number?

Start with a spreadsheet and a pot of tea. List every mobile number the business uses: owner's phone, sales phone, the 4G router SIM, the alarm system SIM, the backup dongle, the number on the website. Include any number that receives business texts, even if it lives in someone's personal handset.

For each one, add four columns: account holder name, billing payer, provider login owner, and recovery email or phone. Then start ringing or logging in. You are looking for three red flags.

First, a number registered to a person rather than the business. That is fine for a personal phone, but not for the number that receives your Microsoft 365 codes. Second, a provider account that only one person can access, especially if that person is leaving or has already left. Third, a recovery email that points to an old address, a personal inbox, or an account nobody recognises.

Give yourself 15 minutes per provider. EE, O2, Vodafone and Three all have business account routes, but the details differ. Ask a simple question: if I wanted to move this number to another network today, what would you need from me? The answer tells you how easy a port-out would be for someone who is not you.

PAC codes, STACs and the port-out lock

In the UK, a PAC code lets you keep your number when you switch mobile networks. You can request one by texting PAC to 65075. That is useful when you are moving provider on purpose. It is also useful to someone pretending to be you. A STAC does the same job for some landline and broadband numbers, and the principle is the same: if a number can be moved, it can be moved without your permission.

Ask your provider whether they offer a port-out lock, SIM-swap protection, or account takeover protection. Not every network gives it the same name, and some smaller providers do not offer it at all. If they do, switch it on. If they do not, ask what identity checks they run before a PAC is issued. A password on the account is better than nothing. A requirement to visit a shop with photo ID is better still.

Also check who is an authorised contact. If the account lists a former office manager who left two years ago, that is the name an attacker will use. Update it. Add a note that any SIM swap or PAC request must be confirmed by a callback to a number already on the account, not a number supplied by the caller.

Recovery numbers: the bit everyone forgets

Locking the mobile account is half the job. The other half is changing everywhere that number is used as a recovery route. Log into Microsoft 365 and check the security info for every admin account. Remove old mobile numbers. Add an authenticator app and, where possible, a passkey or hardware key. Do the same for Google, your domain registrar, your password manager, your bank, your payroll system and your accountancy software.

Be honest about SMS fallback. If a critical account can be reset by a text to a number you no longer control, it is not protected. Turn off SMS where you can. Where you cannot, make sure the number is on a business account with a port-out lock, not a personal contract in someone's name.

Finally, nominate a second admin. If the person who owns the mobile account is on holiday, ill, or suddenly without a phone, someone else needs to be able to get into Microsoft 365 and the provider account. Write down the process. Keep it offline. A shared spreadsheet in the same email account you are trying to recover is not a recovery plan.

The Friday-afternoon test

Before you call this done, run a five-minute thought experiment. It is Friday at 4pm. Your phone shows no service. You cannot receive texts. Can you get into your email? Can you approve a payment? Can you contact your mobile provider without using the phone that just died?

If the answer to any of those is no, you have found your next job. Save the provider's business support number somewhere other than your phone. Make sure at least two people know the account PIN. Keep a backup admin account that does not rely on SMS.

A SIM swap is not exotic. It is a support call, a plausible story and a number that was never properly owned. Forty-five minutes of tidying up now is a lot cheaper than a Monday morning spent proving to your bank that you did not authorise that transfer.