On 14 July 2026, the application that Romanian notaries, banks, and citizens use to verify who owns what stopped responding. The platform is called e-Terra, operated by ANCPI — the National Agency for Cadastre and Real Estate Advertising. The agency’s first public characterisation was a technical incident.

It was not a technical incident. It was a cyberattack that wiped the primary land registry database, and by the time the country’s National Cyber Security Directorate (DNSC) had completed its assessment, the finding was blunt: the attack was not complex and could have been prevented. The intrusion combined credentials that had leaked and been posted publicly with known, unpatched vulnerabilities that had already been flagged to ANCPI.

An actor using the alias ByteToBreach claimed responsibility on a cybercrime forum, posting screenshots purporting to show access to ANCPI infrastructure. Data subsequently appeared for sale.

The operational consequence was immediate and total. Notaries could not authenticate sales. Banks could not register mortgages. Citizens could not obtain proof of ownership. Romania’s real-estate market froze for close to a week — and it froze during the run-up to the expiry of a temporary reduced VAT rate, which had concentrated an unusual volume of transactions into exactly that window.

This is the clearest European example this year of what NIS2 was written to prevent, and of the gap between being designated an essential entity and behaving like one.

Why this is a NIS2 case and not just an IT failure

Under Directive (EU) 2022/2555 (NIS2), public administration entities and the operators of digital public services fall within scope, and Member States may — and Romania has — designate national registry infrastructure as essential. That classification is not a label. It carries a specific set of obligations under Article 21 (cybersecurity risk-management measures) and Article 23 (incident reporting), enforced under Article 32 with supervisory powers that include on-site inspections, security audits ordered by the authority, and, for essential entities, administrative fines of up to €10 million or 2% of total worldwide annual turnover, whichever is higher.

For a state agency, the turnover-based cap is largely notional. What is not notional are the other enforcement levers: mandated audits, binding instructions, public disclosure of non-compliance, and — under Article 20(1) — the personal accountability of management bodies for approving and overseeing risk-management measures.

Article 21(2) lists the minimum measures. Read against the DNSC findings, the mapping is uncomfortable:

  • 21(2)(a) policies on risk analysis and information system security — vulnerabilities had been flagged and not remediated.
  • 21(2)(c) business continuity, backup management and disaster recovery — the registry database was wiped and restoration took the better part of a week.
  • 21(2)(e) security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure — the specific failure identified.
  • 21(2)(i) human resources security, access control policies and asset management — leaked credentials, used successfully.
  • 21(2)(j) multi-factor authentication or continuous authentication solutions — credentials alone should not have been sufficient.

That last point deserves emphasis. NIS2 names multi-factor authentication explicitly, in the text of the directive, as a baseline measure “where appropriate.” An administrative platform through which a national ownership registry can be modified or destroyed is not a marginal case. If MFA is appropriate anywhere, it is appropriate there.

The number that explains the outcome

Reporting on the incident surfaced a spending figure that is more diagnostic than any technical detail. Over twenty years, ANCPI spent roughly RON 710 million (about €135 million) on digitalisation. Of that, approximately RON 1.6 million (about €305,000) — 0.2% — went to cybersecurity.

Two-tenths of one percent. For context, security spending in mature public-sector IT programmes typically runs between 5% and 15% of the technology budget, and higher for systems designated critical.

This is the structural point that compliance teams in both public and private organisations should take from the incident. The agency was not short of digitalisation money. It digitised an entire national registry. What it did not do was fund the protection of what it had built, and the ratio between those two decisions is the whole story. A digitalisation programme that does not carry proportionate security funding does not produce a modern service; it produces a single point of failure with a web front end.

NIS2 anticipates exactly this through Article 21(1), which requires measures to be proportionate to the entity’s exposure to risk, its size, and “the societal and economic impact” of incidents. An agency whose outage stops all property transfers in a Member State sits at the top of that scale. A 0.2% security allocation is not proportionality; it is the absence of an assessment.

The three failures, and what each one costs to fix

Leaked credentials that still worked

Credential exposure is not preventable in the sense that you can stop credentials from appearing in third-party breach corpora. What is preventable is those credentials remaining valid, and being sufficient on their own.

The controls are unglamorous and cheap relative to the loss: enforced MFA on every administrative and remote-access path without exception; continuous monitoring of credential-exposure feeds mapped against your own identity directory; automated forced rotation on match; and elimination of shared or service accounts that cannot carry a second factor. None of these require a large budget. They require a decision.

Known vulnerabilities that had been flagged

DNSC’s finding that the vulnerabilities “had recently been flagged to ANCPI” is the part that converts this from misfortune into liability. A vulnerability that a national authority has notified you about, in writing, has a documented start date for your remediation clock. Under NIS2 Article 21(2)(e), vulnerability handling is a required measure — and the evidence of failure is the notification itself.

This mirrors the pattern in the United States under CISA’s Known Exploited Vulnerabilities catalogue and Binding Operational Directive framework, and in the private sector under the ServiceNow pre-authentication RCE exploited in the wild earlier in July. The common thread: the window between authoritative notification and exploitation keeps shrinking, and regulators increasingly treat that window as the measure of programme maturity.

Backups that did not deliver recovery

A wiped primary database is a recoverable event if — and only if — you hold backups that the attacker could not reach and that you have proven you can restore within a defined objective. A week of national property-market paralysis indicates one of three things: backups that were reachable from the compromised environment, backups that existed but had never been restore-tested at scale, or a recovery time objective that had never been set against the actual business impact.

NIS2 Article 21(2)(c) requires business continuity, “including backup management and disaster recovery.” ENISA’s technical implementation guidance elaborates what that means in practice, and our deep dive on ENISA’s implementation guidance covers the control detail. The operative requirements for registry-class systems:

  • Immutable and offline copies. Write-once storage or physically air-gapped media, held outside the identity domain that the production system trusts.
  • Restore testing at production scale, on a schedule, with the elapsed time recorded and compared against a documented RTO.
  • Recovery objectives derived from impact, not from convenience. For a land registry, the tolerable outage is measured in hours because the downstream effects — mortgage registration, conveyancing, VAT deadlines — are legally time-bound.

The reporting clock

NIS2 Article 23 imposes a staged reporting timeline that applies regardless of how the incident is initially characterised internally:

  • 24 hours from awareness: early warning to the CSIRT or competent authority, indicating whether the incident is suspected to be caused by unlawful or malicious acts or could have cross-border impact.
  • 72 hours: incident notification with an initial assessment, including severity, impact, and indicators of compromise.
  • One month: final report with a detailed description, the type of threat or root cause, applied and ongoing mitigations, and any cross-border impact.

Where an incident is significant, Article 23(1) also requires — where appropriate — notification to the recipients of the service about measures they can take in response. For ANCPI, the service recipients are notaries, financial institutions, and the public, all of whom needed to know within hours that transactions could not be authenticated.

The initial public framing of the outage as a technical incident is instructive. Internal characterisation does not stop the Article 23 clock; awareness of a significant incident does. Organisations that route incidents through a “is it really a cyberattack?” triage step before starting the regulatory clock routinely discover, retrospectively, that they were late.

What private-sector entities should take from a public-sector failure

It would be easy to file this as a story about an under-resourced state agency in a single Member State. That reading misses the transferable lesson, which applies with equal force to any entity in NIS2 scope — and, since Germany, the Netherlands and others completed transposition, that is now a very large population of ordinary companies. See our coverage of Germany’s NIS2 implementation and the October 2026 deadline and management liability.

Three questions, answerable this week:

1. Which of our systems, if wiped rather than merely encrypted, would stop our customers from transacting — and what is the documented, tested restore time for each? Ransomware planning has trained many organisations to think about encryption and extortion. Destruction is a different scenario: there is no key to buy, and no negotiation to conduct. The Romanian case had no realistic payment path. Recovery was the only path.

2. Can any administrative interface to those systems be reached with a username and password alone? If yes, that is the finding. Everything else is secondary.

3. What is our security spend as a percentage of our technology spend on those specific systems? Not organisation-wide — on the systems that carry the impact. If the answer resembles ANCPI’s 0.2%, the proportionality assessment required by Article 21(1) has not been performed, and there is no defensible answer to a supervisory authority that asks for it.

Conclusion

The DNSC’s assessment is the most important artefact from this incident, because it forecloses the usual defence. This was not a nation-state operation against a hardened target. It was leaked credentials plus unpatched, previously notified vulnerabilities, against a system with insufficient recovery capability — and the result was the suspension of an entire national property market at the least convenient moment in the fiscal calendar.

NIS2 does not require entities to be unbreachable. It requires them to hold proportionate, documented, risk-based measures, to report on a clock, and to have management bodies that approve and oversee those measures. On the record as reported, ANCPI can demonstrate none of the four controls most directly implicated: MFA on administrative access, remediation of notified vulnerabilities, isolated backups, and a tested recovery objective.

Each of those is cheap. Their absence cost a country its property market for a week, and produced a written finding from a national authority that the whole thing was avoidable. That finding is the part that will follow the agency into every audit, every supervisory action, and every civil claim that follows.

This article is provided for informational purposes only and does not constitute legal advice.