Romania's Land Registry Died Because Its 'Immutable' Backups Trusted One Login

For a week in July 2026, nobody in Romania could sell a house.

Not because of a market crash. Because the country's land registry — ANCPI, the system that records who owns what — got wiped by an attacker on July 21st, and the backups everyone had been assured were bulletproof turned out to answer to the same compromised credentials as the system they were supposed to protect. Property transactions froze. 2.7 million citizens' records were exposed. The agency spent days rebuilding from a single offline copy that happened to live somewhere the attacker's stolen access couldn't reach.

That copy wasn't safe because it was immutable. Every backup in the chain was immutable. It was safe because it was the only one the compromised credential didn't have a path to.

That distinction is the whole story, and almost nobody writing about backup strategy is telling it.

What Actually Happened at ANCPI

The public breakdowns of the ANCPI incident converge on a boring, specific mechanism: the attacker didn't crack an encryption scheme or find a zero-day in the backup software. They got hold of credentials with reach into the production environment, and those same credentials — or credentials one hop away from them, via shared identity infrastructure — had write and delete access into the backup systems too. WORM storage, version history, retention locks: all present, all correctly configured, all irrelevant, because none of it changes who a valid, authenticated session is allowed to talk to.

Immutability is a promise about what happens to data once you're in. It says nothing about who gets to be in. ANCPI's backups were like a bank vault with a flawless time-lock — mounted on a door that opened with the same key as the front lobby.

The land registries of Poland, Slovakia, Greece, and Ukraine have all absorbed some version of this same attack pattern in the past three years. That's not coincidence. It's a class of infrastructure — public records systems, often modernized in phases, often inheriting a single identity provider across old and new components — where "backup" quietly became a permissions category instead of an architectural boundary. Once you've noticed the pattern, you start seeing the same shape in private-sector breach reports too: the backup wasn't compromised directly. It was compromised by inheritance.

Immutability Protects Bytes. It Doesn't Protect the Blast Radius.

Here's the sentence that should be uncomfortable to read if you run infrastructure: your backups can be perfectly immutable and still die with production, because immutability is a property of the storage layer and trust is a property of the identity layer, and most teams have only hardened one of the two.

Think about what "immutable backup" actually guarantees. Write-once storage, retention locks, version history you can roll back to — these stop an attacker who's already inside from editing or deleting what's there. They're a genuinely good control. But they assume the attacker has to fight the storage system to do damage. If the attacker instead just authenticates as a legitimate identity that the storage system already trusts, there's no fight. There's a login.

This is the same failure mode as keeping your database backups in the same cloud account as your production database, protected by the same IAM role, reachable by the same on-call engineer's laptop. You've backed up the data. You haven't backed up the trust decision that data depends on. When credentials leak — and in 2026, they leak constantly, through phished engineers, stolen session tokens, compromised CI pipelines, over-scoped service accounts — the backup and the original fall together, because from the attacker's perspective they were never two things. They were one trust boundary with two addresses.

The One Copy That Survived, and Why

The detail worth sitting with is what actually saved ANCPI: one offline copy, held in a separate account, outside what the incident write-ups call "the blast radius." Not a fancier immutability setting. Not a shorter retention-lock bypass window. A completely different credential plane.

That's the fix, and it's less about a product feature and more about a design decision most teams never explicitly make: does your backup identity chain intersect with your production identity chain anywhere? If a credential compromised in production can, through any combination of role assumption, shared secrets manager, or common identity provider, eventually reach the backup store — you don't have a backup. You have a second copy of the same failure domain, dressed up as a backup.

Practically, that means: a separate account or tenant, not just a separate bucket. A separate identity provider, or at minimum a break-glass credential that isn't federated through the same SSO your production engineers use daily. Write access to the backup that requires a distinct approval path — ideally one that isn't automatable by anything that also has production write access. And an actual test of the isolation, not a diagram of it: can you, right now, using only credentials an attacker who owns your production environment would also own, reach and delete your most recent backup? If you can, so can they.

None of this shows up on a compliance checklist that asks "are backups immutable?" It shows up on a much smaller, much less popular checklist that asks "if production is fully owned right now, what can the attacker still not touch?" Most infrastructure teams have never actually answered that question for their own environment, because the immutability checkbox felt like the finish line.

This Isn't a Romania Problem

It's tempting to read this as a story about a government agency with underfunded infrastructure, and move on. That's the wrong lesson. ANCPI had modern backup tooling. It had immutability. It had the control that every backup vendor markets as the answer to ransomware. It still lost a week of a national property market, because the control that got marketed as the answer wasn't the layer the attacker actually needed to defeat.

The same architecture — one identity plane quietly spanning production and backup — is sitting underneath a huge number of "modern" backup setups right now, including ones with much bigger budgets than a land registry. Cloud-native backup products make it trivially easy to grant broad access for convenience, and trivially easy to never notice that the convenience is the vulnerability, because nothing breaks until the day something breaks completely.

The Actual Question to Ask This Week

Not "are our backups immutable" — you probably already know the answer, and it's probably yes. The question that ANCPI's incident actually answers is narrower and less comfortable: if every credential your production systems hold right now were handed to an attacker, is there a single copy of your data they could not reach, delete, or overwrite? If you can't name that copy specifically — where it lives, whose credential reaches it, when it was last verified — you don't have a backup strategy. You have a very well-organized single point of failure.

Related reading: Every AI Agent You Deployed Is an Employee With No Manager and a Company Card covers the same underlying problem — credential sprawl nobody explicitly designed — from the identity side instead of the storage side.