Over the weekend of 12–13 September 2026, BT broadband customers who use the BTInternet email service included with their package began receiving text messages they had not asked for. Not one or two. Hundreds. Some reported 500 to 1,000 password reset texts, each carrying a four–digit one–time PIN, arriving in bursts of 50 to 70 within a few minutes, pausing for a few hours, then starting again. BT has since confirmed that “a small number of customers” were affected, says it has “implemented a number of mitigations to prevent further password reset messages from being sent”, and is contacting those impacted directly.
Treated as a consumer story, this is a nuisance: an inbox full of junk, an irritating weekend, a fix applied. Treated as a security story, it is considerably more interesting, and the detail that makes it so is arithmetic. A four–digit PIN has 10,000 possible values. A password reset form that will send an unlimited number of those PINs on demand is a form that will also, in most designs, accept an unlimited number of guesses at them. That is not an exotic vulnerability requiring a researcher to find it. It is a rate–limiting decision, and it is the same decision sitting inside a great many UK business systems today — customer portals, booking systems, member areas, legacy line–of–business applications and self–service password resets that were built once and never revisited. This article looks at what happened, why the design pattern is weak, and what a UK SME should check on its own systems this week.
What BT customers actually experienced
The reports follow a consistent shape. Customers on BT’s UK broadband packages who also use the bundled BTInternet email service started receiving password reset texts from the weekend of 12–13 September 2026. Each message contained a four–digit one–time PIN of the kind used to verify identity during a password reset. None of the recipients had requested them. The volume escalated quickly, with the worst–affected describing totals in the region of 500 to 1,000 messages.
The delivery pattern is the part worth dwelling on, because it carries information. Messages arrived in clusters of 50 to 70 over a few minutes, then stopped for several hours, then resumed. Human behaviour does not look like that. Automation does. The shape strongly resembles bots repeatedly hitting a “forgotten password” form that is not effectively rate–limited — running until something throttled them or the script paused, then resuming. The pauses may indicate a crude limit being hit and reset, or simply a scheduled loop. Either way, the volume tells you that whatever controls existed between the public form and the outbound SMS gateway, they were not stopping a script.
Two further details compound the problem. First, changing the account password did not stop the flood. That is logically consistent with how these forms work — a password reset request is made against an identifier such as an email address, not against a password, so rotating the password changes nothing about an attacker’s ability to keep submitting the form. But it is also the first thing every affected user tried, and its failure left them with no self–service remedy at all. Second, and more seriously, customers found it difficult to distinguish a genuine, self–requested PIN from an attacker–triggered one. Every message looked the same. In a flood of several hundred identical texts, the one that matters is indistinguishable from the noise.
That second point is where a nuisance becomes an attack. One affected customer reported that attackers gained access to their email account overnight while they were logged in, then used that same email account to intercept the BTID password–reset code and change the account details — locking the legitimate owner out of their own account. The chain is worth reading slowly, because every link in it is ordinary: compromise the mailbox, use the mailbox as the recovery channel for the account above it, complete a legitimate reset flow with a legitimately delivered code, and the takeover is complete without a single control being bypassed by force.
BT’s initial front–line response, on 14 September, was to tell affected customers to “ignore” the messages and that their accounts remained secure, with no explanation of the underlying cause offered at that stage. The company subsequently confirmed to ISPreview and The Register that a small number of customers were affected, that mitigations had been implemented to prevent further password reset messages being sent, and that impacted customers were being contacted directly.
Telling a user to ignore a flood of verification codes sounds reasonable and is precisely backwards, because the flood is the attack surface. A one–time PIN is a security control that works by being noticed — an unexpected code is supposed to be the signal that tells you someone is trying to get into your account. Bury that signal under four hundred identical messages and you have not merely annoyed the user, you have disabled their detection capability and trained them to dismiss the exact alert that matters. This is the same mechanism as MFA fatigue attacks, where an attacker spams approval prompts until a tired user taps “yes”. The difference in volume is a difference in tactic, not in principle. Any UK business whose incident guidance boils down to “ignore it, we think you’re fine” should assume that guidance will be followed on the one occasion it should not have been.
How the incident unfolded
The sequence below sets out what is publicly established, at the granularity the reporting supports. The interesting feature is not the speed of the attack but the length of the gap between customers experiencing it and anyone explaining it.
Read as a whole, the timeline describes a failure of detection rather than a failure of defence. BT’s systems were not breached to produce the flood; a public form was used exactly as designed, just far more times than anyone intended. The gap that hurt customers was the one between “something is obviously wrong” on the Saturday and a substantive explanation days later. During that gap, users were making security decisions with no information, which is how the one genuine takeover in this story became possible.
Why a four–digit PIN is the wrong control here
The weakness is not that four digits is a small number in the abstract. It is that four digits is a small number relative to how many guesses an attacker gets. Security of a short code depends entirely on the system limiting attempts, because the keyspace provides almost none on its own. Ten thousand combinations is trivially exhaustible by a machine. The only thing standing between an attacker and the correct PIN is a counter, and if that counter does not exist, is set generously, or resets on a new request, the code length becomes decorative.
The chart below gives an indicative view of how different verification designs hold up against automated attack and against the harassment–by–notification pattern seen here. These are a planning model rather than measured data, intended to rank the options rather than score them precisely.
Two things are visible in that ordering. The first is that the jump from the bottom of the list to the middle costs almost nothing — lengthening a code and adding exponential backoff after failed attempts is a configuration change in most systems, not a re–architecture. The second is that the top of the list is not primarily about code length at all. Passkeys and hardware keys score well because they remove the shared secret entirely: there is no code to intercept, no message to flood, and nothing a user can be socially engineered into reading aloud. That is a different class of defence, not a stronger version of the same one.
The specific controls that would have blunted this incident are unremarkable and well established: longer codes, exponential backoff after failed attempts so each successive guess costs more time, and IP– or device–based throttling on the request side so that a single source cannot trigger hundreds of messages. That last one is the control that matters most for the harassment pattern, and it is the one most often missing, because request throttling protects the recipient rather than the system — and systems are usually designed to protect themselves.
The number that explains the whole incident
Put the arithmetic in front of anyone who signs off on a verification design and the argument stops being a matter of opinion. A four–digit PIN has 10,000 possible values. If an attacker can make guesses freely, drawing at random, the probability of landing on the right one within 10,000 attempts is not a remote chance requiring enormous patience.
That figure understates the real position rather than overstating it. Random guessing is the inefficient approach; an attacker enumerating 0000 through 9999 in order is guaranteed to find the code, and the average case is reached halfway through. Neither approach is difficult to automate. The defence was never the code — it was always supposed to be the limit on attempts, which is exactly why the absence of effective rate–limiting converts a minor design compromise into a complete failure of the control.
There is a second, subtler consequence that the arithmetic does not capture. A flood of codes does not only enable brute force; it degrades the value of every genuine code that follows. Verification by one–time code depends on an implicit contract with the user: if you receive a code you did not request, something is wrong and you should act. Several hundred unrequested codes tear that contract up. Afterwards, the user has no reliable way to interpret the next one, and neither does the support desk they call. That loss is not repaired when the flood stops.
Where UK SMEs carry the same weakness
It would be comfortable to file this as an ISP problem. It is not. The pattern — a short code, delivered over SMS, behind a publicly reachable form with weak request limits — recurs constantly in systems that UK small and medium businesses either operate or depend on. The readiness gaps below reflect where that exposure usually sits, with badges indicating how much attention each typically needs.
The first row is the one that will apply to more readers than expect it. A substantial number of UK sole traders, contractors and small firms still run their business correspondence through an address supplied with their broadband — btinternet.com, and its equivalents from every other ISP. It works, it has worked for fifteen years, and it costs nothing extra. What it also does is place the business’s most security–critical asset inside a consumer service whose verification design, support model and incident communications are built for consumers. When that service has a bad weekend, an SME discovers it has no account manager, no tenant–level audit log, no conditional access policy and no way to escalate beyond a general support line.
The third row is the one that causes the actual damage, and the BT incident demonstrates it precisely. An email account is rarely valuable in isolation. It is valuable because it is the recovery channel for everything else — the banking portal, the accounting package, the domain registrar, the Microsoft 365 tenant, the supplier accounts. In this case the chain ran from a compromised mailbox to the BTID reset code to a locked–out owner. The general rule it illustrates is simple and almost universally violated: a recovery channel must be at least as strong as the strongest thing it can recover. Most organisations have this inverted, protecting a finance system with strict controls while its password reset quietly terminates in a mailbox secured with a four–digit code.
What fixing this costs
The figures below are indicative planning bands for UK businesses, covering the work of moving off weak verification and establishing a defensible account–recovery position — licensing, configuration, migration where needed, and the staff time to do it properly. They are not quotes.
| Business size | Typical scope | Indicative first–year cost | What you get for it |
|---|---|---|---|
| Sole trader or micro business, 1 – 5 users | Move business email off an ISP–bundled mailbox to a managed tenant on your own domain, authenticator app or passkey MFA, recovery details corrected and recorded | £400 – £1,500 | An email identity you own rather than rent from a broadband contract, with a recovery path that does not depend on a four–digit code |
| Small business, 6 – 25 users | Tenant–wide MFA policy with SMS demoted to last resort, recovery channel audit across all business–critical accounts, conditional access baseline, Cyber Essentials readiness review | £1,800 – £6,500 | Consistent authentication across the organisation, and a documented map of which accounts recover through which channels |
| Established SME, 26 – 100 users | Passkey or hardware key rollout for privileged and finance roles, alerting on abnormal reset and sign–in activity, review of customer–facing reset forms, backup of mailbox data independent of the provider | £6,500 – £22,000 | Phishing–resistant authentication where the money and the admin rights are, with detection rather than reliance on a user noticing |
| SME operating a customer–facing portal or app | Rate limiting and exponential backoff on reset endpoints, longer codes, IP and device throttling, abuse monitoring, notification–flood protection for your own customers | £4,000 – £18,000 | Assurance that your own customers cannot be flooded through your forms — the side of this story most businesses have not considered |
| Multi–site or regulated SME, 100+ users | Estate–wide identity review, privileged access separation, tested account recovery runbooks, ICO–ready incident procedures, Cyber Essentials Plus scope alignment | £22,000 – £75,000 | A recovery position that has been exercised rather than assumed, and evidence that stands up to an auditor, an insurer or a customer questionnaire |
The distribution of cost in that table is worth noting. The controls that would have mattered most in the BT incident — demoting SMS, correcting recovery channels, throttling reset forms — sit in the cheapest rows. The expensive rows buy detection and evidence, which is a different thing. A micro business can substantially improve its position for the price of a couple of days’ work, and the single highest–value action on the list, moving business email onto a domain and a tenant you control, is also the one most often deferred indefinitely because the current arrangement is free and has never visibly failed.
Two postures towards account recovery
Reactive posture
What most UK SMEs have today
- Business correspondence running through an ISP–bundled consumer mailbox, because it came with the broadband and has always worked
- SMS set as the default second factor across every account, chosen once at setup because it was the option everyone understood
- Recovery addresses and phone numbers set years ago, never audited, some pointing at former staff or dormant mailboxes
- No inventory of which critical accounts recover through which channel, so the weakest link is unknown rather than accepted
- Unexpected verification codes dismissed as glitches, with no reporting route and no one collating them
- Customer–facing reset forms deployed once and never reviewed for request–side throttling
- Recovery from a compromised mailbox attempted for the first time during the incident itself, against a consumer support queue
Proactive posture
Where Cyber Essentials with Cloudswitched takes you
- Business email on a domain and a tenant the organisation owns, with administrative control, audit logging and a real escalation path
- Phishing–resistant authentication — passkeys or hardware keys — on privileged, finance and email accounts, with SMS demoted to a documented last resort
- Recovery channels audited and recorded, each one at least as strong as the strongest account it can recover
- A current map of business–critical accounts and their recovery dependencies, reviewed when people or suppliers change
- Staff told explicitly that an unexpected code is a security event, with a named person to report it to within minutes
- Reset endpoints on your own systems rate–limited, with exponential backoff and IP or device throttling, so your customers cannot be flooded through your forms
- A tested recovery runbook, plus independent backup of mailbox data, so regaining control does not depend solely on the provider
What separates those columns is not budget. Auditing recovery addresses costs an afternoon. Telling staff that an unexpected code is a security event costs a conversation. Demoting SMS in favour of an authenticator app is a policy setting in most platforms. The reason the left–hand column persists is that account recovery is nobody’s job: it is configured once during setup, by whoever happened to be doing the setup, and then inherited silently by every subsequent owner of the system. It becomes visible only when someone attacks it, which is precisely when there is no time to fix it.
List your organisation’s ten most consequential accounts: business email, the banking portal, the accounting package, the domain registrar, the payroll system, the Microsoft 365 or Google tenant, the primary cloud console, the payment provider, the CRM and the backup platform. For each one, write down two things and nothing else: which channel recovers it (which email address, which phone number) and who controls that channel today. Then look for the pattern this incident exposed — any row where a high–value account recovers through something weaker than itself, any channel that is a personal or consumer mailbox, any phone number belonging to someone who has left, and any address that appears on more than three rows. That last case is your single point of failure: compromise it once and every account beneath it follows. The list takes an afternoon to produce, requires no spending, and is the single most useful security artefact most SMEs do not have.
What this means for Cyber Essentials and your regulatory position
UK businesses pursuing or holding Cyber Essentials certification should read this incident as a scoping question rather than a news item. The scheme’s value has always been less about the difficulty of its technical controls and more about the discipline of enumeration: it forces an organisation to establish what accounts, devices and services it actually has, and to apply consistent controls across them. Multi–factor authentication on cloud services is squarely within scope. Account recovery, in practice, is where certified organisations most often carry an unexamined gap — because a recovery channel is not a device, does not appear in an asset inventory, and quietly sits outside the questions most people think to ask.
The specific question to ask of your own scope is this: if every account in scope is protected by MFA, what happens when someone initiates a recovery flow? If the answer for any material account is “a code goes to a mailbox or a phone number that is not itself in scope and not itself protected to the same standard”, then the control is real but the boundary is porous. That is not a certification failure in most cases. It is a genuine risk that certification, treated as a checklist rather than as an exercise in understanding your estate, will not surface.
There is also a data protection dimension that applies whether or not you are certified. If an attacker takes over a business mailbox, the personal data of clients, staff and suppliers held in that mailbox is compromised, which engages UK GDPR obligations and potentially a 72–hour notification to the ICO. The practical difficulty in a scenario like this one is establishing what happened at all. An organisation running email on a consumer–grade service typically has no tenant–level audit log, no sign–in history it can export, and no way to determine what was read or exfiltrated. Being unable to characterise a breach does not remove the obligation to report it; it simply means reporting it with far less to say.
The NCSC’s long–standing guidance points the same way, and has for years: prefer authentication factors that cannot be intercepted or replayed, and treat SMS as better than nothing rather than as the destination. This incident does not change that advice. It illustrates the second–order reason for it — that an SMS–based factor is not only interceptable but floodable, and a factor that can be buried under noise has failure modes that have nothing to do with cryptography.
The story at a glance
| Item | Detail |
|---|---|
| What happened | BT broadband customers using the included BTInternet email service received hundreds of unsolicited password reset texts, each with a four–digit one–time PIN |
| When it started | The weekend of 12–13 September 2026 |
| Volume reported | Up to 500–1,000 messages for the worst affected, in bursts of 50–70 within a few minutes, pausing for hours before resuming |
| Likely mechanism | Automated bots repeatedly submitting a poorly rate–limited “forgotten password” form |
| The design weakness | A four–digit PIN gives only 10,000 possible combinations, and short codes are only secure if attempts are strictly limited |
| Why changing the password did not help | Reset requests are submitted against an email address, not a password, so rotating the password does not stop the requests |
| The real harm | Customers could not distinguish a genuine self–requested PIN from an attacker–triggered one, which disables the alerting value of one–time codes |
| Confirmed takeover | One customer reported attackers accessing their email overnight, intercepting the BTID reset code through that mailbox, changing account details and locking the owner out |
| Initial BT advice | On 14 September a support agent told customers to “ignore” the messages and said accounts remained secure, with no cause explained at that point |
| BT’s confirmed position | Told ISPreview and The Register that “a small number of customers” were affected, that it has “implemented a number of mitigations to prevent further password reset messages from being sent”, and that it is contacting those impacted directly |
| Controls that address this | Longer codes, exponential backoff after failed attempts, and IP or device–based throttling on the request side |
| The general rule | A recovery channel must be at least as strong as the strongest account it can recover — most organisations have this inverted |
| Biggest SME exposure | Running business email on an ISP–bundled consumer mailbox, where there is no tenant control, no audit log and no escalation path |
| Regulatory angle | A compromised business mailbox engages UK GDPR and potentially a 72–hour ICO notification — harder to characterise without provider–side logs |
| Free first step | Audit your ten most consequential accounts: which channel recovers each one, and who controls that channel today |
This story connects to several we have covered recently, and read together they describe one theme rather than separate incidents. Our piece on the end of security through obscurity is the closest relative: a four–digit PIN is obscurity dressed as a control, and it only ever worked because nobody was systematically trying. The digital ID rules now live for alcohol sales show the opposite design philosophy at work — verification through a certified provider that returns an assertion rather than a shared secret, which is the direction identity is travelling. The rapid exploitation of JFrog Artifactory is a reminder of how quickly automation finds a weak endpoint once it is worth finding. VMO2’s cost cuts and the continuity risk they create speaks to what happens when a consumer–grade support model is the only escalation route a business has. And LINX’s LON2 fabric passing 1Tbps makes the same structural argument in the network layer: a second path is only worth having if it does not share a failure mode with the first — which is exactly the test an account recovery channel should be put to.
Do you know what your business email actually recovers through?
Cloudswitched helps UK businesses achieve and maintain Cyber Essentials certification — and the part of that work that pays for itself is the enumeration: establishing which accounts exist, which controls apply to them, and where the recovery paths quietly terminate in something weaker than the account they protect. If your business email still runs through an ISP–bundled mailbox, or SMS is doing more work in your authentication than you would like, that is the conversation to have before an attacker starts it for you.
Talk to us about Cyber Essentials CertificationFrequently asked questions
Find the weak link before someone else enumerates it
Cloudswitched works with UK businesses on Cyber Essentials certification and the practical security work that surrounds it — moving business email onto infrastructure you control, replacing SMS with phishing–resistant authentication on the accounts that matter, auditing where recovery codes actually land, and making sure your own customer–facing forms cannot be turned into a message cannon. The BT incident required no vulnerability and no great sophistication. It required a form, a script, and a design decision nobody had revisited.
Talk to us about Cyber Essentials Certification
CloudSwitched
London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.
