Revolutionary Information

Here is the rule: any company that sells phones in a country must also sell that country's owners the parts and manuals to repair them. Self service repair india shows why. An iPhone owner in Madurai with a cracked screen gets Apple's fee or a shop's guess at the right part.

Why does self service repair india need a law?

Because Apple sells repair parts, tools and manuals to individuals only in countries it picks, and India's Right to Repair portal relies on voluntary signing, so no Indian buyer holds a right to cite. India is also not the only market left out. Apple's release of 28 May 2025 placed Self Service Repair in Europe, the UK and the US, with Canada next, so Australia, Japan and every other market share the gap.

Apple built the other half. In March 2021 it said its Independent Repair Provider programme would reach more than 200 countries with genuine parts and manuals (or rather, for shops that qualify), and India TV reported that India was included. A qualifying shop in Salem can buy what its customer cannot, much like end-of-support dates hidden from buyers: facts that decide a phone's life stay with the maker.

India's answer so far is a portal. The India.gov.in Right to Repair page lists mobile phones and tablets among four initial sectors and states no duty to supply parts or manuals. The Press Information Bureau said on 29 August 2024 that the portal depends on voluntary onboarding, with 23 mobile and electronics firms then signed up. Compulsion is possible: the UK has made default passwords illegal since April 2024.

Four numbers show the thin footing: Apple's August 2025 statement, the ministry's 2022 plan as TechCrunch reported it, and Cashify's September 2026 report of Apple India's prices.

Where one seller controls the part, the fee is whatever it says and a buyer cannot test it. Abroad, Apple publishes the part price; in India it shows only the finished fee.

Which markets give owners an enforceable right?

Of the markets compared here, only the EU backs repair access with an enforceable duty on makers: its ecodesign rules require critical parts to stay on sale, while Apple's store and India's portal rest on voluntary participation.

The European Commission's smartphone page sets the benchmark: critical parts within 5 to 10 working days, from 20 June 2025.

Only the first row is a legal duty. Every other row depends on a company choosing to take part, which is exactly what a rule removes.

Worked example: an iPhone 18 Pro owner needs only a battery. Apple India charges ₹13,900 (reported 19 September 2026). Apple's US store charges $129 less a $61.92 old-battery credit (GSMArena, 20 October 2026), plus a $49 seven-day toolkit rental (MacRumors, October 2025), at ₹95 to the dollar, our assumption. So $129 minus $61.92 is $67.08, plus $49 is $116.08, times 95 is ₹11,028: a saving of ₹2,872. Add the screen in the same week (₹36,900 at Apple India per Trak.in; $329 less $16.45 abroad) and the kit is paid once, so the saving grows to ₹10,080. US prices exclude tax, duty and shipping.

What are the objections to a repair-access rule?

Three objections come up: low volume, safety and warranty, and each is answered by what Apple already does elsewhere, though the rule still needs limits because it guarantees access to parts, not a lower price.

Low volume is the weakest: Apple built a shop channel in India in 2021, so the supply chain exists. Safety is real for swollen batteries and argues for conditions. Apple's store credits the old battery, pulling used cells into a collection channel, and our call is that a law should require the same plus a manual that opens with the safety steps. Skip the manual and you get the alternative: an iPhone 13 owner on r/IndiaTech wrote in late 2025 that a local shop fitted an aftermarket battery for ₹3,000 and the phone then showed an Unknown Part message. One user's account, no survey.

Warranty is a drafting question: a rule can keep cover on the rest of the phone intact after a genuine-parts repair while excluding damage the repair caused. Makers can be bound on this front, as when several Gulf and Asian authorities made banks move logins off SMS codes.

Check this first: open Settings, Battery, Battery Health and read the capacity. Apple's India battery page, read on 31 October 2026, says a battery under 80% is replaced free with an Apple care plan.

• Parts access is not a price cap.
• A US price is a guide, not an Indian quote.
• Our view: publish part prices, do not cap them.

Decision: unless the Battery Health check shows your repair is free, pay Apple's fee for a phone you will keep and use a shop only for one you will soon replace, then write one line this week to the Department of Consumer Affairs, which runs the Right to Repair portal, asking for a legal duty on any phone seller in India to supply parts and manuals.

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.