The belief that publicly accessible beneficial ownership registries are inherently insecure is widespread. Many point to Liechtenstein's breach of 31,000 records as evidence that financial transparency mandates are misguided. Privacy advocates and financial services lobbyists argue that making ownership data accessible creates an irresistible target for attackers.
They're missing the point. The real issue isn't transparency; it's inadequate security measures.
The Real Problem
The Liechtenstein breach, which occurred over two days starting July 29, doesn't prove transparency requirements are dangerous. It shows that government agencies often treat compliance as a checkbox exercise rather than a security design challenge.
Here's what happened: Liechtenstein established its Register of Beneficial Owners in 2021 to comply with EU anti-money laundering rules. The registry went live, and an attacker gained access. The Office of Justice noticed the intrusion and took systems offline. A crisis unit, including Prime Minister Brigitte Haas and Minister of Justice Emanuel Schädler, investigated and confirmed data exfiltration.
What's missing from this timeline? Any evidence that the registry's public accessibility was the vulnerability. The attack vector wasn't detailed in the government's disclosure, but it likely involved weak perimeter controls, insufficient monitoring, inadequate access logging, and delayed detection.
The real issue isn't the existence of the data. It's that the systems housing it were designed with outdated security practices.
Evidence of Security Failures
Consider what ISO/IEC 27002 requires for systems processing sensitive information: network segregation (control 8.20), privileged access management (control 8.2), continuous monitoring (control 8.16), and secure system engineering principles (control 8.27). The NIST Cybersecurity Framework 2.0 calls for identity management and access control (PR.AA), data security (PR.DS), and platform security (PR.PS).
A beneficial ownership registry needs robust threat modeling. You're not protecting credit card numbers that change every few years. You're safeguarding corporate structure data that reveals financial relationships, potentially involving politically exposed persons and high-net-worth individuals. This data has intelligence value, doesn't expire, and can't be rotated once exfiltrated.
This threat profile demands defense in depth: Zero Trust Architecture for all access, Just-in-Time Access for administrative functions, immutable audit logs, network segmentation between public query interfaces and backend databases, and behavioral analytics to detect anomalous access patterns.
The conventional view presents a false choice: transparency or security. France has suffered multiple government database breaches in the past year affecting education records, identity documents, and bank account registries. These weren't created for public transparency but were breached due to outdated IT security practices.
Steps to Improve Security
If you're managing a registry, government database, or any system where compliance mandates data collection and retention, don't treat security as an afterthought.
Start with architecture. Map your data flows using NIST SP 800-53 control AC-4 (information flow enforcement). Identify every system component that interacts with sensitive records. For each, document what the Principle of Least Privilege looks like. If your query interface needs read access to beneficial ownership records, it shouldn't have write access. If your administrative console needs write access, it shouldn't be reachable from the public internet.
Implement continuous monitoring to detect lateral movement. The Liechtenstein breach lasted two days. That's 48 hours of access to 31,000 entity records. Your Security Information and Event Management system should flag unusual query volumes, off-hours administrative access, and data export operations that exceed normal patterns within minutes.
Build your incident response plan before you need it. A crisis unit formed after detection is reactive. Your Computer Security Incident Response Team procedures should define who can take systems offline, how to preserve forensic evidence, and what your notification obligations are under your jurisdiction's breach disclosure rules. If you're subject to the General Data Protection Regulation's 72-Hour Notification Requirement, you need playbooks ready, not crisis meetings.
Conduct tabletop exercises assuming your perimeter will be breached. Test whether your network segmentation contains an attacker. Verify that your privileged access controls prevent lateral movement. Confirm that your logging captures enough detail to reconstruct the attack timeline.
When Critics Have a Point
Critics of public registries have a valid concern when transparency is mandated without the necessary resources or expertise to secure the systems.
If you're a regulator requiring beneficial ownership disclosure, you can't just issue the requirement and walk away. Provide implementation guidance that includes security architecture patterns, recommended controls mapped to recognized frameworks, and audit requirements to verify those controls are effective.
If you're a small jurisdiction like Liechtenstein, you may need technical assistance or shared infrastructure to meet registry requirements comparable to larger countries. Running a secure registry isn't just about buying security tools. It requires specialized expertise in threat modeling, security engineering, and incident response that may not exist in-house.
The answer isn't to abandon transparency. It's to recognize that compliance obligations create security obligations, requiring funding, expertise, and ongoing attention.
The Liechtenstein breach should prompt every organization running a compliance-mandated registry to ask: if an attacker spent two days in our systems, what would they take? And more importantly: would we even know they were there?
