Revolutionary Information

Here is the rule that should be compulsory: no bank may let a texted code be the only second check on a login or payment. That is an SMS OTP ban, and four markets already enforce one. Britain and the US only advise it. The objection, that a ban shuts out people without smartphones, is answered in the US government's own identity rulebook.

Picture what it prevents. A fraudster talks a mobile shop into moving your number to a new SIM, your phone loses signal, and your bank's next code lands in their hand.

Why is SMS OTP not secure enough for bank logins?

A texted code proves only that someone controls your phone number, and both the number and the code can be taken from you without touching your handset, through a SIM swap or a fake login page.

NIST SP 800-63B-4, the US federal identity guideline dated August 2025, says out-of-band authentication "is not phishing-resistant": type a texted code into a fake bank page and the attacker relays it, however fast you act. Telling people to be careful with codes is outdated advice.

It also classes SMS codes as "restricted" and tells services to check for SIM changes first. Cifas's Fraudscape 2025 report, published 7 May 2025, found unauthorised UK SIM swaps rose 1,055% in 2024; each swap hands the victim's bank codes to someone else.

Four numbers decide whether a ban is practical. Two come from that Cifas release; two are our arithmetic from the UAE and NIST documents.

The cost card kills the banks' usual excuse. NIST permits exportable keys at AAL2, its middle assurance level, and bars syncable authenticators only at AAL3, so on our reading a synced passkey on your phone clears the bar.

Britain already legislates security floors when advice fails, as its ban on default passwords in connected devices shows, and NIST is extending identity rules to AI agents that log in on your behalf. Bank logins remain the gap.

Which countries have made an SMS OTP ban law?

Four markets in our compilation compel banks to move customers off texted codes, namely the UAE, Singapore, Malaysia and the Philippines, while the UK and the US still treat the switch as advice rather than law.

Singapore's date is from the Monetary Authority of Singapore's 9 July 2024 release; the others are as reported by Newsonair, Bernama and the Daily Tribune. Britain's NCSC said on 23 April 2026 that passkeys "should now be consumers' first choice of login", but set banks no date.

The UAE finished inside one UK financial year; the Philippines, whose circular dates to May 2025, gave banks about 13 months. Our call: a UK regulator could set a 12-to-18-month deadline, asking nothing the Gulf and Southeast Asia have not already done.

Worked example: assume six logins: current account, savings, credit card, PayPal, pension and email. Four (current account, credit card, PayPal, email) accept a texted code alone. One SIM swap reaches 4 of 6, two thirds. Move email and current account to passkeys: 4 minus 2 leaves 2 of 6, one third, halving your exposure.

Now do your own one-swap count: list your money and email logins and count those that accept a text code alone. That number, found in under a minute, is your exposure today.

Would banning text codes lock out people without smartphones?

No, a ban written NIST's way removes the texted code as a sole factor while requiring services to keep other authenticator types open to every customer, so nobody depends on a smartphone.

NIST requires that "alternative authenticator types are available to all subscribers" and that verifiers "SHALL offer at least one phishing-resistant authentication option at AAL2". Texts survive as one route, never the only one. But SP 800-63 binds US federal agencies, not private banks.

Hardware is the fairer objection: passkeys need a phone that still gets updates, which is why we argued devices should print their end-of-support date at the point of sale. Recovery is the real grey area. If a lost phone means the bank lets you back in by text, the weakness returns by the side door. Our view, only an opinion: the fallback should be slower, not weaker (a branch visit, say, or frankly anything a phone shop cannot redirect).

Watch for these:

• Silent fallbacks: some passkey apps still accept a text via "try another way".
• Email resets: email recovered by text undoes your passkeys.
• Lockout: with no second device or backup codes, removing texts can lock you out.
• Number ports: ask your network what it checks before moving your number.

SMS codes should be banned as the sole second factor for UK bank logins, with a deadline: the markets that did it finished in about a year, and alternatives, not texts, protect people without smartphones. Until then, set the rule yourself this week: turn on a passkey or in-app approval in your bank's app, switch off the text-only route, then do the same for your email. No second device or backup codes? Keep the text option until you have one. The NCSC's passkeys guide (undated, retrieved 23 October 2026) shows how.

UK law already requires every connectable device to publish its end of support date. The objection is that a web page is enough for anyone who cares. It is not, because the buyer decides at the till, and that date sits where the buyer is least likely to look. Every connected device should print it at the point of sale.

Why the end of support date stays hidden

The end of support date stays hidden because the UK rule asks makers to publish it on a web page, not to show it in the shop, so a buyer at the shelf sees nothing the rule requires.

The UK product security regime came into force on 29 April 2024. Schedule 1, paragraph 3 says a maker must state the minimum security update period along with an end date, published clearly, without a request, free, and in English. Read that closely and the box is absent. So is the shelf. The buyer gets the date only from a page they must first think to open.

Ask who carries the cost of this gap. The maker has had two and a half years to comply, yet the shopper pays for the uncertainty at the till. A date that arrives after the purchase is a date the buyer cannot use to choose.

Four figures frame the gap, and each one answers a question a buyer has at the shelf.

Read the cards together. The compliance window is long and the conditions are many, yet the place a shopper stands appears in none of them. The 2.5 years is our own arithmetic from the April 2024 start date to October 2026, not a figure any regulator published. The end date is required, and still not required where it would change a purchase.

Does a device maker have to tell me when support ends?

Yes, if the product is a connectable device sold in the UK, the maker must state the minimum security update period together with an end date, but the law does not say where you will see it. That answer is the whole legal question in one line.

Schedule 1 paragraph 3 pairs the period with the date, which is the number a shopper needs. It does not fix the place, so the maker chooses it. For the same design in another rule, our piece on how the default password ban treats labels shows a floor set by law with the packaging left to the seller.

What is the minimum security update period under UK law?

Under the UK regime, the minimum security update period is the shortest support commitment the maker states for a connectable product, and it must come with an end date. The law makes the maker state it, not promise any particular length.

The figure belongs to the maker, not the regulator. Two phones sold side by side can carry very different commitments, and both can be lawful. That is the reason to compare the stated period rather than assume a standard. If you buy from the EU, the clock runs faster, as our note on the Cyber Resilience Act reporting deadline explains.

How long will my phone get security updates?

It depends on the period the maker has stated, which the law requires them to publish alongside an end date, and that figure can differ from one model to the next in the same brand range. Check the product page for that date before you buy, because the box will not tell you.

Two rules of thumb follow. Read the end date rather than the marketing, and when the page gives no date, treat the product as one with no promised support.

Which situation are you in?

The right step depends on whether you are buying a phone, a connected car part or something sold with no UK page at all, and the table sets out what to do in each case.

Scenarios matter because the rule treats a phone on a UK shelf differently from a car head unit, and the buyer needs to know which one is in front of them.

The default row matters most. A product with no date gives you no promise to rely on, and that is worth a question to the seller before you pay.

Where the rule runs out

The end-date rule has gaps, because some products sit on an exception list, a car carve-out is still being drafted, and a seller with no UK page leaves the buyer with nothing to check.

Schedule 3 lists excepted products, and automotive is expected to be carved out by a statutory instrument that is not yet in force. A connected car head unit can therefore fall outside the rule, and the buyer cannot tell which list applies from the showroom floor. Disclosure is thin elsewhere too, as our note on how few top domains publish a security.txt file shows.

• Check whether the product sits on the Schedule 3 exception list before relying on a date.
• Ask for the security update period in writing if the product page shows none.

Make the date a condition of the sale. If the product page shows no end date by the time you reach the till, ask the seller for it in writing, and walk away if they cannot give one this week.

Every company that sells software or a connected device should be legally required to publish where a stranger can report a security bug, and to promise someone will read it. The cheapest form is a plain text file called security.txt, and only 1.25% of the top million domains have one, per a URIports scan on 24 January 2025. On roughly 98 of every 100 big sites, a researcher who spots a hole has nowhere to send it.

Why should security.txt be compulsory?

A security bug report is only useful if the right person receives it, so a public, monitored contact turns a stranger's warning into a fix, while a voluntary one leaves most sites silent.

The format is simple. RFC 9116, the 2022 internet standard for the file, asks for a contact, an expiry date and an optional policy link. The CRA's 24-hour reporting duty assumes a vendor hears about the bug first: before a vendor can tell regulators within a day, someone has to be able to tell the vendor.

Neef, Schlunke (TU Berlin) and Hennig (KIT), in a paper posted to arXiv in June 2026, tracked the 40 largest German listed firms from 2023 to January 2025: adoption of the file or a formal disclosure programme went from half the group to nearly all of it. One country, 40 firms and no proof of cause, but firms plainly move when a deadline is visible.

Voluntary effort is not nothing. By my arithmetic from URIports' two scans, domains with the file rose from 6,816 in April 2024 to 12,510 in January 2025, roughly 84% in nine months. I still disagree that good practice will spread alone: most sites stay silent and attackers do not wait. The UK wrote the duty into law with its default-password ban for connected devices instead of hoping.

Four figures test whether a bare file does the job: the European Commission's CRA page sets the dates, the TU Berlin and KIT paper sampled security mailboxes, and URIports checked the files themselves.

The bounce figure is the one I would show a regulator. The sample was small, 26 generic security addresses, so it is a warning light rather than a rate. Still, a finder whose email errors out has done everything asked; the failure sits with the company, and only a duty to acknowledge, as UK law now sets, closes it.

Is a vulnerability disclosure policy required by law?

It depends on where you sell: UK law already requires consumer-device makers to publish a reporting contact, EU law will require a coordinated disclosure policy from December 2027, and US federal law requires it only of agencies.

Schedule 1, paragraph 2 of SI 2023/1007 makes the UK maker of a relevant connectable product publish a contact plus timings for acknowledgement and status updates, free and in English (as of 2024). The EU's Cyber Resilience Act, Regulation 2024/2847, requires in Annex I, Part II, point 5 a policy on coordinated vulnerability disclosure; the European Commission's CRA page gives the dates (checked 14 October 2026). CISA's Binding Operational Directive 20-01 applies the idea to US federal agencies only (as of 2020).

The UK and EU put the duty on the people who profit from the product; the US puts it on its own civil servants and leaves the vendors it buys from to volunteer. My view: that is backwards, because unanswered reports pile up in the market, not in one agency's inbox.

What goes wrong when a file is all you ask for?

A file proves only that someone typed a few lines once: a published, unmaintained one can point to nobody, which is why the rule must demand a working, answered channel rather than a text file.

RFC 9116 makes the expiry date a required field, yet URIports found 45% of files carry no Expires line and another 13% had already expired. Fewer than half follow the standard, so by my arithmetic roughly one top-million domain in 180 publishes a file that does; that is derived from two published rates, not a URIports figure. The objection that a file is cheap theatre is half right. Call it a file, then correct that: the file was never the point, the reply is.

The other objection is that a mandate would bury small firms. The UK text is gentler than critics assume: it asks when a reporter can expect an acknowledgement and updates, not a deadline for the fix. Whether a one-person shop should carry the same duty as a listed company is the real grey area; in my opinion, yes to acknowledging, no to fixing on a clock. Voluntary targets end badly: the CISA and FBI memory-safety roadmap set a 1 January 2026 date that binds nobody. Watch for these in your own setup:

• An empty Expires field or a lapsed date.
• A security address routed into a general support queue.
• No named owner, so the reply is nobody's job.
• A policy that threatens finders into silence.

The decision is whether to wait for the law or run a monitored channel now, and the answer is now. This week, email your own security address from a personal account and time the reply: a bounce or silence tells you what to fix first.

Every router, camera and smart plug sold in the United States should be legally required to carry a password unique to that unit, or make you set your own, before it touches your Wi-Fi. Britain has enforced exactly that default password ban since 29 April 2024. America chose a sticker. The standard objection says a voluntary label lets shoppers reward careful makers without Washington writing firmware rules. It sounds reasonable, until you see what the sticker has done since.

Why a default password ban beats a label

A ban beats a label because it protects the buyer who never reads packaging, never registers the device and never changes a setting, while a label protects only the shopper who already knows to look for it.

The British version, set out on GOV.UK's product security regime page, is blunt: passwords must be unique per product or set by the user. Makers must also publish a route for reporting security bugs and say how long they will ship security updates. A British buyer gets that protection without knowing the law exists, which is the whole point of a rule.

America took the other road. The FCC approved the US Cyber Trust Mark on 14 March 2024 as a voluntary label, CyberScoop reported, so a US shopper gets password protection only when a maker opts in. Its lead administrator, UL Solutions, then withdrew on 19 December 2025 amid an FCC probe into its China ties, says Cybersecurity Dive. The FCC named the ioXt Alliance in its place on 13 April 2026, Broadband Breakfast reported, and won't pay for the job. By my count, the label shoppers were told to trust sat with nobody in charge for nearly four months.

Washington has been here before: its memory safety roadmap deadline for critical-infrastructure software carried no penalty and passed quietly. Europe binds vendors instead, as the Cyber Resilience Act's 24-hour vulnerability warning shows. Four figures from GOV.UK, the PSTI Act 2022 and Broadband Breakfast show the gap.

A fine pegged to worldwide turnover is too big for a global router brand to treat as a cost of selling in Britain, so the cheap answer is one firmware build for every market. You just can't tell from a US box which makers did it.

Does the UK ban default passwords on smart devices?

Yes, the UK has banned universal default passwords on consumer connected devices since 29 April 2024, requiring each product to ship with a unique password or make the buyer set one, under the Product Security and Telecommunications Infrastructure regime.

The table sets that law against the US label, read as a buyer standing in a store.

Read down the right-hand column: the label helps only buyers who already do the work. The first-row fine comes from the PSTI Act 2022; the 115-day gap is my arithmetic from the reported dates above.

Do routers have to come with unique passwords?

Only in some places: in Britain since April 2024, in California and Oregon since 2020, and across the EU from December 2027, while a router sold in the other 48 US states can still legally share one factory password.

California's SB-327, operative since 1 January 2020 (as of 2020), demands a password "unique to each device manufactured" or one the user creates. Oregon passed a near-copy. The EU's Cyber Resilience Act, on EUR-Lex, requires a secure by default configuration once its main obligations apply on 11 December 2027. So the "too costly" objection collapses: the engineering exists, and the biggest US state has demanded it for years.

The second objection calls default passwords a niche consumer worry. CISA disagrees. In December 2023 (as of 2023) its Secure by Design alert urged makers to drop default passwords after attackers reached Unitronics controllers at US water facilities; CyberScoop reported their factory password was 1111, so one shared login opened every identical unit. The federal security agency called it a manufacturer failure in writing, then only asked nicely. As with post-quantum migration deadlines, guidance without teeth moves at the pace of the slowest vendor.

One grey area remains, and this is opinion: should a federal rule reach devices already in homes? I'd cover new sales only, because retroactive rules invite lawsuits that stall everything. Watch-outs meanwhile:

• A Cyber Trust Mark helps, but its absence proves nothing.
• An app-based setup can leave the local web login on its factory value.
• Marketplace imports may follow no national rule.

So here's the decision. If you're in the US, treat the label as a bonus and the password check above as the real test, and this week log in to your own router and replace any password printed in its manual. Then tell your representative that Britain already proved the rule costs makers almost nothing.

Related: the UK product security law behind default-password bans

Related: why an SMS OTP ban should be compulsory for bank logins

Here is the rule. Under the Product Security Bad Practices guidance from CISA and the FBI, a maker of software used in critical infrastructure that had no published memory safety roadmap by January 1, 2026 is, in the agencies' own word, "dangerous". The date came and went. Your firewall vendor, your hospital's imaging supplier, the firm behind your water utility's control panels: none of them owed you a thing when it passed.

The flaw is in the rule. The same document says it "is non-binding" and "imposes no requirement", so the risk of a missing plan sits with you, the customer. It should be compulsory. And the standard objection, that leaving C and C++ is too slow and too costly, no longer survives the data.

Is CISA's memory safety guidance mandatory?

No, CISA's memory safety guidance is voluntary: the agencies call a missing roadmap dangerous for critical-infrastructure software, but attach no fine and no procurement ban, so a vendor that ignored the January 2026 date faces nothing.

Washington has stayed in that register. A June 2025 NSA and CISA information sheet on memory safe languages (Rust, Go and others that stop code touching memory it does not own) says the agencies "urge organizations to consider whether adopting MSLs is practical for their circumstances." That hands every vendor two exits, "consider" and "practical". A buyer waiting for a federal push is waiting for something the government has said, in writing, it will not do.

Other regulators have been less shy. Europe wrote vulnerability handling into law, down to the 24-hour exploited-vulnerability warning the Cyber Resilience Act demands. Even NIST put calendar years on its post-quantum migration deadlines. Memory safety, the older and better-understood problem, got an adjective.

Is Rust really safer than C++?

Yes, by a margin that ends the argument. A November 2025 Google report, Rust in Android, found its roughly 5 million lines of Rust running at about 0.2 memory-safety vulnerabilities per million lines, against roughly 1,000 in its C and C++, a reduction Google puts at more than 1,000x. That kills the excuse that safer languages just move bugs elsewhere.

But the objection was always about cost: rewriting slows teams, and ship dates pay salaries. Four numbers test that. Google's Android data supplies two, measured on changes of comparable size. MITRE's CWE Top 25, released in December 2025, supplies a count of memory errors among the most dangerous weaknesses. The calendar supplies the last.

Show the rollback figure to a sceptical finance director. A rollback is a release pulled after shipping, usually an outage and a lost weekend. Fewer of those means the cost objection runs backwards.

With no regulator compelling a plan, your contract is the only lever left.

What a required memory safety roadmap changes for buyers

Requiring the plan turns a vendor's vague intention into a dated, auditable commitment that covers its riskiest code first, which gives a buyer something to enforce at renewal instead of a hope.

The flaw-rate row is my arithmetic, not Google's: Android's measured densities scaled to a 100,000-line component. At those rates a new C++ service carries latent memory flaws in triple figures, and the Rust version most likely none.

Where a compulsory roadmap gets hard

A compulsory plan gets hard in two places: products close to retirement, which the guidance already exempts, and vendors who publish a roadmap with no dates in it, which satisfies the letter while changing nothing.

Do software makers have to stop using C and C++ by 2026?

No. The CISA and FBI guidance asks existing products for a plan, not a rewrite, and only calls new critical-infrastructure product lines in C or C++ dangerous where a memory-safe alternative exists. I'd go further than CISA, or at least put it more bluntly: a roadmap without a year beside each component is a brochure.

The unresolved question, in my opinion, is embedded firmware. A substation controller will not be rewritten, and a plan for it may mean little beyond the next model. Newer guidance shares the gap, such as the NSA's May 2026 advisory on MCP security for AI agents: sound advice, no teeth. Watch for:

• Goals with no year per component.
• Memory-safe claims covering only new features.
• An end-of-support date just inside the exemption.
• Sandboxing sold as a substitute, not a stopgap.

If two of those are true, stop waiting for Washington. This week, email the vendor asking for its published plan and support end date, and tell procurement that renewal now depends on a dated commitment, cryptographic code first. Require it yourself, because nobody else will.

Here is the rule. Since 11 September 2026, any company selling software or connected hardware in the European Union that learns one of its products is being actively exploited has 24 hours to send an early warning to the authorities, and 72 hours to follow it with a full notification. That is CRA reporting, set out in the European Commission's guidance on the Cyber Resilience Act, and it is already live. A vendor in Austin that sells the same router in Berlin and Boston now owes Berlin a warning. Boston gets nothing.

That gap should close by law, and the usual objection is mostly answered by how the rule is written.

Why CRA reporting should be the global floor

A vendor knows first when its product is being exploited, so the duty to warn belongs with the vendor, and a rule that protects only EU customers leaves every other buyer of the same product exposed.

The manufacturer sees the crash reports, the researcher emails and the telemetry spike days before customers notice anything. The Act makes that knowledge travel: manufacturers must also inform impacted users, according to Hogan Lovells' 11 September 2026 briefing. An EU hospital running a VPN appliance gets told. A clinic in Ohio running the identical box does not.

The American answer is thinner. CIRCIA puts the reporting duty on critical-infrastructure operators, the victims, not on the vendor whose code let the attacker in. CISA's Secure by Design pledge is voluntary, so a US buyer holds no enforceable promise unless it sits in the contract. Treating a pledge as a rule is outdated advice.

Anyone who tracked the DPDP consent manager deadline in India or post-quantum migration deadlines under NIST IR 8547 knows the pattern: a regulator sets a clock, and vendors discover how little of their process was built for one.

Run the clock on a real calendar. Confirm exploitation at 5pm on a Friday and the early warning is due by 5pm Saturday, the full notification by 5pm Monday. That is our own arithmetic, and it means someone with authority to file must be reachable all weekend. The four numbers below, from the Commission and Article 64 of the Act, decide whether vendors take that seriously.

The revenue-linked ceiling is what changes behaviour at large vendors. A flat cap is a budget line; a share of global revenue grows with the company, so the suppliers in the most networks carry the steepest exposure.

Does the Cyber Resilience Act apply to US companies?

Yes, the Cyber Resilience Act applies to any manufacturer placing products on the EU market, wherever it is based, so a US vendor selling into Europe already owes EU buyers warnings its home customers never receive.

US figures below come from Ballard Spahr's Byte Back analysis of CIRCIA (February 2026) and CISA's pledge page.

The vendor builds the triage desk for Europe anyway, so American customers pay for output they never see. Vendors treating 2027 as the start date have the calendar wrong.

Won't a 24-hour rule crush small vendors?

No, because the 24-hour step is an early warning to a national security team, not a public disclosure or a finished report, and the fuller detail follows on a structured, longer schedule.

At its strongest, the objection says a ten-person firm has no security team and a panicked filing could leak. Filings go through ENISA's Single Reporting Platform to the CSIRT of the manufacturer's main establishment, so the warning never touches the open internet. Attackers learn nothing from a message they cannot read.

The burden is real but scoped: a written threshold for "actively exploited" and a named Sunday filer. Plus a rehearsal. Two, honestly, because the first always finds the gap nobody wrote down. AI tooling vendors have more ground to cover, with flaws surfacing in MCP servers flagged in the NSA's advisory and in AI agent credentials nobody has inventoried.

The genuine grey area is the word "aware". In our view the clock should start at credible evidence of exploitation, not legal sign-off, but enforcement will settle it. Watch for these:

• Community-maintained components sit outside the clock until open-source stewards join.
• Severe incidents run a different final-report schedule, so check which your contract names.
• US buyers hold no right to the EU notice, even for identical firmware.

Do not wait for Washington. This week, pull your three largest software contracts and add one clause: the vendor notifies you within 24 hours of confirming active exploitation, on the same terms it already owes EU regulators. A vendor that refuses a promise it already keeps in Europe has told you what you need to know.

Related: why a memory safety roadmap should be compulsory for software vendors

Related: why a compulsory default password ban beats a voluntary label

Related: why every vendor should publish a working security.txt reporting channel