/
Navigation
Chronicles
Browse all articles
Explore
Semantic exploration
Research
Entity momentum
Nexus
Correlations & relationships
Story Arc
Topic evolution
Drift Map
Semantic trajectory animation
Posts
Analysis & commentary
Pulse API
Tech news intelligence API
Browse
Entities
Companies, people, products, technologies
Domains
Browse by publication source
Handles
Browse by social media handle
Detection
Concept Search
Semantic similarity search
High Impact Stories
Top coverage by position
Sentiment Analysis
Positive/negative coverage
Anomaly Detection
Unusual coverage patterns
Analysis
Rivalry Report
Compare two entities head-to-head
Semantic Pivots
Narrative discontinuities
Crisis Response
Event recovery patterns
Connected
Search: /
Command: ⌘K
Embeddings: large
TEXXR

Chronicles

The story behind the story

← → days · ↑ ↓ browse · Enter similar · o open

Apple Support docs show that unusual mid-production hardware changes were made to its A12, A13, and S5 chips last fall, to update the Secure Storage Component

MacRumors Hartley Charlton

Context & Ripple Effects

This lands just months into Apple's first Apple Silicon Mac ramp, but the chips touched here are the ones already in hundreds of millions of pockets: the A12, A13, and the S5 watch chip. Apple Support documents quietly confirm that last fall Apple revised these parts mid-production specifically to update the Secure Storage Component — the hardware root that holds device secrets.

The significance is procedural more than product: silicon is normally frozen once a generation ships, and security fixes ride the next annual chip. Revising three shipping chips simultaneously inside one production run means Apple treated the storage-of-secrets path as urgent enough to break its own cadence — and disclosed it only in support documentation, not a keynote.

First-order effects

  • Devices assembled after the fall revision ship with an updated Secure Storage Component under identical model names, so buyers and the refurb/repair channel receive two hardware variants of the 'same' A12, A13, or S5 device with no external way to tell them apart.

Second-order effects

  • The move prefigures the pressure Apple now faces at the silicon level: the later SLAP and FLOP side-channel attacks against M-series and recent A-series chips show exactly the class of vulnerability that can only be answered by changing the die itself, not a software patch.

Third-order effects

  • If mid-run security respins become routine, a chip's identity stops being fixed by its part number — which pushes provenance and verification of what silicon is actually inside a device toward being a first-class concern, something Apple's full-stack control makes far easier for it than for merchant chip vendors whose customers buy dies on spec sheets.

The trend: Silicon security is shifting from a per-generation design task to an iterative one, where Apple increasingly revises chips already in production rather than waiting for the next annual part.

Discussion

  • @pandrewhk Andrew Pantyukhin on x
    Apparently, there was a security reason serious enough to change the production of all A12 and A13 devices in the fall of 2020. Also, TIL, the secure enclave in iPhones *does not* include key storage 🤯 So many questions! https://support.apple.com/... https://twitter.com/...
  • @t_morris_wealth Tim Morris on x
    @MacRumors @HartleyCharlton Wasn't it secure before that?
  • @andrewtychen Andrew Chen on x
    The suspicion is that this article doesn't tell the full story, because as far as I know, Apple and Google know about the NZ app and have been okay with it. And that's also probably why the UK folks had confidence in going ahead with their plan...
  • @foxfortmobile Foxfort Mobile on x
    Maybe someone found a bootrom exploit for devices with a12+ chips 😂 https://twitter.com/...
  • @pandrewhk Andrew Pantyukhin on x
    @T_Morris_Wealth @MacRumors @HartleyCharlton Their architecture of storing private keys *outside* the secure perimeter seems highly unorthodox. It is this storage part that they had to upgrade, but I'm not sure there's a way to secure it outside of the SE. https://twitter.com/...
  • @andrewtychen Andrew Chen on x
    So perhaps it's that the UK app may have tried to upload BT and QR Code-based location data together, thus linking them together, rather than having two separate upload mechanisms that go to two separate systems like we have in NZ... But still just a guess at this point.