The Immortal Technique

I wrote up four ways OMNY's account portal actually fails not long ago, New York's tap-to-pay fare system. The finding under all four was a seam: a hardened payment path wired to a soft layer nobody had reasoned through end to end, the failure living at the boundary between the parts, not inside any one part.

This is the forward version of that story, and it moves the seam somewhere more uncomfortable. Not between two web vendors. Into the phone itself.

For most of a decade the industry's answer to "where do we put the sensitive thing" has been the same: on the phone, the phone is secure. Payment went first. Then car keys, house keys, hotel keys, transit. Île-de-France Mobilités put the Navigo pass into Apple Wallet and began letting riders move the annual pass fully onto the device. Identity followed, several governments now issue driver's licenses and state IDs straight into the same Wallet. The phone quietly became the place institutions, and governments, keep the thing that proves who you are and what you are allowed to do.

That answer rests on one assumption nobody writes down: the device cannot be turned against its owner. In August 2026, that assumption got its expiration date back.

The scale is the part to sit with. A decade ago the phone held one sensitive thing, your card. Today it holds payment, car and home keys, transit, and in a growing list of places your government ID, all trusting the same chip and the same assumption. A crack in that assumption no longer costs one credential. It costs every credential that chose the phone as its root, at once, and the jailbreak that reopens the question is already shipping, not a thought experiment.

The move they buried

I have been on this since the first iPhone. I jailbroke every one I owned, as a matter of course, right up until it stopped being realistically possible. What killed it for me was not Apple's lawyers, it was the tethered jailbreak: the kind where a reboot left the phone dead until you plugged back into a computer to re-apply the exploit. That is not a daily driver, that is a pager with extra steps. Untethered or nothing, and eventually it was nothing.

But dormant was never the same as dead, and that distinction was a live argument among engineers precisely because the honest answer kept moving. Apple closed the bootrom era, hardened the kernel, shipped Lockdown Mode, and the scene thinned to almost nothing. Then, after 326 days of people calling iOS 26 locked, Dopamine 3.0 landed and reminded everyone that "solved" has a shelf life.

It does not cover every device, and Apple will patch the chain it rides. That is the nature of the thing. It dies, it comes back, it dies again. Which is the forward-looking point, and the whole reason to write this now rather than after: you do not get to plan around the device staying shut. You plan around it being opened eventually, because the twenty-year record says it will be.

The jailbreak does not break the vault

Start with what it cannot do. That is where most of the hype dies.

A jailbreak does not open the Navigo in your Wallet. That credential lives in the Secure Element, a separate certified chip (EMVCo, Common Criteria) isolated from the application processor a jailbreak compromises. When you tap the gate, the exchange happens in a local field the main processor never sees inside. The vault holds. Nobody is forging or cloning the pass out of it, and anyone telling you otherwise is selling something.

A compromised device never gets near the vault. What it gets is the trust around it. A phone that can be opened is a phone that can lie, to the apps running on it, to the provisioning and account flows those apps drive, and to any backend leaning on the device's own word that it is intact. The sensitive thing in the vault stays sealed. Everything that believed the device itself was honest inherits the crack.

The seam moved onto the device

This is the OMNY seam, relocated. In New York the soft layer was a web account portal talking to a vendor backoffice, and the failure was a sensitive account change committed on client-side faith, no re-authentication, the class of mistake MITRE files as CWE-306. On the phone the soft layer is the app and the account-and-provisioning flow wrapped around the vault, and the mistake is the same species: trusting a client that the device's owner can now rewrite.

The difference is the stakes. A web portal was one system. The phone is becoming the common trust root under transit, payment, physical access, and identity at the same time. When the seam sat between two vendors it was a bug. When the seam is the device every institution leans on, it is a dependency, and dependencies compound.

Only what is possible

Only what is possible, then, nothing claimed as done. On a compromised handset the layer around the vault becomes observable and bendable: the provisioning calls, the account tokens, the fields a client sends, the checks a backend assumes the client already made. Resilience controls, pinning, anti-tamper, jailbreak detection, are speed bumps by design, and OWASP's mobile standards (MASVS) say so in plain language. They slow an attacker who already holds the device. They do not stop one. Point that at an account layer that trusts the client, the way OMNY's did, and the possible outcome is influence over what the trusted layer tells the vault, and over who is permitted to manage it, without ever touching the vault.

That is the whole shape of it. A vault doing its job perfectly while, one layer over, the thing that feeds it takes a compromised device at its word.

The limits of the claim

Three limits, and I will not pretend past them.

This claims no exploit was executed against Île-de-France Mobilités or RATP. It reasons over a publicly documented product and a publicly released jailbreak, which is the only honest way to write it without an authorized scope.

Whether a given backend re-validates provisioning and account changes server-side, independent of the client, is not visible from outside. If it does, that single control breaks the chain. The possible is not the inevitable, and saying otherwise would be a lie dressed up as a finding.

And the jailbreak is narrow today, A12 and A13 silicon, a thin band of builds. The compromised-device condition is real but not universal yet. "Yet" is the operative word, and the forward-looking part of the argument: the technique is immortal, and narrow becomes wide on its own schedule, not Apple's.

None of this is a gotcha aimed at one operator. The Navigo in Wallet is here because it is a good product, and the exposure is a design problem Île-de-France Mobilités shares with every system that bet on the phone. Specifics belong in a disclosure channel, routed privately to the operator, not in a post, which is where I would send them given a scope.

Designing for a phone that will be opened

The forward move for anyone building on the device is to stop treating device integrity as a gate and start treating it as a signal that degrades. Re-validate the sensitive change server-side, every time, independent of the client, because the client is one jailbreak away from being an unreliable narrator. Require step-up authentication on account and provisioning changes, the control OMNY was missing. Notify out of band when the state of an identity or a fare account changes. Design on the assumption that the device will be compromised at some point in its service life, so that a compromised phone cannot escalate past the data already sitting on it.

That last principle is not just advice. A reference monitor that keeps capability separate from permission, denies by default, and treats the client's word as a hint instead of an authorization is what it looks like in code, and I keep a small runnable one in the open: raised_eyebrow_harness. An argument that asks for something unbuildable is just complaining. This one is built.

The institutions that put transit, access, and identity on the phone made a reasonable bet on a strong vault. The part they did not price is that the vault sits inside a general-purpose computer whose owner, or whoever comes to own that owner's phone, can eventually open. Even the governments issuing ID into Wallet are making the same bet. The strength of the vault was never the question. The question is what still holds the day the device around it does not, and that is worth answering before the dependency deepens, not after.

The jailbreak does not beat the vault. It never had to. The move that matters was never aimed at the wall, it was aimed at everything that decided to trust the wall's whole neighborhood. The technique is immortal, and that is precisely why building security on its absence was always borrowed time.