Revolutionary Information

Every cloud provider should keep its customers' security audit logs for twelve months, free, by default. Picture why. A responder opens the audit search on a breached tenant, scrolls back for the intruder's first sign-in and hits the end of the window. Nothing before it is hidden; it was deleted on schedule. Short default audit log retention does that every day, and the objection to fixing it, storage cost, collapses once you price the storage.

Why should audit log retention be a full year?

Because the average breach is noticed about six months after it starts, a free window shorter than a year deletes the attacker's first moves before anyone goes looking for them.

IBM's Cost of a Data Breach Report 2026, as summarised by Secureframe, puts the average time to identify a breach at 183 days. Free windows are shorter. Microsoft raised Purview Audit (Standard) retention to 180 days from October 2023; Premium keeps a year. AWS's CloudTrail event history shows 90 days of management events at no charge. On our arithmetic, an average breach is found three days after a Standard tenant's first entries expired, and 93 days after an AWS account's with no trail. The part you lose is the part showing how they got in.

Storm-0558 showed the cost. In mid-2023 the State Department caught Chinese intruders in its Microsoft 365 mail through MailItemsAccessed, a record The Hacker News reported was then typically Premium-only. Microsoft freed it after the fact. One breach fixed one vendor's tier and set no rule, the same gap as CISA's memory safety roadmap, a deadline nobody is bound by, while duties like the Cyber Resilience Act's 24-hour early warning assume the evidence still exists.

Four numbers settle whether a year is excessive, drawn from IBM's 2026 report via Secureframe, Google's observability pricing page (as of October 2026), Microsoft's 2023 expansion and our own division of AWS's window by IBM's detection time.

The zero should embarrass everyone else. Google keeps admin and login audit records past the one-year mark for every project and bills nothing, so free year-long retention is plainly not commercially impossible.

The federal rule moved too. OMB memo M-26-14, dated 22 May 2026, rescinded M-21-31, whose 12 months of active storage plus 18 months cold gave way to six months searchable and a year retrievable, per the memo's own appendix. Even trimmed, the government kept a year (retrievable, granted, not searchable), which makes a one-year vendor default look modest.

How long do Microsoft 365, AWS and Google keep audit logs for free?

Microsoft 365 Standard keeps six months, AWS's event history keeps three, and Google keeps admin activity for just over a year, so only one of the big three already meets the rule argued here.

The table sets those windows beside the two rules that already demand a year. PCI DSS v4.0.1 requirement 10.5.1 requires 12 months of audit log history, the latest three immediately available, as Microsoft's PCI guidance quotes it. Find your row and compare the last column with your own detection time.

Only Google clears the bar by default, and only for admin activity: Data Access logs keep 30 days, per Google's storage documentation. The grey area, in our opinion rather than any rule: logs needing a restore should not count as retained for the first three months of an incident.

Worked example: an AWS account with no trail keeps the 90-day event window and writes about 2 GB of audit events a day. Assumptions: S3 Standard at $0.023 per GB-month, the US East first-50-TB rate listed in October 2026; storage only, no compression, no ingest or query fees. Reaching 365 days means 275 more days, so 550 GB more at steady state. 550 × $0.023 = $12.65 a month, about $152 a year, or roughly 2.5 cents per person monthly at a 500-person firm, to close a 93-day blind spot. Your version is one subtraction, detection time minus window, and it belongs in your next renewal.

Where does a one-year default still fall short?

It falls short wherever the expensive part is search rather than storage, wherever logs hold personal data that privacy law says to delete, and wherever an intruder stays hidden for longer than a year.

Storage is the cheap part. SIEM ingest and hot search are where bills grow, and a vendor default changes neither. We would write the rule the PCI way: a year kept, a quarter searchable.

Privacy cuts the other way. Audit records carry user names and IP addresses, so the GDPR's storage limitation principle means a provider must justify the year and lock it down. Voluntary fixes have a poor record, as with default passwords, which lasted until the UK made banning them law.

• Microsoft's longer retention follows each user's licence, so mixed tenants keep mixed windows.
• AWS event history skips data events such as S3 object reads; only a trail records them.
• Exports need deletion protection, such as S3 Object Lock, or an admin-level intruder can erase them.
• Auditors wanting immediate access may reject logs that need a restore.

Make the rule yours before a regulator makes it everyone's. This week, find the oldest event your audit tool returns; if it is under a year old, export to locked cold storage and write a free one-year retention default into your next cloud contract.

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.