The physical location of data affects latency, regulatory obligations, disaster recovery and which national authorities have immediate territorial jurisdiction. Location answers only where the servers sit.

But, who controls the infrastructure, who can access the information, which foreign laws apply to the provider or whether another government can compel disclosure.

Residency is not sovereignty

Data residency refers to the physical/geographic location where information is stored. The Government of Canada’s own digital guidance explicitly distinguishes it from sovereignty, which concerns a country’s authority over access to and disclosure of information.

A company announces a Canadian data centre and calls the service sovereign. A US cloud provider creates a European region and markets it as local control. Procurement ticks the residency box, legal approves the contractual clauses and executives assume the jurisdictional problem has been resolved. It hasn’t.

Data residency tells you where the information is stored.

Data protection tells you which rules apply about handling of the data.

Data control tells you who can technically retrieve, process or disclose it.

Data sovereignty tells you which jurisdiction has enforceable authority over that control.

These conditions can overlap, but they’re not interchangeable. Data can reside in Europe, receive GDPR protection and still be accessible to a company under American law.

The Government of Canada acknowledges this directly. Its 2026 white paper on public-cloud sovereignty states that government data entrusted to a foreign cloud provider may remain subject to that provider’s home-country laws even when the data resides in Canada. It identifies the central risk: foreign authorities may use their domestic laws to compel the provider to surrender Canadian government information.

Canada’s data-sovereignty white paper very clearly describes the legal structure of modern cloud computing.

The CLOUD Act

Microsoft is subject to American law, including the CLOUD Act. (I’ve written about this issue many times in the past, the most recent one just over 12 months ago.)

Microsoft’s own explanation says that US law enforcement can compel service providers to produce information within their “possession, custody or control,” regardless of where that information is physically located. Read that again. Carefully.

The CLOUD Act doesn’t need to move a European server into the United States. It reaches the American company controlling the server.

Microsoft says it scrutinises government demands, rejects those that aren’t legally valid, challenges disproportionate orders and attempts to redirect authorities to enterprise customers. Microsoft says that governments don’t receive direct, unrestricted access to its systems. They reduce abuse and provide more accountability than in many other jurisdictions. But that’s not sovereignty.

If Microsoft receives a valid and enforceable American order, it must comply. The company may challenge the demand, narrow it or notify the customer where legally permitted. It can’t promise that European or Canadian information will never be disclosed to American authorities.

It’s the legal reality Microsoft itself acknowledges in its government-request disclosures. It’s not an accusation.

The EU Data Boundary reduces exposure

Microsoft has invested heavily in its EU Data Boundary, allowing European customers to store and process substantial categories of Microsoft 365, Azure, Dynamics 365 and Power Platform data within the EU and EFTA. Keeping more information inside Europe reduces unnecessary transfers, simplifies compliance and limits some operational exposure.

But Microsoft’s documentation also lists circumstances in which information continues to move beyond the boundary. These include global security operations, technical support, communications with users outside Europe, customer-configured integrations and certain professional-services data. Some information may be accessed remotely by personnel outside the EU, while some support and consulting material may be stored in the United States.

Microsoft describes this accurately: it significantly reduces data flows outside Europe. It doesn’t claim that it’s isolated from non-European access.

Microsoft’s EU Data Boundary documentation makes the limitations visible to anyone that reads past the marketing summary.

Even if every operational transfer were eliminated, however, the central jurisdictional issue would remain. Microsoft Corporation is still an American-controlled entity.

Compliance frameworks don’t transfer sovereignty.

Europe has built legal mechanisms to govern information moving to the United States. Standard Contractual Clauses establish obligations between exporters and importers. The EU–US Data Privacy Framework allows participating American companies to receive European personal information under an adequacy decision. Without these mechanisms, much of the transatlantic digital economy couldn’t legally function.

The Court of Justice of the European Union demonstrated that distinction in the 2020 Schrems II judgment. It invalidated the previous EU–US Privacy Shield because American surveillance law didn’t provide protections essentially equivalent to those required in Europe.

The current Data Privacy Framework was created to address those deficiencies. It may provide a valid legal transfer mechanism, but it doesn’t make American providers European, repeal the CLOUD Act or remove US intelligence and law-enforcement authority.

Control matters more than the address of the server

• Can the provider retrieve intelligible customer information?

• Can the provider’s employees or systems access it?

• Can the provider independently decrypt it?

• Can the provider be compelled by a foreign government to disclose it?

• Can that government prohibit the provider from notifying the customer?

• Can the provider suspend the service or deny continued access?

If the answer to these questions is yes, the customer may have residency, compliance and contractual protection. It doesn’t have complete sovereignty. Information may be encrypted while stored and while moving across networks, but if the provider controls the keys or must decrypt the information to process it, the provider still occupies the point of access.

That may be acceptable for ordinary workloads, but not for defence, healthcare, judicial records, intellectual property, critical infrastructure or government decision-making. Sovereignty is not a single setting. Different information requires different levels of control. Public websites and routine administration don’t need the same architecture as military communications or national identity systems.

Sovereignty requires architectural limits

True digital sovereignty can’t depend on a provider promising to refuse access. It needs systems designed so that the provider can’t independently access plaintext.

That means separating identity from disclosure, keeping meaningful control of cryptographic keys with the customer, segmenting information so one compromised service can’t expose everything, and enabling computation without routinely revealing the underlying data.

The objective isn’t to make lawful investigation impossible. It’s to ensure that access to sensitive information occurs through the authority that owns it, under the applicable domestic legal process, not through a foreign-controlled intermediary.

Europe is beginning to recognise the difference

The renewed European push for sovereign cloud services, open infrastructure and EuroStack reflects a growing recognition that regulation alone can’t fix structural dependency.

Europe can regulate foreign platforms, negotiate transfer frameworks and require contractual safeguards. But if its governments, businesses and critical services are dependent on infrastructure controlled elsewhere, Europe is governing a dependency. Building European alternatives would change that. It brings corporate control, infrastructure and legal jurisdiction closer together.

A European provider that can freely access every customer’s plaintext creates a different jurisdictional arrangement, not a complete security architecture. But it changes who sets the terms, who controls continuity and which legal system has the final word. That’ real data sovereignty.

The other sits inside the building. It has access to email, documents, meetings, calendars, internal communications, location data, wireless connectivity, microphones, cameras, remote software updates and potentially everything an employee can retrieve through Microsoft 365. Its manufacturer has openly acknowledged that it can be compelled by the US government to surrender information, even when that information is stored outside the United States.

The first is treated as a potential espionage platform. The second is called productivity infrastructure.

That oxymoron is at the centre of the Western debate about Chinese electric vehicles. But if foreign jurisdiction and compelled disclosure are the concern, we should be looking at both the same way.

The concern about Chinese vehicles is not imaginary

Modern vehicles are rolling sensor platforms. They record location, speed, driving behaviour, voice commands and information about nearby devices. Exterior cameras observe roads, buildings, people and other vehicles. Driver-monitoring systems may record facial position, attention and movement inside the car. Remote diagnostics and over-the-air updates give manufacturers continuing technical relationships with vehicles long after they leave the factory.

That creates real security issues around military bases, government buildings, critical infrastructure and senior officials. A compromised or deliberately manipulated vehicle could collect useful intelligence or provide a route into connected systems.

Chinese companies also operate under laws that can require cooperation with Chinese state authorities. Czechia has good reason to take that seriously. Its government has attributed cyberattacks against the Czech Ministry of Foreign Affairs to a group associated with China’s Ministry of State Security, while NÚKIB has repeatedly warned about technology subject to Chinese state influence.

It’s not paranoia, if they’re actually after you. Is it? The issue isn’t that, really. It’s how selective we are in applying that standard.

Microsoft has already acknowledged the jurisdictional reality

Microsoft is subject to American law, including the CLOUD Act. The company’s own explanation is unambiguous: US authorities can compel American service providers to disclose information within their “possession, custody or control,” regardless of where that information is physically stored.

Microsoft says it examines every demand, rejects those it considers invalid, redirects authorities to enterprise customers where possible and challenges disproportionate orders. It also says governments don’t receive direct or unrestricted access to customer systems.

The American legal process may be more transparent and contestable than the Chinese version. But that doesn’t change the final answer.

If Microsoft receives a valid and binding American order, it has to comply. The location of the data centre doesn’t matter. In some cases, a secrecy order may stop Microsoft from notifying the affected customer.

Microsoft publishes figures showing that demands involving foreign enterprise data are rare. That’s irrelevant to the underlying sovereignty question. A little used foreign power is still a foreign power.

Microsoft’s government-request policy outlines both the protections and the obligation.

Copilot is already inside operations

Canada has authorised Microsoft Copilot for use across parts of the federal government. Its implementation policy limits the browser-based service to unclassified information, requires government identities and mandates Microsoft’s enterprise-data-protection settings. The Department of National Defence similarly identifies Copilot as its approved generative-AI tool, subject to restrictions on the information employees may provide. That, at least, shows that Canada is trying to manage the risk.

Czech public administration is also adopting Copilot. The Czech Ministry of Justice describes officials using it for everyday work, including routine analysis, presentations and communication. The Digital and Information Agency has trained employees to use Copilot and create AI agents for administrative processes.

Again, that doesn’t mean Czech or Canadian officials are recklessly feeding classified plans into a public chatbot. But it does mean both governments accept Microsoft as a trusted operational partner despite the company being legally subject to a foreign state. Does anyone else see the problem with this arrangement?

• Chinese legal compulsion is presented as state control. American legal compulsion is presented as lawful process.

• Chinese telemetry is described as surveillance. Microsoft’s access to government information is described as enterprise integration.

• Chinese remote software is a potential kill switch. American cloud dependency is a service contract.

The technology may be different, but the underlying sovereignty issue isn’t: can a foreign-controlled provider access sensitive information, and can its home government compel it to disclose that information? If that point is problematic, the flag of the country shouldn’t matter.

A car may know where an official drove. Copilot may know what the official decided.

A connected vehicle can reveal travel patterns, visited locations and proximity to sensitive facilities. That can be valuable intelligence.

Microsoft 365 may contain policy discussions, legal advice, budget documents, procurement decisions, internal disagreements, security assessments and communications between senior officials. Copilot can make that information easier to locate, summarise and correlate because that is precisely what it is designed to do.

An EV (Chinese or otherwise) may know where an official drove. Microsoft may know what that official wrote, read, discussed and decided. So why is the first looked at as the more obvious sovereignty threat?

This is less about technical capability than political alignment. American access is regarded as allied, rules-based and manageable. Chinese access is regarded as hostile by definition.

The American response is clear

The United States has used tariffs and connected-vehicle rules to keep most Chinese EV manufacturers out of its market. Polestar, despite its Swedish identity and increasingly diversified manufacturing, has been caught by these restrictions because of its relationship with Geely.

This applies even when vehicles are assembled outside China. Moving production to South Korea or South Carolina may change the country of origin, but it doesn’t necessarily change the ownership, software or remote-control analysis used by American regulators.

Volvo, which is also controlled by Geely and shares substantial technology with Polestar, has received different treatment. When two closely related companies using overlapping platforms produce different security decisions, industrial policy and domestic market protection begin to look at least as important as cybersecurity.

Apply the same standard to everyone

The answer isn’t to ignore Chinese technology risks or prohibit governments from using Microsoft. The latter would take years to unravel. It’s to stop treating corporate nationality as a substitute for architecture.

Governments should identify what information a system collects, where it is processed, who can access it, which jurisdictions can compel disclosure and whether the provider can surrender intelligible information without the customer’s consent, or knowledge.

Sensitive facilities can restrict vehicles with externally controlled telemetry regardless of whether the manufacturer is Chinese, American or European. Government cloud systems can require local operational control, independent auditing, strong segmentation and encryption that prevents service providers from accessing usable plaintext.

Restrictions should follow the information and the architecture. Not the flag or origin. Europe and Canada can’t argue that sovereignty is threatened whenever Chinese law reaches into a vehicle and, at the same time, be indifferent when American law reaches into the cloud.

The Chinese EV will continue to be called a spy while Microsoft remains infrastructure. Which is the bigger problem?

Sharing a result isn’t the same as sharing the source

Imagine one intelligence service has information about a suspected individual. Another country needs to know whether that person appears in the dataset. A third wants to determine whether the individual has connections to entities already under investigation. None of that automatically means access to the complete record.

One country needs confirmation. Another needs the result of a query. And another needs to establish that a threshold has been reached. Systems tend to solve all three problems the same way. Moving data. Once that happens, the original owner loses control over what comes next. The information now exists inside another country’s infrastructure, under another set of administrators, policies, suppliers and legal obligations.

Every copy is a security problem

Intelligence-sharing creates dependencies between organisations. The more information shared, the larger those dependencies become. A dataset copied to five partners now has six security perimeters. If those partners make more copies, the number grows further. So do the administrators, applications, backups and systems capable of interacting with it.

This is an argument against treating data duplication as the default mechanism.

Ask the data without taking the data

This is where privacy-enhancing cryptography becomes useful. ZKPs can allow one party to prove that a condition is true without disclosing all of the information behind that proof. FHE can allow certain computations to be performed while the underlying information remains encrypted.

Instead of transferring an intelligence dataset so another party can inspect it, the architecture can potentially allow tightly defined questions to be answered against protected information.

• Does this identifier appear in the dataset?

• Does this entity satisfy an agreed risk condition?

• Do two datasets contain a relevant relationship?

• Does this transaction pattern exceed a predefined threshold?

The recipient gets the answer without automatically receiving everything used to produce it.

Need-to-know should actually mean need-to-know

Security organisations have used the phrase need-to-know for decades. Realistically? It usually means need-to-access. A person or system is authorised to retrieve a record, after which the burden shifts to access controls, policy and monitoring to ensure it isn’t misused. That works, until it doesn’t.

Limit the exposure

Alliances don’t work without cooperation, and intelligence relationships depend on high levels of institutional trust. But trust doesn’t mean unlimited access. Two governments may trust each and still have legitimate reasons to restrict access to particular sources, identities, methods or datasets. The same applies to defence contractors, law-enforcement agencies, financial institutions and operators of critical infrastructure.

If a partner’s access becomes narrower, the architecture can narrow the questions it’s allowed to ask rather than trying to recover information already copied elsewhere. If another organisation joins the relationship, it can be granted precisely the capability it needs without inheriting broad access because it is easier operationally.

Where PrivID fits

This is one of the areas where PrivID’s combination of ZKP, FHE, segmentation and bounded access is relevant. Data can stay under the control of the organisation responsible for it. Other authorised parties can receive proofs, results or tightly restricted access without automatically receiving the underlying information.

• With computation over encrypted data, the infrastructure doesn’t neeed plaintext visibility.

• When verification can rely on a proof, the verifying party doesn’t need details.

• Where access is segmented, one relationship doesn’t just expose everything.

None of this eliminates conventional security controls. Authentication, endpoint security, monitoring, key management and operational discipline are still crucial. But failure in one of those controls doesn’t automatically expose everything else.

Cooperation without accumulation

The geopolitical environment is pushing governments towards two objectives:

1. Share more information because threats increasingly cross borders, networks and jurisdictions.

2. The need for more control over sensitive data, infrastructure and national dependencies.

The solution? Share the minimum information required to produce the necessary outcome. Granted, it’s easier said than done, but PrivID has been working on that solution for eight years.

In 2025, CISA and international partners described Chinese state-sponsored actors compromising telecommunications, government, transportation, lodging and military infrastructure around the world. The activity, overlapping with what industry calls Salt Typhoon, included modifying routers to maintain long-term access and using compromised infrastructure and trusted connections to move into other networks. The intelligence value included identifying and tracking communications and movements of targets.

Assume they’re already inside

APT28 has compromised routers. Volt Typhoon has maintained access to critical infrastructure environments for years. Salt Typhoon-linked activity has penetrated telecommunications infrastructure across multiple countries. CISA says Volt Typhoon has used legitimate accounts and ordinary administrative tools to blend into normal operations, with evidence of access persisting in some environments for at least five years. The takeaway should be that prevention eventually fails somewhere.

A credential gets stolen. A supplier gets compromised. A vulnerability stays unpatched. An administrator makes a mistake. A trusted connection is abused. A perfectly legitimate system tool is used for something illegitimate. If gaining access exposes useful plaintext, broad identity records, administrative relationships, internal datasets and pathways into neighbouring systems, then one breach can become an intelligence platform.

Intelligence doesn’t need a big theft

Metadata can be intelligence. Who queried a particular record? Which executives communicate frequently? Which government departments exchange the most valuable information? When does activity increase? Which systems talk to one another? Which administrator can reach a sensitive environment? Which identity appears across several datasets? Once those puzzle pieces come together the picture gets very clear.

The telecommunications compromises associated with Chinese state-sponsored activity illustrate the point. Control of backbone and edge infrastructure can reveal patterns of communication and movement even before we start talking about message content.

Stopping unauthorised entry is essential, but preventing entry and preventing disclosure are not the same control. We need to stop treating them like they’re the same thing.

Access shouldn’t create knowledge

Once an attacker gains the right account, process, machine or administrative position, the same visibility that makes the system useful can make it valuable for espionage. Because most conventional systems are designed around a straightforward assumption: authorised software receives usable information so that it can process it.

• The application sees the plaintext.

• The administrator can query the database.

• The analytics platform receives the records.

• The identity service knows the attributes.

• The infrastructure contains enough context to reconstruct relationships between them.

Systems try to contain the attacker inside a system. A system that is designed to reveal information to anything occupying the correct position. Does that sound like a valid way to protect a sensitive system and its data?

Make persistence less useful

Under conventional architecture, the verification process can have access to the underlying identity record. Compromise the process and the attacker can gain access to those records. With a zero-knowledge approach, the system could instead receive proof that the requirement has been satisfied without receiving all of the attributes behind it. Which means that there is a lot less data to compromise.

If infrastructure needs to calculate something using sensitive information, FHE can allow classes of computation to happen while that information remains encrypted. But, FHE doesn’t make the compromised infrastructure trustworthy, by default. It just means the compromise doesn’t have to produce the same amount of disclosure.

This is where PrivID fits

This is one of the reasons we’re combining ZKPs, FHE, segmentation and tightly bounded access within PrivID. The objective isn’t to claim that an attacker can never get into a PrivID-enabled environment. No organisation can make that promise or guarantee.

Endpoints can still be compromised. Credentials can still be stolen. Implementation flaws can still exist. Infrastructure still needs patching, monitoring, authentication and conventional security controls.

The assumption about what successful access means changes:

• A system only needs to know that a condition is true.

• Infrastructure only needs to perform a calculation, not expose the entire system.

• If one component is compromised, segmentation limits how much of the environment is visible.

• If an attacker obtains persistence, that persistence doesn’t automatically mean unrestricted access or observation.

The attacker prefers you don’t notice

A persistent intelligence operation benefits from stability. Breaking systems attracts attention. Encrypting servers ends access. Dramatic exfiltration may trigger alerts. Staying quietly embedded is more useful.

Volt Typhoon’s use of legitimate tools and accounts is a good example. CISA and partner agencies have repeatedly warned that “living off the land” techniques allow malicious actors to blend into ordinary system activity and avoid some conventional detection mechanisms.

Under those conditions, what can those tools see? The answer is “almost everything the legitimate system could see”. That is a problem.

Breach and disclosure should be separate failures

Cybersecurity has spent years talking about defence in depth, but some of our most important systems still allow multiple security failures to collapse into one another. A breach shouldn’t automatically be a disclosure event, an identity compromise, an intelligence windfall and a pathway into everything connected to it.

We can’t intrusion impossible, especially against sophisticated state actors with time, money, specialised personnel and a strategic reason to remain persistent. The most effective spy may not steal anything. They may just sit inside your infrastructure and let your own systems tell them what they want to know.

In 2025, Indian energy company Nayara Energy lost access to parts of its Microsoft infrastructure after European sanctions affected the company because of its Russian ownership links. Outlook and Teams were disrupted, and the company began moving communications to an Indian provider. Nobody hacked Microsoft. Nobody stole Nayara’s credentials. The infrastructure hadn’t failed. The political conditions changed.

Now consider the International Criminal Court.

The Trump administration has imposed sanctions on ICC judges, prosecutors and other officials over investigations and proceedings involving American and Israeli nationals, including the cases surrounding Israeli Prime Minister Benjamin Netanyahu and former defence minister Yoav Gallant. As of August 2026, nine of the Court’s eighteen judges had been sanctioned by the United States.

Whatever your position on the ICC’s jurisdiction, the mechanism used by the Americans matters.

The sanctions don’t just freeze assets in the United States. Their practical effect travels through the financial and technology systems which much of the world depends on. Sanctioned ICC judges have described cancelled credit cards, disrupted banking and loss of access to services from major technology companies. Canadian ICC Judge Kimberly Prost has specifically described the reach of Visa, Mastercard, American Express and SWIFT as part of the practical impact of being sanctioned. The United States sits at critical points in the infrastructure they use. That is a cybersecurity issue, whether call it that or not.

Dependency is a form of control

Cybersecurity still tends to think about control in terms of access. A cloud provider doesn’t have to be hostile to become unavailable. A payment network doesn’t have to be compromised to stop processing transactions. A software company doesn’t need malicious intent for accounts, licensing or updates to disappear. A semiconductor manufacturer doesn’t have to attack anybody for export controls to make its products inaccessible.

Sometimes the supplier actively complies with government policy. Sometimes it has no realistic choice. This is the part of supply-chain security that few want to talk about. Organisations spend enormous amounts of effort assessing whether vendors themselves are secure. What happens when the vendor is perfectly secure and you can’t use it?

Built deliberately

Over the past twenty years, organisations have intentionally moved more of their infrastructure outside their direct control. Servers became cloud services. Software became SaaS. Identity became federated. Communications became platforms. Updates became continuous. Hardware became more specialised and globally sourced.

These ‘rational’ decisions reduced costs, improved scalability and gave organisations access to capabilities they could never economically reproduce themselves. They also created a very different security perimeter.

An organisation can rely on multiple vendors throughout its technology stack. That’s the issue at hand. If a provider controls authentication, licensing, updates or a critical portion of the underlying compute, then somebody outside your organisation can affect what happens inside it without penetrating your network.

The ICC sanctions make that point very clear. The judges didn’t decide that American payment and technology infrastructure was geopolitically important to them. They simply used ordinary financial and online services, as almost everyone does. Once sanctions were imposed, the architecture of the global financial system did the rest.

Sovereignty isn’t just a flag on a server

European cloud. Canadian cloud. Domestic processors. Domestic software. Domestic infrastructure. There’s a real argument for increasing domestic capability, especially in critical sectors. But pretending any modern economy can simply remove foreign dependency is just kidding yourself.

A European cloud service may run on American-designed processors manufactured in Asia. A Canadian cybersecurity product may depend on European libraries, American operating systems and globally manufactured hardware. A supposedly sovereign platform can contain dozens of external dependencies before anyone gets to the application layer.

Changing the nationality of the logo doesn’t necessarily change the architecture. Use foreign technology when it’s the best technical or commercial choice. But know what the supplier controls. Know what it can see. Know what happens if access disappears. Know whether replacing it involves changing a component or rebuilding the system.

Capability doesn’t mean unlimited visibility

This is where infrastructure dependency and information dependency become unnecessarily entangled. A cloud provider supplies compute, so plaintext becomes visible somewhere inside the computing environment. An identity provider verifies someone, so it gets the underlying identity information. A partner performs a compliance check, so it gets the records. A collaborator needs the answer to a question, so it gets the dataset. We’ve become used to these arrangements because that’s the way it’s ‘always been done’. Maybe. But, that doesn’t mean it should stay that way.

ZKPs can allow one party to establish that a condition is true without exposing all of the information used to prove it. FHE can allow computation to occur while the underlying data remains encrypted. These technologies don’t eliminate a supplier. They do eliminate ‘how much’ the supplier sees.

A cloud platform using this encrypted computation can reduce visibility into a workload. A partner may still perform a verification, but a proof can reduce the amount of underlying identity information it receives. Organisations can still cooperate without automatically creating another plaintext copy every time information crosses an institutional boundary.

This is the PrivID argument

PrivID isn’t based on the idea that infrastructure dependency can somehow disappear. It can’t. FHE won’t keep a cloud provider online if a government prevents it from serving you. ZKP won’t manufacture processors when export restrictions cut off supply. Cryptography won’t make SWIFT process a transaction or force a payment network to keep somebody’s account open. Those are availability and geopolitical problems.

They do eliminate the volume of data needed for a decision to be made. They reduce the vulnerabilities that exist within a ‘plaintext’ system.

You don’t need an enemy

The ICC example is useful because it removes one of the easier assumptions from the argument. The United States and many ICC member states remain close allies. Japan, Canada, the Netherlands and European states haven’t suddenly become American adversaries because they disagree with Washington over the Court (arguably).

Yet American influence over global financial and technology infrastructure gives a domestic sanctions decision effects far beyond American territory. Japan publicly criticised the August sanctions against ICC President Tomoko Akane, while the Netherlands and Germany reaffirmed support for the Court. Alignment is conditional. Dependency is technical.

The supplier doesn’t need to become your enemy. Your ally doesn’t need to become your enemy. Nobody needs to breach anything. The political conditions governing an existing dependency simply have to change.

There will always be dependencies because modern technology is too interconnected. The objective is architecture that recognises the difference between using somebody else’s capability and placing yourself entirely under their control.

There may also be decades of institutional cooperation, shared history and genuine cultural affinity. But underneath all of that is pragmatism: mutual benefit and mutual need. There’s nothing particularly cynical about that. It’s how international relationships work.

Alignment is not permanence

Two countries can be allies while disagreeing sharply over trade — sound familiar? They can cooperate militarily while restricting technology exports, share intelligence while withholding particular categories of information, or agree on one geopolitical threat while seeing another completely differently.

A change of government doesn’t need to end an alliance to change the priorities. Privacy policy can shift. Intelligence priorities can change. Sanctions and export controls can expand. Procurement requirements can become more restrictive. Governments can decide that domestic technology or infrastructure should receive preferential treatment, or that certain foreign dependencies are no longer acceptable. Things change, assuming they won’t is the mistake.

We turn political decisions into technical facts

When two organisations decide that cooperation is mutually beneficial. Access is granted, systems are connected, data begins moving between them, APIs are opened and administrative privileges are created. Cloud environments become interconnected, databases may be replicated and identity systems begin recognising one another.

We trust them today over time becomes the system assumes they’re trusted. The first is a judgement. The second can persist long after the original circumstances have changed.

Subscribe now

Trust is rarely binary in the real world

Cybersecurity has a tendency to simplify trust into something approaching a binary switch. Geopolitics and business don’t work that way. The real-world version is trusted for this purpose, under these circumstances, while these interests are aligned.

A supplier may be trusted to operate infrastructure without being entitled to inspect customer data. A partner may need to verify a transaction without retaining the underlying identity information. A foreign agency may need to determine whether a particular condition exists without receiving the entire dataset. A cloud provider may provide the compute without necessarily needing visibility into what is being computed.

Architecture should be able to differentiate between the different forms of trust needed in each scenario. That isn’ t really the case.

Sharing isn’t surrendering control

Digital cooperation still follows a very crude model: if another party needs information, we give them the information. We may encrypt it while it travels, authenticate the recipient before releasing it, log what they subsequently do and restrict its permitted use through contracts or policy.

Now they have a copy. Their administrators can access it. Their infrastructure becomes part of the security perimeter. Their jurisdiction matters. Their backups matter. Their suppliers matter. Even their future relationships with other organisations or governments can matter.

In other words, we** begin inheriting risks.** Cooperation involves dependency to some degree. The extent of that dependency needs to be an architectural choice. When organisations decide whether to cooperate, they usually ask: Do we trust them?

Does the other party need the underlying data, to the extent provided? It may only need proof that a particular condition has been satisfied, the result of a calculation, or access to one tightly bounded portion of information. Maybe access is necessary for an hour rather than indefinitely. Maybe an organisation needs to verify something without learning everything that was used to establish the result.

Under these conditions, technologies such as zero-knowledge proofs and fully homomorphic encryption start looking more like tools for defining relationships. A ZKP can establish that something is true without disclosing all of the information behind the proof. FHE can allow computation to take place while the underlying information is encrypted. In other words, trust becomes precise and conditional at every step.

Trust shouldn’t mean visibility

This is one of the assumptions behind the architecture we’re developing at PrivID. We’re not trying to answer the political question of who should trust whom. Technology can’t make that decision, and it shouldn’t. It can determine is what trust allows.

If an organisation needs proof, it should be possible to provide the proof not everything behind it. If it needs the result of a computation, the result should be enough. If access is temporary, the architecture should reflect that. If someone needs one attribute, why are they getting access to all the attributes in all the records. Visibility shouldn’t automatically be the price of cooperation.

Allies don’t need to become enemies

Today’s ally could eventually become tomorrow’s hostile state. Could that happen? Of course. Does it need to happen for the risk to matter? Not remotely. The much more likely scenario: the ally remains an ally, but interests diverge.

A new government sees trade differently. A court interprets access powers differently. A supplier becomes subject to new regulation. Sanctions change. A technology becomes export-controlled. A country decides that its domestic industrial base comes first. An intelligence-sharing agreement becomes narrower than it was before.

Sovereignty is the ability to change your mind

Modern infrastructure depends on international suppliers, global standards, foreign intellectual property, shared research, cross-border networks and extraordinarily complicated supply chains. Trying to remove every external dependency would probably leave you with very little functioning technology.

Can you change providers without rebuilding everything? Can you reduce somebody’s access when circumstances change? Can you revoke a relationship, move a workload or alter who can see particular information while the rest of the system continues operating?

Can you cooperate with another organisation without automatically making it part of every trust boundary? If you can’t, you don’t really have technological sovereignty.

Political assumptions belong in the threat model

Cybersecurity traditionally focuses on hostile behaviour: attackers, malware, credential theft, misconfiguration, malicious insiders and supply-chain compromise. All of those deserve the attention they receive. Some of the most consequential risks facing modern infrastructure begin with assumptions.

We assume a country will remain aligned with us, a provider will remain available, a legal framework will remain valid, a supplier will remain acceptable, an administrator will remain authorised or an information-sharing arrangement will continue to make sense. The mistake is building systems that treat them as unchangeable.

Political relationships change. Commercial relationships change. Legal frameworks change. Even alliances change in character without disappearing altogether. Technology architecture should be capable of recognising that reality.

The objective isn’t to create a world in which nobody trusts anyone. That would make cooperation almost impossible. Countries will continue working together because their interests overlap. Companies will continue depending on suppliers because doing so makes economic and technical sense. Allies will continue sharing information because mutual need demands it.

But, assuming that today’s relationship will be tomorrow’s relationship is a mistake.

Science Fiction and Fiction is interesting because it tends to reflect what we, as a society fear. Before movies, shows and the internet (tiktok, YouTube, Instagram etc), it was books. This article will also make it pretty clear, I have seen too many movies and read too many books. I make no apologies.

During the Cold War, American movies and TV were full of invasion stories, hidden enemies, humanoid aliens, nuclear disaster and survival stories. On the surface they were about aliens, monsters or radiation. Beneath the surface, however, they were usually about other things: infiltration, ideological conformity, annihilation, loss of control and the suspicion that the person standing beside you might not be who you thought they are/were.

The Monsters

Werewolves aren’t just about violence. They’re about transformation, the kind adults can’t control. Puberty is an obvious reading: the child you knew becomes physically and psychologically different, almost overnight. The werewolf, in a broader sense, works whenever one generation doesn’t like what the next generation is becoming.

Zombies? They can be anything we’re afraid of. They’ve represented consumerism, conformity, contagion, social collapse and the disappearance of individuality into the crowd.

They Live is a great example. It combines so many anxietes.. It isn’t just an alien-invasion story. The invasion has already happened. The mechanisms through which people see reality have been captured. Advertising, authority and consumption are all part of the same system, and almost everyone accepts it because they can’t see that there’s anything to question.

Body-snatcher stories? Their real horror isn’t infiltration. It’s the loss of autonomy. You still look and talk like you. But something about you has disappeared.

Those story lines and monsters are adaptable to any era, that’s why they work so well. Communist infiltration worked as one interpretation during the Cold War (something the current US regime is trying to resurrect), but the same mechanism can stand in for ideological conformity, religious authority, corporate culture, political movements or virtually anything else capable of replacing individual judgement.

The Wrong AI Story

For decades, AI has been some variation of Terminator/Skynet. The machine becomes intelligent. It decides humanity is the problem. Humans lose control. Things explode. Great for movies, but more an exagerated version of reality. It’s not whether AI becomes like us, but, whether we become more like AI.

That doesn’t need artificial consciousness. It doesn’t need malicious intent. It doesn’t even need anybody to make a deliberate decision. It just needs constant interaction.

Humans adopt the language of the environments around them. We absorb vocabulary, sentence structures, assumptions and ways of framing problems from family, schools, books, work, television, social media and the people we spend time with. AI is no different. Spend enough time interacting with it and its patterns become yours.

That creates problems for the idea of AI detection. Most detection systems assume that human and machine writing are different categories that one can be statistically separated from the other. But what happens when humans begin to write like systems trained on humans who themselves have increasingly interacted with AI?

Human language influences AI → AI language influences humans →those humans create new text.

That text eventually becomes part of the broader information environment from which future AI systems learn. At some point, asking whether a particular turn of phrase is “human” or “AI” starts to become its own kind of problem. The classic Catch-22.

The Generation That Never Knew Before

Older people view AI as something added to an existing cognitive framework. They remember researching without it. Writing without it. Getting lost without GPS. Sitting with questions because the answer wasn’t immediately available.

Someone growing up with AI may never know, or understand, that. For them, thinking with AI may just be thinking. That doesn’t make the younger generation less intelligent (ok, the jury’s still out on that, I’m giving the benefit of the doubt). They may develop a fundamentally different relationship with knowledge and reasoning. And that’s where older cultural fears begin to reappear.

The anxiety starts looking less like Terminator and more like The Midwich Cuckoos (or the movie that was made from that book - The Village of The Damned).

The kids in Midwich look human. They belong to the community around them. But they think differently, communicate differently and operate according to a framework the adults don’t understand. The fear is that they’re our children, but not like us.

Children of the Corn plays with a related fear. The younger generation develops its own authority structure, values and worldview, and the adults become irrelevant or hostile simply because they belong to the old order.

One generation may look at another and say: You’re becoming dependent. You’re losing the ability to think for yourselves.

The younger generation may respond: No. We’re thinking differently because the tools available to us are different.

When the Tool Becomes Mother

What about when AI stops being just software and becomes the thing you ask when you don’t know.

• It explains.

• It reassures.

• It corrects.

• It advises.

• It resolves disputes.

It tells you what word means, what a political argument means, what your symptoms might mean, how to phrase something, whether an idea is reasonable, what you should buy, where you should go and how you might interpret what somebody else just said. It begins to occupy a psychological role that technology hasn’t occupied before. Mother. It becomes the ever patient parent.

Now we’re somewhere between Idiocracy and Demolition Man. Idiocracy shows a society in cognitive decline, serious thought is neither exercised or rewarded. Demolition Man on the other hand shows something different: a society whose behaviour, language and acceptable norms have been engineered into a narrow band of supposedly safe, civilised conduct.

Combine those with an AI system that people willingly consult for almost everything and you get voluntary deference. Not just control. Independent thought becomes less convenient.

• Why spend an hour figuring out a problem when the system can explain it in thirty seconds, or less?

• Why research five sources when the system can summarise them?

• Why construct an argument from scratch when the system can help organise it?

Those points are the problem for an individual. Scaled? That’s different.

The Quiet Convergence

First, cognitive outsourcing. People retain less information and practise fewer reasoning processes because retrieval, synthesis and explanation are always available externally.

Second, linguistic convergence. Millions of people interacting with similar systems begin absorbing similar vocabulary, rhetorical structures and ways of explaining things.

Third, normative convergence. People don’t just absorb how the system speaks. They absorb what the system sees as reasonable and sensible.

In They Live, the system has deliberately manipulated perception. Now, instead of aliens look at AI. If enough people turn to the same systems to interpret a bigger portion of reality, those systems inevitably shape the cognitive environment.

Nobody Has to Become a Zombie

This also creates a version of the zombie metaphor. Traditional zombies lose individuality and become part of a mass, we could also be discussing Pluribus here. (Let’s not get into the speed of zombies etc. argument)

Imagine a society where everyone stays intelligent, self-aware and convinced of their own independence at the same time becoming more similar in how they structure information, frame arguments and resolve uncertainty.

Nobody’s been hypnotised. Nobody’s surrendered consciousness. Nobody’s joined the hive. But a type of cognitive convergence still happens. Everyone is adapting. Something we humans do really well.

Who Controls Whom?

This is really the crux of the AI issue. Not whether AI controls humans. Not whether humans control AI. But how does prolonged interaction change both sides to the point where it becomes harder and harder to say who’s thought it is.

We train machines on human output →the machines interact with humans → humans absorb aspects of machine behaviour → those humans produce new culture → future systems learn from that culture. This becomes it’s own system.

• Older generations see it as a loss of autonomy.

• Younger generations see it as augmentation.

• One group sees dependency.

• The other sees efficiency.

• One sees the disappearance of independent reasoning.

• The other sees it as pointless nostalgia.

Neither position is automatically right. They may be talking about two different definitions of what it means to think. That’s where the old horror stories come in again.

The werewolf: what happens when the next generation changes into something its parents don’t recognise.

• The Midwich Cuckoos: what happens when children develop a cognitive world adults can’t enter.

• Children of the Corn: what happens when the younger generation decides the old structures doesn’t matter.

• They Live: what happens when the systems mediating reality become invisible precisely because everyone accepts them.

• And Idiocracy and Demolition Man ask what happens when convenience and order replace the need to think for yourself.

AI needs to become useful, trusted and ubiquitous in a way that we stop noticing how much of our cognitive environment it occupies.

Subscribe

Cybersecurity investment is usually measured by the controls an organisation adds not the outcomes they change. Prevention, detection and monitoring are essential, but they mostly manage risk. Not necessarily the exposure of data.

A better investment model looks at the entire equation: the probability of compromise, what can be exposed if it happens, how far the consequences can propagate, and the continuing cost of protecting that exposure.

Platforms, controls, monitoring, detection, identity, endpoint protection, threat intelligence, zero trust, cloud security, data security, AI security, post-quantum security. Most of these technologies address real problems. But organisations don’t actually need more security products. They need better security outcomes.

The way cybersecurity is bought, budgeted and measured still revolves around capabilities not consequences. A product detects something faster. A platform provides greater visibility. A new control closes a particular attack path. Another system produces better telemetry or gives the security team another way to manage access.

If a system is compromised, the questions aren’t how many security products were deployed or how sophisticated their dashboards were. What matters is what was exposed, what the attacker was able to do with it, how quickly the organisation could contain it and how far the consequences travelled.

Over the past few days, I’ve looked at this problem from several directions: why sensitive information becomes visible simply because systems need to use it, the continuing cost of protecting that exposure, the privileged-access problem created when trust and visibility become converge, and how interconnected infrastructure allows the fallout of a compromise to propagate beyond the initial organisation.

Security Has Become an Accumulation Problem

A new threat needs another control. A regulatory change introduced another process. An audit identified a weakness and another system was purchased. Infrastructure moved to the cloud, employees became more distributed, suppliers became more connected and identity became more complicated. AI is now introducing another layer to this issue.

Security environments tend to acquire overlapping tools, duplicated capabilities, integrated dependencies, escalating licensing costs and enormous amounts of data that has to be interpreted. All of that while the underlying architecture is largely unchanged.

Sensitive information still becomes visible during processing. Privileged users and systems still have access to it. Applications still receive information beyond what they need. Connected systems still exchange information and credentials across organisational boundaries. Many of them are essential. But it does raise a fundamental question about where security investment produces the greatest return.

Security Isn’t Only the CISO’s Problem

Cybersecurity is generally treated as the CISO’s responsibility, which makes sense operationally. The security organisation runs the programme, manages the controls, responds to incidents and understands the threat environment. The economic consequences are more distributed.

A serious security failure creates legal costs, regulatory exposure, insurance claims, operational disruption, contractual liability, customer remediation, lost productivity and lost revenue. An incident that begins in the security environment can become a finance, legal, operations, communications and board problem.

That means the CISO and CFO aren’t really looking at competing objectives. The CISO sees attack surface and technical consequence. The CFO sees expenditure and financial consequnces. Legal sees liability, privacy sees information exposure, compliance sees regulatory obligations and operations sees resilience. These are different views of the same issue.

If unnecessary access to information is reduced, the organisation can change its security exposure, privacy risk and compliance burden. If compromise can be contained architecturally, incident severity and downstream liability will change with it. If an identity system verifies only the information needed for a transaction rather than distributing complete identity records, the implications extend into data governance, customer experience and regulatory exposure.

Prevention Is Only Part of the Outcome

The previous articles in this series have repeatedly looked at different aspect of the issue to point to the convergence. The consequence of compromise depends not only on whether an attacker gets in, but what becomes available.

An organisation can reduce risk by lowering the probability of compromise. But it can also reduce the amount of useful information exposed by that compromise. It can restrict what a credential authorises, minimise what an application receives, separate administrative privilege from data visibility and design dependencies so that failure in one system doesn’t just propagate.

These approaches change the consequences when prevention fails. One investment might reduce the probability of credential compromise. Another might leave that probability largely unchanged but ensure that a compromised credential reveals substantially less information. A third might prevent the resulting compromise from propagating through customers or connected systems.

The useful comparison isn’t which technology provides the strongest security. It ‘s which investment produces the greatest reduction in meaningful exposure and consequence for the money being spent.

Architecture Changes What Has to Be Protected

Most conventional controls manage risk around an existing system. Architectural change can alter that system. Consider identity. If an application receives a complete identity record just to establish that somebody satisfies a specific condition, the application now possesses information it has to protect. Its infrastructure, administrators, logs, backups and integrations potentially become part of the security boundary surrounding that information.

If the same application can establish the required fact without receiving the underlying identity, the application still needs security, but the consequence of compromising it has changed. The same principle applies to computation.

If sensitive information has to repeatedly become readable because an application needs to perform operations on it, every point at which that information becomes visible creates a point of exposure that has to be controlled. Where some of that computation can instead happen while the underlying information stays protected.

This doesn’t eliminate conventional cybersecurity. Applications still need authentication, infrastructure still needs monitoring, endpoints still need protection and incidents still need response. The difference is that those controls may now be protecting a smaller exposure surface. Better architecture can reduce how much conventional security is being asked to protect.

The Commercial Case Isn’t Just Breach Avoidance

Security investments are frequently justified by the losses they might prevent. That’s understandable, but breach avoidance can be difficult to model because the organisation is trying to assign a financial value to something that may or may not happen. But, architectural change can have another source of value: reducing the continuing cost of carrying exposure.

If an application no longer receives a category of sensitive information, some of the governance surrounding that information may change. If administrators no longer routinely have visibility into customer data, privileged-access risk changes. If identity attributes can be verified without distributing complete records, retention and exposure change. The potential downstream impact changes.

The organisation may therefore be changing not only the probability or cost of a future incident, but the amount of complexity it has to manage every day. Real systems are too complicated for control systems to just disappear, and regulatory obligations don’t go away because an architecture improves.

But the economic case for architectural change should include what the organisation may no longer need to govern, monitor, audit and defend with the same intensity. This brings us back to the carrying cost of exposure.

Technology Still Has to Earn Its Place

There are genuinely powerful technologies becoming practical. Zero-knowledge proofs can establish facts without revealing all of the information behind them. Encrypted (FHE) computation can allow useful operations to occur while underlying information remains protected. Confidential computing can isolate sensitive workloads, while selective disclosure can reduce the information exchanged between parties. Modern identity architectures can make authentication and authorisation considerably more contextual.

Cryptography can introduce computational overhead. New architectures create integration and migration costs. Confidential computing changes trust assumptions it doesn’t eliminate them. Zero-knowledge systems aren’t appropriate for every workflow. AI can improve detection while introducing new forms of access and exposure.

A technology earns its place when it materially changes an outcome to justify its cost. For some organisations, the best investment may still be better endpoint protection or identity management. For others, it may be segmentation, monitoring or incident-response capability. In environments with extremely sensitive information, the greater return may come from changing how that information is exposed during verification, processing or administration.

Security Architecture Is Capital Allocation

An organisation has finite resources with which to reduce risk. Some of that money will reasonably go towards prevention, some towards detection and response, some towards compliance and resilience, and some towards maintaining the controls already in place. Architecture belongs in there as well.

The organisation should compare the continuing cost of protecting an existing exposure with the cost of reducing or removing that exposure architecturally. It should compare another layer of monitoring with a design that makes the monitored information less valuable if compromised. And it should evaluate whether the cost of maintaining a complex collection of controls is justified when a different architecture could change the underlying problem.

A €10 million redesign that removes €500,000 of meaningful risk is difficult to justify. A €10 million investment that materially reduces operating complexity, information exposure, regulatory risk and potential incident severity while enabling new commercial capabilities is a very different proposition.

• Existing infrastructure isn’t free just because it’s already been purchased.

• Existing security controls aren’t free because their licences were approved last year.

• Existing exposure isn’t free because the organisation has become used to protecting it.

Every one of those represents a continuing economic decision.

Start With the Outcome

Sometimes that means preventing compromise. Sometimes it means reducing what becomes exposed when prevention fails, limiting what privileged access can reveal, or containing how far a compromise can propagate.

Start with the exposure: where information becomes visible, who or what can reach it, whether that access is necessary, and what happens if it’s compromised. Then decide whether the answer is another control or a change to the architecture itself.

For the CISO, that ties security investment to consequence rather than the number of controls deployed. For the CFO, it creates a comparison between the cost of change and the continuing cost of the status quo. For the board, it makes cybersecurity what it should be: a capital-allocation decision about enterprise risk.

We won’t eliminate every breach. Credentials will be stolen. Software will contain vulnerabilities. People will make mistakes. Suppliers will be compromised. Failure and catastrophe are different.

Architecture helps determine the difference.

A compromised application doesn’t have to reveal everything it processes. Privilege doesn’t have to mean visibility. Verification doesn’t have to mean disclosure. A supplier compromise doesn’t have to become a customer breach. The purpose of better security architecture isn’t to pretend failure can be eliminated. It’s to engineer the consequences down.

That moves the investment question from how much more security do we need? to how much exposure do we need to create in the first place?

They operate through cloud platforms, identity providers, software suppliers, APIs, managed services, payment processors, contractors, customers and increasingly AI systems. Information moves between them, credentials establish relationships between them, and automated processes connect systems that may be operated by entirely different organisations.

A compromised supplier can interrupt its customers. Stolen credentials can provide access to another environment. Exposed personal information can enable identity attacks and fraud. A compromised API can provide a route into systems that were never part of the original attack. An outage at a sufficiently important provider can affect thousands of organisations.

Built for Connectivity

Modern computing has spent decades removing friction between systems. APIs allow applications to exchange information automatically. Cloud infrastructure provides resources on demand. SaaS platforms eliminate the need to operate everything internally. Identity federation allows users to move between services without maintaining separate credentials everywhere. Managed-service providers give organisations access to specialised expertise. Supply chains operate through interconnected logistics, financial and information systems. AI just accelerated that.

We want systems to exchange information, understand it, combine it and act on it. But that level of connectivity comes at a price.

Verizon’s 2026 Data Breach Investigations Report found that third parties were involved in 48% of breaches, up from 30% the previous year. That means the security boundary has changed.

An organisation can have excellent internal controls and still depend on systems it doesn’t operate, people it doesn’t employ and infrastructure it doesn’t own. The attack surface increasingly includes the relationships between organisations. So does the potential impact.

The First Breach Is Just the Beginning

When sensitive information is stolen, its value doesn’t necessarily disappear after the original incident.

• Credentials can be reused.

• Identity information can support impersonation.

• Customer information can make phishing considerably more convincing.

• Commercial information can expose relationships, suppliers or internal processes.

• Information from several breaches can be combined to create something considerably more useful than any individual dataset.

The initial compromise can become an input into subsequent attacks. Especially when the information exposed isn’t simply descriptive data but something that provides access or establishes trust. In other words, the damage isn’t necessarily limited to what was stolen. That’s the ripple effect.

Trust Relationships Can Become Attack Paths

Every interconnected environment contains trust relationships. These relationships are necessary in the interconnected infrastructure. The security problem isn’t just the number of organisations connected to an environment. It’s what those connections carry.

Concentration Changes the Scale

Connectivity doesn’t just create more relationships. It concentrates them. Thousands of organisations may depend on the same cloud platform. Large numbers of businesses may use the same identity provider, software library, managed-service provider or SaaS application. Entire industries may rely on a relatively small number of payment, communications or infrastructure providers. True it’s efficient, but it’s also a series of points of failure that scale quickly. Concentrated infrastructure can creates systemic risk.

One provider isn’t just one potential incident. It may be connected to hundreds or thousands of organisations, directly and indirectly.

Which means that architecture has to account for consequence concentration, not just compromise probability.

AI Makes Propagation Faster

AI introduces another problem, it changes what connected systems can do with information. Traditional integrations often move relatively predictable pieces of data between predetermined systems. An AI agent can read email, retrieve documents, query databases, interact with APIs, access customer information and take actions in other systems. Its usefulness comes partly from its ability to cross boundaries that previously required human intervention. This creates a new form of systemic risk.

An AI system may have access to information that previously existed in several separate contexts. Each permission granted individually can look reasonable. Collectively, they can create a real problem for the organisation.

The question isn’t if the AI is trustworthy. It’s whether AI needs that much access to the system. If an AI agent needs to determine whether an invoice meets certain conditions, it doesn’t need every piece of information associated with the customer.

If it needs to verify eligibility, it may need the result of a verification not the identity information behind it. Likewise if it is scheduling meetings. It just needs very specific access, nothing more. Giving an AI access to everything because it might need something is just the old privileged-access problem, but at machine speed.

Containment Has to Become Architectural

Current containment is largely reactive. An organisation detects something has gone wrong, then isolates an endpoint, disables an account, blocks a network segment, revokes a token or disconnects a service. The problem wit this scenario: the organisation has to recognise the compromise before it can contain it.

Sensitive information can be exposed only where it’s genuinely required. Applications can receive the attributes necessary to perform a function. Privileged users can administer systems without gaining visibility into everything. Credentials can be constrained to specific functions, and systems can be designed so that compromising one component doesn’t automatically expose everything connected to it.

The same principle applies to computation. Sensitive information can be protected while it’s being processed rather than repeatedly becoming visible because a system ‘needs it’.

Reactive containment tries to stop a compromise after it’s detected. Architectural containment limits what that compromise can become before it happens.

The Economics Change Again

Customers can experience outages. Partners can need to investigate their own environments. Credentials can need to be rotated. Services can need to be suspended. Contracts can be affected. Regulators can ask questions in multiple jurisdictions. Customers can face their own notification obligations. Eventually, someone pays for all of this.

And an investment that reduces how far the consequences can propagate may have value beyond the organisation making the investment.

Your Security Architecture Is Part of Someone Else’s Risk Model

Questionnaires are completed. Certifications are requested. Contracts contain security clauses. Audits are conducted. Insurance requirements appear. Vendors are categorised according to risk.

All of this exists because customers understand something important: their suppliers’ architecture can become their problem.

Your architecture forms part of somebody else’s risk environment. Your customers are depending on how you handle their information. Your partners are depending on the credentials and integrations connecting your systems. Your suppliers may be depending on information you provide to them. Your insurers are evaluating the consequences of your controls failing. Your regulators are increasingly interested in resilience beyond the individual organisation.

Security architecture isn’t purely an internal technical decision. It’s part of the commercial relationship between organisations. And that creates an interesting competitive dimension.

If two suppliers provide broadly equivalent services, but one can materially reduce the information exposed during processing and show that compromise of its infrastructure has a smaller potential impact, that difference may matter as much, or more, as another feature on a product comparison sheet. Especially when the customer is a bank, hospital, government, critical-infrastructure operator or any organisation carrying information whose compromise creates consequences far beyond IT.

Build for Compromise Without Accepting It

Prevention, detection, identity controls, monitoring and incident response remain essential parts of any credible security strategy. But resilience needs acknowledging that no collection of controls is infallible. Credentials are stolen. Suppliers are compromised. Applications contain vulnerabilities. Employees make mistakes. Configurations are wrong. AI systems are inevitably given access to information or functions somebody didn’t fully anticipate.

A stolen credential doesn’t have to unlock an entire identity. A compromised system doesn’t have to expose the information it’s processing. A supplier failure doesn’t have to place every connected customer at risk. And an AI agent doesn’t need unrestricted visibility simply because it performs a useful function.

That leads to a relatively simple architectural principle:

• Reduce what can be exposed.

• Reduce what can be carried.

• Reduce what can propagate.

  Thanks for reading PrivID's Substack! Subscribe for free to receive new posts.

But underneath those controls? Somebody still has to be trusted with the data.

Administrators need elevated privileges. Developers need production access. Support teams need visibility into customer environments. Database administrators need access to databases. Security teams need logs. Contractors need temporary permissions. Applications and service accounts need credentials to perform their functions.

The organisation spends a great deal of time and money deciding who should receive access, monitoring what they do with it, and proving afterwards that they didn’t abuse it.

Privilege Became an Architectural Shortcut

Privileged access exists for a reason. Someone has to maintain infrastructure. Someone has to recover systems when they fail. Someone has to deploy software, investigate incidents, configure databases and keep services running. Historically, the easiest way to enable those functions was to give trusted people more/privileged access.

That worked relatively well when computing environments were smaller, centralised and operated by contained teams. It’s harder when organisations operate across multiple clouds, SaaS platforms, contractors, managed-service providers, remote employees, APIs and globally distributed infrastructure.

Privileged access management limits administrative credentials. Identity governance reviews permissions. Multi-factor authentication strengthens access. Session monitoring records activity. Separation of duties prevents one individual from controlling an entire process. Just-in-time access reduces how long privileges are active.

We’re deciding who can be trusted to see information that the architecture makes visible.

Zero Trust Didn’t Eliminate Trust

Don’t assume someone should be trusted. Verify identity. Evaluate context. Limit privilege. Continuously reassess access. But zero trust still ends up at the same place. Basically, who gets through is heavily monitored. But, once inside, they can access everything. That’s why legitimate access is one of the hardest security problems.

Monitoring can help identify suspicious behaviour, but it happens after the fact. Which means the organisation is still dependent on another assumption: the trusted entity will behave as expected.

The Insider Doesn’t Have to Be an Insider

The phrase insider threat suggests a disgruntled employee downloading customer records before leaving the company. Maybe. But privileged exposure is much more than malicious employees.

• An administrator’s credentials can be stolen.

• A developer’s laptop can be compromised.

• A support account can be phished.

• A third-party technician can have excessive permissions.

• A service account can be exploited.

• A software supplier can be compromised.

• An AI agent can be granted access to information its operators never anticipated it combining.

The problem is that the privilege itself can carry too much information with it.

What happens when a legitimate privilege is misused, stolen, compromised or simply makes a mistake. Architecture can help reduce the consequences.

What If Administration Didn’t Mean Visibility?

A database administrator’s job may need them to maintain availability, manage performance, configure replication, perform backups, allocate resources and recover systems. But which of those needs the administrator to read every customer record in the database? Administrative control and data visibility tend to go together.

The same problem exists when talking about a cloud operator who may need to manage infrastructure without needing access to customer information, or about any of the following:

• A support technician may need to confirm that an account exists without seeing every attribute associated with it.

• An application may need to establish that someone is over 18 without knowing their date of birth.

• A financial system may need to determine whether a condition has been satisfied without exposing every input used to reach that determination.

• A security process may need to verify that an event occurred without copying the entire underlying dataset somewhere else for analysis.

These are questions about information architecture. Not permissions.

Privileged Access Has a Carrying Cost

There’s a commercial dimension that tends to disappear inside security budgets. Every privileged relationship creates a governance issue.

Accounts have to be provisioned and deprovisioned. Permissions have to be reviewed. Administrative sessions may need to be monitored. Logs have to be retained. Separation-of-duty policies have to be enforced. Contractors need oversight. Access has to be demonstrated to auditors. Exceptions have to be documented.

Someone has to investigate when those controls report something unusual. The more sensitive the information, the more expensive that governance becomes. Privileged visibility is its own version of the carrying cost of exposure. The organisation isn’t protecting data. It’s managing the people, identities, credentials and processes capable of reaching it.

Reducing unnecessary visibility isn’t just a security issue. If an administrator can perform a function without reading the underlying data, the organisation hasn’t eliminated the need to secure that administrator.

This Isn’t About Eliminating Administrators

Organisations need privileged users. Systems fail. Engineers debug them. Security teams investigate incidents. Databases require maintenance. Infrastructure needs administration. Emergency access doesn’t disappear. The objective isn’t to create some imaginary environment in which nobody has privileges.

Modern cryptographic makes that distinction more practical. Disclosure can reveal only the attributes required for a transaction. ZKPs can establish that a condition is true without revealing all of the information behind it. And encrypted computation can allow certain operations to happen without revealing the protected information.

AI Makes the Privilege Question Bigger

Organisations are beginning to give software agents access to email, documents, customer records, financial systems, development environments and operational tooling so that they can perform tasks on behalf of employees. But, an AI system doesn’t need malicious intent to create an exposure problem. It can receive excessive context, combine information that previously existed in separate systems, retain information unnecessarily, disclose it in response to the wrong request or take an action its operator didn’t anticipate.

Trust the Function, Not the Visibility

Organisations will keep trusting people, systems, suppliers and infrastructure to perform necessary functions. Trust an administrator to maintain a database without giving them access to every record. Trust an application to verify eligibility without someone’s complete identity. Trust an AI system to perform a task without giving it unrestricted access.

Cybersecurity has become better at who can be trusted with access, then monitoring and documenting that trust. The next architectural shift is to enable the trusted function while minimising access to the underlying information.

That won’t eliminate insider threats, compromised credentials, malicious employees, vulnerable suppliers or careless administrators. It just changes what will be exposed during a breach.

It’s a reasonable question. New technology has acquisition costs. Integration takes time. Existing systems may need to be modified. Employees need training. Infrastructure may need upgrading. There may be additional compute requirements, implementation risk, and a period during which old and new systems have to operate alongside one another.

Those costs are relatively easy to see because someone eventually puts them into a budget. Doing nothing looks a lot cheaper. But, the status quo isn’t free. It has the advantage of already being in the budget.

Most organisations aren’t starting with a blank spreadsheet. They’re operating technology environments assembled over years or decades through acquisitions, migrations, cloud adoption, regulatory changes, new applications and old applications that somehow refuse to die.

Each addition creates dependencies, and each dependency creates something else that has to be managed, monitored, patched, audited or protected.

A system exposes sensitive information during processing, so access to that system has to be controlled. That means identity controls. Privileged users need additional controls. Endpoints need protection. Networks need segmentation. Data movement needs monitoring. Logs need collection and analysis. Alerts need investigation. Compliance needs evidence. Suppliers need assessment. People need training. Incidents need response capabilities. All of these costs put together are the carrying cost of exposure.

Cybersecurity also has a tendency to accumulate. A new threat appears - another capability is purchased. A regulatory requirement changes - another process is introduced. An incident occurs - more monitoring is added. A supplier creates another dependency - another risk-management process shows up. An audit identifies a gap - another control closes it. Nothing disappears. But, more is always added.

The result is greater operational complexity, and complexity has its own cost. More systems have to integrate. More alerts have to be interpreted. More policies have to remain consistent. More privileged relationships have to be governed. More dependencies have to be understood. It’s always more. Never less. Eventually, organisations can find themselves protecting the systems that protect the systems that protect the data.

Since much of that expenditure already exists, it’s easy to stop seeing it as a cost of the architecture at all.

The Wrong Comparison

This matters when a CISO takes a proposed architectural change to the CFO. That change may cost €5 million to implement. Presented in isolation, €5 million is a very visible number.

The existing environment appears to cost nothing because nobody is asking for €5 million to keep it. But that isn’t a valid comparison.

The existing environment already has licensing costs, infrastructure costs, security tooling, monitoring, personnel, audits, insurance, compliance, incident-response capability and accumulated technical debt. Those expenses may be scattered across half a dozen budgets, but they don’t disappear simply because nobody has grouped them together. Then there’s another cost that usually isn’t sitting neatly in next year’s budget. What happens when something fails?

IBM’s 2026 Cost of a Data Breach research puts the global average cost of a data breach at US$4.99 million, up 12% from the previous year and the highest figure reported in the study to date. That’s roughly €4.3 million at recent exchange rates, although the conversion obviously moves with the currency. The more important point is the scale of the loss. Even that figure can make a breach sound tidier than it really is. A serious incident doesn’t produce one invoice marked data breach.

There’s investigation, containment, remediation and recovery. External specialists may be brought in. Systems may have to be isolated or rebuilt. Operations can be disrupted. Legal teams become involved. Regulators may become involved. Customers may require notification or remediation. Contracts may be affected. Insurance conditions can change. Then there’s management time.

Executives, security teams, developers, operations staff, communications teams and legal counsel can spend weeks dealing with an incident instead of doing whatever the organisation normally pays them to do.

For larger incidents, the numbers can sky rocket. Allianz’s analysis found that ransomware accounted for 60% of the value of large cyber claims above €1 million during the first half of 2025. Data theft appeared in 40% of the value of those large claims, up from 25% during 2024. But, that doesn’t tell the entire story. Because your breach isn’t only your problem.

When the Cost Travels

Organisations don’t operate in isolation. They depend on cloud platforms, software suppliers, managed services, identity providers, APIs, payment systems, logistics providers and increasingly AI services. Those relationships create enormous efficiency. They also create dependencies.

Verizon’s 2026 Data Breach Investigations Report found that third parties were involved in 48% of breaches, up from 30% the previous year. Nearly half of the breaches it analysed therefore involved relationships or infrastructure extending beyond the organisation itself. The financial consequence doesn’t necessarily stop with the organisation that was compromised.

A supplier outage can interrupt its customers. Compromised credentials can provide access to other environments. Stolen information can enable subsequent fraud, identity attacks or highly targeted social engineering. Customers may have to investigate their own systems, rotate credentials, notify their own clients or temporarily suspend services. One organisation’s security incident can become somebody else’s operational and financial problem.

That creates a multiplier that a simple average breach-cost figure doesn’t properly reflect. It’s not just how much the original organisation loses. It’s how far the ripple effect of that breach propagates through the relationships surrounding it. As infrastructure becomes more interconnected, that issue becomes more important.

This is where containment becomes an economic consideration as much as a security one. This is where we need to understand that architecture needs to limit what a successful compromise can expose. Limiting the initial exposure can limit what there is to propagate.

Getting In and Getting Something Are Different Problems

Consider two organisations experiencing broadly similar compromises.

In the first, the attacker reaches systems containing large amounts of readable customer information, credentials or commercially sensitive data. Some of that information may also provide the means to attack customers, employees, suppliers or other connected organisations.

In the second, the attacker reaches infrastructure where significantly less useful information is exposed because sensitive data remains protected through more of its lifecycle.

Both organisations have experienced a security failure. Their financial outcomes may vary. So do the consequences for everyone connected.

One architecture concentrates primarily on preventing the attacker from getting through the door. The other also asks what should be sitting behind the door if they succeed, and how far anything they obtain can travel. The real difference, in those perspectives, is the economic impact they have on the organisation and those connected to it.

Security investment has traditionally concentrated heavily on reducing the probability of compromise. Stronger authentication can reduce credential abuse. Better monitoring can detect an attacker earlier. Segmentation can restrict lateral movement. Endpoint controls can stop malicious code. Vulnerability management can close known routes into an environment.

But probability isn’t the only variable determining the economic outcome. There’s also the value available to the attacker and the consequences that follow if they get it. That gives us another way to think about cyber risk. Not as a precise mathematical formula - cybersecurity contains far too many variables for that - but as an economic model.

The consequence of an incident is influenced by the probability of compromise, the value exposed when it happens, and how far the resulting damage can propagate. Traditional security concentrates heavily on the first part. Architecture can influence all three.

• If an organisation can verify information without unnecessarily revealing it, the amount exposed changes.

• If computation can occur while sensitive information stays encrypted, the amount exposed changes.

• If an application receives only the attributes needed for a transaction rather than the complete underlying record, the amount exposed changes.

• If administrators can operate infrastructure without routinely being able to read the information contained within it, the amount exposed changes.

• If less useful information is available following compromise, there may also be less material available to enable the next attack.

The attacker doesn’t have to disappear for the economics of the attack to change.

The CISO and CFO Are Looking at the Same Problem

The CISO and CFO are sometimes seen as approaching cybersecurity from opposing directions. The CISO wants to reduce risk. The CFO wants to control expenditure.

Both are essentially asking the same question: What’s the most economically efficient way to reduce the organisation’s exposure?

That doesn’t automatically mean spending more. Nor does it mean replacing existing infrastructure simply because something newer exists. A new architecture that costs €10 million but eliminates €500,000 of meaningful risk isn’t particularly compelling.

A €10 million investment that materially reduces continuing operating costs, simplifies controls, limits the severity of potential incidents, reduces regulatory or downstream exposure and enables new commercial capabilities is an entirely different proposition.

That requires a proper comparison. It means comparing the total cost of maintaining the existing architecture with the cost and consequences of changing it. There’s also a temptation to make the opposite mistake and pretend architectural change solves everything.

Encrypted computation can impose performance costs. Cryptographic systems introduce engineering complexity. Existing applications may not easily support new approaches. Migration creates operational risk. Some information genuinely does need to be available in plaintext at particular points in a workflow.

The commercial case exists when reductions in exposure, operating complexity, incident consequence, downstream risk or future technical debt justify the cost of making the change. And that calculation won’t be always be the same.

Protecting a public product catalogue isn’t the same problem as protecting medical records. Processing an employee’s cafeteria preference isn’t the same as processing their biometric identity. A system containing publicly available information doesn’t carry the same economic consequence as one containing customer credentials, intellectual property or regulated personal information.

Architecture should reflect the value and consequence of the information involved. Which is why quoting the average cost of a breach, whether it’s €4 million or €40 million, can only take the discussion so far.

The Status Quo Should Have to Justify Itself Too

New technology is routinely required to prove itself. Existing architecture rarely faces the same test. Its licences renew. Its infrastructure remains. Its processes continue. Its technical debt accumulates. Its security controls multiply around it. And because those costs already exist, they become invisible.

If an organisation is spending increasing amounts protecting sensitive information because that information must repeatedly become visible throughout its systems, then maintaining that architecture is itself an investment decision. It should be evaluated like one.

The choice isn’t between spending money and spending nothing. It’s between the cost of changing the architecture, the continuing cost of protecting the existing one, and the potential cost when that protection fails. The cost of doing nothing is never zero.

Identity and access management determines who gets in. Privileged access management controls administrators. Network segmentation limits movement. Endpoint protection watches devices. Data loss prevention watches information leaving. SIEM platforms collect events, security operations centres monitor them, behavioural systems look for anomalies, and compliance systems document who had access, when they had it, and whether that access was appropriate.

Given the architecture we’ve built for the last 40 years, it is necessary. But there’s an assumption buried under that: the information itself must eventually become visible somewhere. Why?

Every Exposure Means Something Else to Protect

When sensitive information becomes available in plaintext, the application processing it becomes part of the security boundary. So does the operating system underneath it, the memory it occupies, the administrator with sufficient privileges, the identity system controlling access, the endpoint being used, the logging infrastructure, and the APIs connecting that system to everything around it. AI systems are now part of that boundary as well.

Every additional place where information becomes visible expands the environment to be defended. And every expansion carries a cost. Which brings up an economic question: how much of the cybersecurity budget exists because the underlying architecture creates exposure that has to be controlled?

• The CISO sees attack surface.

• The CFO sees expenditure.

• The privacy officer sees personal information.

• Legal sees liability.

• Compliance sees regulatory obligations.

• Operations sees systems that must remain available.

• The board sees all of that. Eventually.

They may look like different problems, but in reality they’re dealing with different consequences of the same architecture: sensitive information exists somewhere in a usable form, therefore that environment must be protected.

The traditional response has been to attempt better authentication. Better monitoring. Better detection. Better segmentation. Better access policies. Better incident response.

There’s a structural limitation to the approach. They can reduce the probability of compromise. Not the value of the compromise.

When the Controls Fail

Security risk is discussed in terms of probablilties:

• How likely is an attacker to penetrate the organisation?

• How likely is an employee to misuse access?

• How likely is a credential to be compromised?

• How likely is ransomware to succeed?

Imagine two systems. Both are compromised.

In the one, the attacker obtains credentials that provide access to a large collection of readable customer information. In the other, the attacker compromises infrastructure, but the sensitive information stays cryptographically protected throughout.

Both organisations experienced a security failure. Their economic outcomes? Vastly different.

Pretending that any sufficiently complex organisation can guarantee 100% safety for data is becoming increasingly harder to defend.

For decades, cybersecurity has overwhelmingly concentrated on reducing the probability that an attacker reaches valuable information. We build stronger walls, detect attackers earlier, authenticate users more carefully, restrict privileges and monitor behaviour.

But there’s another variable available: reduce the amount of useful information exposed behind those controls.

An organisation can minimise the information it collects. It can process information locally rather than continually centralising it. It can disclose only the attributes needed for a transaction. It can prove that something is true without revealing all of the information behind that proof. Increasingly, it can also perform certain computations while the underlying information stays encrypted.

Data Minimisation Is Not Just Deletion

We usually think about data minimisation in terms of quantity and time. Collect less. Store less. Retain it for less time. Delete it when it’s no longer needed. Notice what‘s missing from that: minimise exposure.

A hospital legitimately needs medical records. A bank needs financial information. Governments need citizen information. Manufacturers may need commercially sensitive intellectual property. AI systems need information from which to perform useful analysis. That doesn’t mean every component involved in using it needs to be capable of seeing it.

When a new security approach is proposed, finance understandably asks what it will cost:

• Implementation costs money.

• Integration costs money.

• Compute costs money.

• Migration costs money.

• Training costs money.

• Operational change introduces its own risk.

They should be looked at. The problem is that isn’t the entire cost picture. The alternative isn’t do something versus spend nothing. The real comparison is the cost of change versus the continuing cost of keeping the existing model.

That existing model already carries substantial costs: security tooling, monitoring, privileged-access controls, compliance, audit, cyber insurance, incident-response capability, specialised personnel, remediation and the technical debt accumulated by continually adding controls to increasingly complicated environments.

Then there’s the cost that’s harder to predict: what happens when they fail?

What Does the System Actually Need to Know?

We’ve spent decades improving our answers to who should be allowed to see this? There’s a question no one thought to ask: Does anyone need to see it?

Sometimes the answer will still be yes. Cryptography isn’t magic. Neither is zero trust, AI, confidential computing, or whatever else currently happens to be carrying a conference badge and an enthusiastic marketing budget. But more often than not the answer is no.

A system can verify an attribute without knowing the underlying identity. A service can calculate a result without retaining the information used to calculate it. An administrator can operate infrastructure without being able to read the information contained. An AI system can answer a question without permanently absorbing everything it was given. And, critically, a compromised system doesn’t necessarily have to represent the catastrophic information exposure we’ve come to assume it does.

Because if information doesn’t always need to be visible to be useful, we’re no longer talking only about building better cybersecurity controls around the same underlying architecture. We’re talking about changing the architecture itself.

And once you do that, the question facing the CISO and CFO changes: how much exposure the organisation should keep paying to protect in the first place?

Trusted vendors. Trusted identities. Trusted devices. Trusted environments. Trusted execution. Trusted AI. Trusted supply chains.

At the same time, the industry increasingly talks about zero trust, continuous verification, secure-by-design systems, identity-based access, and explicit trust boundaries.

Security organisations are saying to trust less while continuing to build systems that depend heavily on trust. The industry has identified the problem, but, it hasn’t followed the argument to its logical conclusion.

Trust Is an Expectation

When an organisation says that it trusts a vendor, it usually means the vendor has passed a due-diligence process. Contracts have been reviewed, certifications checked, and security questionnaires completed. Policies, insurance, governance, jurisdiction, and reputation may all have been considered.

All of that said, the vendor may still be able to view the data. Its administrators may still have privileged access. Its infrastructure may still create logs, backups, temporary files, analytics records, or diagnostic copies. Its employees can make mistakes, its software supply chain can be compromised, and its legal obligations can change.

Trust describes the expectation around those capabilities, it doesn’t mean they can’t be misussed.

Zero Trust Stops at the Door

Traditional network security treated users and devices inside the perimeter as more trustworthy than those outside it. Zero trust challenged that assumption by requiring access decisions to be evaluated continuously rather than granted permanently because something had entered the network. That is better. But zero trust is implemented as a more sophisticated permission system:

The access decision becomes more precise, once access is granted, the data is decrypted and revealed. The system has verified who is asking. It hasn’t eliminated what is exposed.

Verification Doesn’t Eliminate Visibility

A verified identity can still be compromised. An authorised employee can still make a mistake. A legitimate application can still collect too much information. An approved AI agent can still take an unintended action. A properly authenticated administrator can still see information that isn’t needed. A compliant cloud platform can still process sensitive data in plaintext.

An organisation can improve authentication, identity governance, behavioural monitoring, endpoint security, and least-privilege access and still expose the full underlying dataset. That is better-controlled exposure, not eliminated exposure.

Trust Expands Through the System

Modern systems depend on chains of trusted entities. An employee accesses an application running on a cloud platform. The application calls several APIs, records telemetry through another service, writes logs to a monitoring platform, creates backups in a separate region, and may pass information into an analytics or AI system.

Each service has its own infrastructure providers and subprocessors. Each has administrators, credentials, software dependencies, legal obligations, and failure modes. A single business action can cross multiple trust boundaries before the user sees a result.

This is why secure-by-design discussions increasingly emphasise the need to make trust explicit. Trust boundaries matter because they show where data, identities, and execution contexts pass from one control domain to another.

But identifying a boundary doesn’t protect the information crossing it. It only tells us where trust is being transferred, not whether it’s actually necessary.

Contracts Govern Behaviour

Contracts define obligations, liability, permitted use, retention, deletion, breach notification, audit rights, jurisdiction, and remedies.

But a contract can’t stop a system from seeing data that the architecture gives it.

• It can prohibit copying; it can’t make copying impossible.

• It can restrict secondary use; it can’t prevent secondary use if the provider retains technical access.

• It can require deletion; it can’t prove that no other copy ever existed.

• It can impose consequences after a breach; it can’t reverse disclosure.

Contracts govern relationships. Architecture governs capability. Security weakens when one is mistaken for the other.

Privileged Access Is Still Access

Administrators need sufficient authority to maintain infrastructure, restore services, configure systems, and respond to incidents. That becomes a broader assumption: that administrators need to view the information those systems contain.

• The person who controls the server can see the database.

• The person who manages the cloud account can access the storage.

• The person who maintains the application can inspect its logs.

• The person debugging the AI workflow can examine the prompts and outputs.

Administration and data visibility are different functions. Treating them as inseparable creates a standing exposure that organisations try to manage through screening, policy, monitoring, and trust.

AI Makes the Trust Problem Larger

An AI agent may be authenticated correctly, assigned an approved role, and permitted to access several systems. It may still combine information in unexpected ways, act at machine speed, use tools, invoke external services, retain context, or pass information between workflows that had previously been separate.

This is why security discussions are beginning to treat non-human identities and AI agents as security principals not just extensions of human users. But giving an AI agent an identity doesn’t solve the problem.

The agent can still receive more information than it needs. A perfectly authenticated agent with excessive visibility remains an excessive risk. The issue isn’t only whether the system trusts the agent, it’s whether the architecture requires the agent to be trusted at all.

Trust Minimisation Is Not Distrust

No organisation can operate without trust. People must work together. Companies must use suppliers. Partners must exchange information. Administrators must maintain systems. Regulators must supervise markets. Customers must rely on organisations to honour their commitments.

The objective isn’t to eliminate trust, it’s to stop making security dependent on it.

A trust-minimised architecture assumes that vendors can fail, credentials can be compromised, insiders can make mistakes, jurisdictions can change, software can contain defects, and automated systems can behave unexpectedly. Which limits what any one failure can expose:

• Access should reveal only what is necessary for the immediate task.

• Identity should establish entitlement without requiring unnecessary disclosure.

• Sensitive information shouldn’t automatically become plaintext merely because a computation needs to occur.

• Infrastructure providers should be able to provide infrastructure without inheriting unrestricted visibility into its contents.

• Administrators should be able to maintain systems without automatically gaining access to the protected data inside them.

• Compromise should remain local rather than becoming a route to everything.

Security Should Survive Failed Trust

Trust can be justified, and it can be misplaced. Organisations won’t know which until it’s too late.

A vendor can be competent for years before a breach. An administrator can be reliable until an account is compromised. A jurisdiction can be considered adequate until its laws or political conditions change. An application can operate safely until an update introduces a vulnerability. An AI system can behave predictably until it encounters a combination of instructions its designers didn’t anticipate.

A resilient architecture doesn’t need to be perfect. It just has assume that something will eventually fail. The real test is what happens when it does:

• Can the failed component see the underlying information?

• Can it copy that information?

• Can it move laterally?

• Can it impersonate another entity?

• Can it turn one authorisation into general access?

• Can the organisation contain the failure without replacing the entire environment?

Trust Is a Decision

An organisation can decide that a vendor is trustworthy, an employee is reliable, or that a platform, jurisdiction, AI model, or supply-chain partner presents an acceptable risk. Those decisions will always involve judgement. Security architecture should determine what is protected when that judgement is wrong.

That is where much of the current discussion about trust stops too early. The industry is right to reject implicit trust, to verify identities continuously, and to define trust boundaries, minimise privileges, and treat non-human entities as genuine security principals.

A verified entity should still receive only the information needed to complete the task. An authorised system should still be unable to expose everything. A trusted vendor should still be technically prevented from seeing what it doesn’t need to see.

The assumption’s that the problem’s now been addressed.

Once data’s been exposed, copied, logged, transferred, harvested, retained, or made available during processing, a later compliance decision can’t make that exposure disappear.

It can only change what happens next.

Compliance Is Retrospective by Design

Regulation usually responds after the fact. Its weaknesses become apparent. Incidents accumulate. Regulators investigate. Legislation’s drafted, negotiated, challenged, amended, and eventually implemented.

By the time a formal fix arrives, the underlying architectural dependency may have existed for years.

It’s just the nature of regulation. That gap allows an organisation to feel safe while waiting for the rules to catch up. But, the exposure exists whether or not the regulation’s caught up or not.

A New Rule Doesn’t Fix An Old Problem

An organisation can terminate a vendor agreement, change providers, move its workloads, or restrict future access. It may even be able to prove that it’s now compliant.

None of those things fix what happened to information that was previously accessible?

Deletion Does Not Fix It

Organisations can rely on deletion. Deletion may remove a known copy from a known system under known control. But that doesn’t mean the information was never duplicated, retained elsewhere, extracted, reconstructed, or incorporated into another process. Especially in distributed environments involving cloud platforms, SaaS providers, analytics systems, AI models, development logs, support tools, and supply chains. The more systems that allowed to see the information, the less credible a claim of complete deletion becomes.

Compliance Governs Permission

Compliance controls focus on who’s allowed to access information. Policies define use. Contracts define obligations. Identity systems define authorised users. Audit logs log activity.

These controls regulate who can access the data. Their effectiveness depends on people, organisations, software, infrastructure, legal systems, and enforcement mechanisms behaving as expected.

The system just declares that visibility to be controlled. That model becomes increasingly fragile as systems grow more interconnected and autonomous. An AI system doesn’t need malicious intent to expose information. A developer doesn’t need to act dishonestly to create an excessive log. A supplier doesn’t need to breach a contract deliberately for data to pass into another service. A government doesn’t need to violate local law if a foreign legal order already grants access.

Compliance defines what should happen. Architecture determines what can happen.

The Compliance Window Is An Exposure Window

When organisations postpone architectural change until regulation forces it, it becomes very much a “they problem”. During that period, data is still processed under the existing model. Systems continue to decrypt information. Vendors continue to receive it. Cloud services continue to log it. Models continue to ingest it. Backups accumulate.

The organisation can implement every change and still not account fully for what happened during the delay.

Take quantum risk. Harvested encrypted data doesn’t need to be readable today to create future exposure. Likewise, data revealed during computation doesn’t need to be stolen through a dramatic breach, it only needs to become available somewhere outside the organisation’s effective control.

Compliance Can’t Fix Past Architecture

An organisation can plan to adopt post-quantum cryptography, intend to move away from a particular cloud environment, expect stronger AI regulation, believe contractual protections will improve, or wait for regulators.

None of that changes what the current architecture exposes today. The question now becomes what information will stay exposed while it waits.

Retrospective security can impose penalties, change behaviour, and establish accountability, but it can’t make exposed information private again.

Architecture Has to Move First

Designing systems where sensitive information doesn’t automatically become visible just because it’s being used. That means reducing plaintext processing, separating proof from disclosure, and limit what vendors, infrastructure providers, administrators, applications, and automated systems are able to see.

Regulation will keep evolving. Vendors will change. Jurisdictions will shift. Standards will be replaced. Threat models will expand. An organisation can’t predict everything, but it can reduce how much information is exposed now.

• Can we trust this cloud provider?

• Can we trust this software vendor?

• Can we trust this identity platform?

• Can we trust this certificate authority?

Every procurement process, security audit and compliance framework has revolved around that question. The better the reputation, the easier the decision.

It made sense. Technology was becoming increasingly complex, and no organisation could build or operate every component itself. Trust allowed digital ecosystems to scale. But trust came at a cost. That cost was architectural.

Every vendor introduces a trust dependency that another organisation will act in your best interests:

• They’ll remain financially stable.

• They’ll maintain security.

• They’ll respond quickly to vulnerabilities.

• They’ll operate within predictable legal frameworks.

• Their priorities will keep aligning with yours.

The cybersecurity industry has treated trust as a security control not an operational assumption. It doesn’t eliminate risk; it transfers it to someone else.

Organisations depend on dozens, sometimes hundreds, of external providers. Cloud platforms, software vendors, identity services, AI providers, certificate authorities, managed security providers, hardware manufacturers and who knows how many third-party libraries (seriously, I really don’t think anyone is fully aware of how many - I have no idea - I know it’s a lot) all contribute to modern infrastructure.

The challenge isn’t that any particular vendor is untrustworthy. The challenge is that trust doesn’t scale indefinitely. The more dependencies we accumulate, the more assumptions need to be made.

What can we verify?

Verification doesn’t need reputation. It doesn’t need optimism. It doesn’t need hoping that another organisation continues behaving exactly as expected. It needs evidence.

This is where mathematics begins enters the picture. For centuries, mathematics has offered certainty where human judgement could not. We don’t trust that two plus two equals four. We verify it. And if you have a great accountant, you don’t ask questions why it can equal five.

IThat principle is finding its way into cybersecurity:

• Rather than assuming an identity is genuine, we can verify specific claims.

• Rather than assuming data has remained unchanged, we can prove its integrity.

• Rather than assuming a user is authorised, we can show authorisation without exposing unnecessary information.

This isn’t about eliminating vendors., replacing cloud providers, or suggesting that organisations should distrust every technology company they work with. Modern computing depends on collaboration, and it always will.

Instead of building systems that rely on institutional trust, we build systems that rely on mathematical verification. That doesn’t remove trust, it does reduce how much trust you need and rely on.

• Is it secure?

• Is it compliant?

• Does it integrate with our existing systems?

• How much does it cost?

The problem is that those questions were for a cybersecurity system from 30 years ago. Today’s organisations need different questions, and different baselines.

• Who controls the updates?

• Who controls the encryption?

• Who controls the identity system?

• Who controls the firmware?

• Who controls the AI?

Notice that these questions are about control, not the technology per se.

For decades, it’s been assumed that if a product met the security standards, everything else would take care of itself. The software could be hosted anywhere, updated by anyone, and managed from almost any jurisdiction. Security was a property of the product not the ecosystem surrounding it.

Recent events have exposed a reality that was always there but rarely, if ever, discussed: software doesn’t exist in isolation. Every application depends on update mechanisms, cloud infrastructure, certificate authorities, identity providers, hardware supply chains, and the legal jurisdictions governing them.

Every one of those assumptions is a decision that someone else can make on your behalf. Outsourcing your decisions, especially around security, is never a good idea.

The point is that procurement isn’t about asking whether a vendor can be trusted. It’s about how much an organisation should depend on that trust.

Security has traditionally focused on preventing unauthorised access. Sovereignty focuses on maintaining authorised control. An organisation can have excellent cybersecurity and be dependent on external decisions for updates, identity services, or cloud infrastructure. The technical controls may be excellent, but the operational control sits elsewhere. That’s a board-level issue not an IT issue.

This means that procurement is evolving from evaluating products to evaluating dependencies.

• Who owns the intellectual property?

• Who controls the update pipeline?

• Can encryption keys remain under the organisation’s exclusive control?

• Can the platform continue operating if a supplier changes its commercial strategy, becomes subject to sanctions, or simply decides to discontinue a service?

Five years ago those questions would most likely not have been asked. Today, they’re becoming central to the issues being faced.

This a fundamental change in how organisations see technology, not just a geopolitical issue. Security is essential. Compliance is essential. Performance absolutely matters. But procurement is recognising that technology decisions are governance decisions. Software is only part of the purchase. The dependencies come with it.

I suspect we’ll start to see procurement departments place as much emphasis on operational independence as they do on traditional security certifications. Because security doesn’t really answer: Who is in control when circumstances change?

1. FHE, allows computation over encrypted data.

2. ZKPs, allow claims to be verified without exposing the information behind them.

3. Architecture determines where those technologies belong, what they’re allowed to do and which trust assumptions they remove.

4. Hardware acceleration determines whether the resulting system can operate quickly and efficiently to be useful.

The future of privacy-preserving computation will be built by understanding how the pieces fit together, and by refusing to confuse speed, encryption or proof with security. The objective isn’t just stronger encryption. It’s useful computation without exposure.

The Problem Was Never Storage

Cybersecurity has focused heavily on protecting data at rest and in transit. And it does that extremely well. Encrypt the database. Encrypt the connection. Restrict access. Monitor the endpoint. Log the administrator. But they don’t solve the central problem. When the data needs to be used, it’s gets decrypted.

That plaintext can appear inside an application, memory, analytics platform, cloud environment, administrative interface, artificial-intelligence pipeline or third-party service. The data may be perfectly protected while stored and transmitted, but become fully visible during the operation that gives it value.

That’s the inherent contradiction: We protect data until the moment we need it.

Then it gets exposed in the exact infrastructure we spend the rest of the security budget trying to trust. FHE challenges that model by allowing data to stay encrypted while computation takes place. ZKP challenges the assumption that verification means disclosure. They change where trust is needed.

FHE Is a Family

CKKS is designed for approximate arithmetic over real or complex numbers. It’s particularly useful for packed numerical workloads such as analytics, signal processing and machine-learning inference.

BFV and BGV are better suited to exact integer or modular arithmetic.

TFHE is particularly strong for comparisons, lookup tables, programmable bootstrapping, policy decisions and exact logical or integer operations.

• If the system needs large-scale approximate numerical analysis, CKKS may be appropriate.

• If it needs exact accounting or modular operations, BFV or BGV may fit better.

• If it needs encrypted comparisons, branching or policy enforcement, TFHE may be the stronger choice.

In many cases, the answer won’t be one scheme. It’ll be a hybrid architecture that uses several. The useful questions are:

• What kind of computation?

• Over which data type?

• With what precision?

• At what depth?

• For what batch size?

• With which latency requirement?

• And under whose control?

ZKP Changes What Verification Means

ZKP solves different problems. It doesn’t generally compute over encrypted data in the same way as FHE. It proves that defined statements are true without disclosing the information used to establish it.

• That might mean proving that someone is over 18 without revealing their date of birth.

• It might mean proving that a transaction falls within an approved limit without revealing the account balance.

• It might mean proving that a credential is valid without handing a copy of it to every service that asks.

• It might also mean proving that a computation followed an agreed process.

The verifier receives the answer. It doesn’t automatically receive the evidence. Most digital identity and compliance systems are built around repeated disclosure. A person presents a document. An organisation copies it. A service retains it. Another system verifies it. A third party receives it for audit. Each point creates a copy and another breach target.

ZKP is a different model. The system can verify the claim without collecting the underlying record. That moves data minimisation to the protocol itself. But ZKP isn’t magic.

A proof establishes what the circuit or constraint system actually checks, not what was intended. A valid proof can still be based on unreliable inputs. A credential may be fraudulent, expired, compromised or issued through a weak identity process. A ZKP can prove that the specified rules were followed. It can’t fix bad rules, untrustworthy sources or careless governance.

Privacy-Preserving Doesn’t Mean Privacy Guaranteed

The use of ZKP in European digital identity and age verification makes this distinction clear. A person may be able to prove that they’re over a required age without disclosing their name, exact age or date of birth.

That’s better than uploading a passport, identity card or selfie to every platform demanding proof. But a privacy-preserving proof can still operate inside a broader architecture that raises serious questions.

• Who issues the credential?

• Who controls the wallet?

• What metadata is generated?

• Can the proof be linked across services?

• Which websites are permitted to demand it?

• What happens when a mechanism created for clearly age-restricted content expands into more general online access?

ZKP can reduce the information disclosed when a question is asked. It can’t decide if the question should be asked. That’s a governance decision. The technology can minimise disclosure. It can’t guarantee institutional restraint.

This is why privacy can’t be assessed by looking at things in isolation. A secure proof doesn’t create a private system. A secure computation doesn’t create a trustworthy application.

Architecture Is Where the Security Actually Lives

FHE and ZKP are powerful because they make different architectures possible. They allow a system to move away from broad access and towards constrained authority.

• A bank may be allowed to determine whether a lending threshold is satisfied without exposing the applicant’s complete financial history. As ING does.

• A medical service may be allowed to evaluate an eligibility condition without receiving the full clinical record.

• A cloud platform may be allowed to perform an encrypted computation without accessing the data or the final plaintext result.

• A verifier may be allowed to confirm a claim without storing the evidence behind it.

Each component learns only what it needs to perform its role. That means fewer plaintext copies, less unnecessary retention, smaller breach consequences, reduced insider access, less cross-service correlation and fewer assumptions about who or what can be trusted.

Hardware Makes It Practical

FHE and ZKP involve large ciphertexts, polynomial operations, transforms, key switching, memory movement, constraint systems, commitments, hashing, proof generation and, in some schemes, repeated bootstrapping.

General-purpose processors can perform these operations. They just may not perform them quickly or efficiently enough.

Hardware acceleration matters. GPUs can provide massive parallelism. FPGAs can implement specialised pipelines while remaining reprogrammable. ASICs can deliver exceptional performance and energy efficiency for stable, well-defined operations. CPUs remain essential for orchestration, flexible control flow and software fallback. The future will use all of them. But mistaking one impressive component for the complete system, is dangerous.

Performance Must Be Measured Honestly

The relevant measurement isn’t always the fastest individual kernel. It also includes host-to-device transfers, memory bandwidth, key movement, ciphertext layout, proof-generation overhead, batching delays, sustained operation, cooling and power, failure recovery, multi-tenant isolation and software integration.

Throughput and latency also need to be separated. One million operations per second may be excellent for bulk analytics and irrelevant for a person waiting on a login screen. A two-second proof may be unacceptable for one transaction and entirely reasonable if it can be verified millions of times.

There’s no meaningful performance number without a workload. And there’s no meaningful workload without an architecture.

The Trust Boundary Hasn’t Disappeared

Systems still depend on software integrity, key management, credential issuance, circuit correctness, parameter selection, hardware reliability, metadata protection and operational governance.

Evaluation keys may be intentionally available to the computing party while secret decryption keys are protected. Verification keys may be public while private witnesses are confidential. A cloud accelerator may never see plaintext but still control availability, execution, isolation, firmware and updates. A hardware provider may not hold the data but may control the runtime on which the system depends.

A system that removes reliance on one cloud provider but creates absolute dependence on a proprietary accelerator hasn’t necessarily achieved sovereignty. A system that keeps data encrypted but depends on foreign-controlled firmware, updates and infrastructure can still carry significant geopolitical and operational risk.

Sovereignty Is Architectural Too

This question is especially important in Europe, Canada and other jurisdictions trying to retain control over critical digital infrastructure. Data sovereignty isn’t only about where a database is located.

It includes control over keys, software, hardware, firmware, updates, identity systems, the legal environment and the ability to continue operating when an external supplier withdraws support. A server physically located in Europe may still depend on a foreign cloud control plane. An accelerator deployed locally may still require firmware controlled abroad. A privacy-preserving service may still rely on a mobile operating system, app store or identity issuer operating under another jurisdiction.

Sovereignty is the ability to operate, govern and adapt the system without asking another party for permission. Privacy-preserving architecture can support that objective. But, it doesn’t guarantee it.

Hybrid Systems Will Become Normal

The strongest systems won’t insist on one universal answer. They’ll combine technologies according to the workload:

• CKKS may handle packed numerical analysis.

• BFV or BGV may handle exact integer operations.

• TFHE may handle comparisons and policy logic.

• ZKP may validate credentials, inputs, outputs or correct execution.

• CPUs may coordinate the workflow.

• GPUs may accelerate large parallel operations.

• FPGAs may reduce the latency of specific bootstrapping or transformation stages.

• Specialised hardware may support proof generation.

The mistake isn’t in the technologies or how they are combined, or not. The mistake is allowing the transitions between them to recreate the plaintext exposure, metadata leakage and broad trust the system was meant to remove.

• Every boundary matters.

• Every transfer matters.

• Every output matters.

The system is only privacy-preserving if the complete path is privacy-preserving.

Real Change

Conventional security begins with access.

• Who may enter?

• Who may read?

• Who may administer?

• Who may retrieve the record?

The modern security systems will ask:

• What does this component actually need to know?

• What computation is it authorised to perform?

• What claim must be verified?

• Which information can remain encrypted?

• Which evidence never needs to be disclosed?

• What output is safe to release?

• Can repeated queries reveal more than one query would?

• Who controls the keys, proofs, hardware and software?

• Which trust assumptions can be removed?

• Which ones can’t?

Useful Computation Without Routine Exposure

The challenge isn’t that FHE, ZKPs, privacy-preserving architecture and hardware acceleration are inherently impractical. The real challenge is understanding what each technology does, where it belongs, and how the pieces work together.

Forty years ago, organisations were only beginning to work out how to secure digital data. Encryption, access control, identity management and network security often sounded complex. Over time, the principles became understood, the tools improved, and secure data handling became part of ordinary system design.

Privacy-preserving computation is the next stage of that evolution.

FHE allows data to remain encrypted while it’s being used. ZKPs allow claims to be verified without routinely exposing the evidence. Architecture determines what each system is allowed to know and do. Hardware acceleration makes those choices practical at scale. None of this removes the need for judgement.

The question isn’t just who can access the data. It’s what computation should be allowed, what claim needs to be proven, what output is safe to reveal, and which components actually need knowledge of the underlying information.

That may sound difficult today, but the difficulty isn’t a failure of the technology. It’s the normal learning curve that comes with a new architectural model.

The maths exist. The hardware is catching up. The real work is to understand the technologies well enough to use them properly. That means knowing which scheme fits the workload, where proof is required, where plaintext can be removed, and how the architecture should be structured before acceleration is added.

This is precisely the problem PrivID was built to address.

Not by forcing one technology into every system, but by understanding how FHE, ZKP, identity, architecture and hardware need to work together.

It’s time to evolve from protecting data only while it’s stored or moving to protecting it while it’s being used, and stop treating routine exposure as an unavoidable.

CAVEAT: I’m not a maths person, by any stretch, this is based on my research and information gathered along with it from speaking to others. If there are errors in this article please let me know.

FHE uses larger ciphertexts, more complex maths, noise management, key switching and, in some schemes, repeated bootstrapping. ZKP can need large constraint systems, substantial memory, parallel processing and considerable proof-generation time. The question that needs to be answered in both cases is whether they are fast enough, cheapenough and reliabe enough for real systems.

That’s where hardware acceleration comes in.

Once a company has built a faster processor, accelerator or software backend, the conversation becomes about benchmarks: operations per second, dramatic reductions in latency, orders-of-magnitude improvements, lower power consumption, faster proof generation or faster bootstrapping - yadda yadda yadda.

Why Encrypted Compute Is So Expensive

Ordinary processors are designed around plaintext. They’re efficient because the underlying values are directly available. Comparisons are cheap, arithmetic is straightforward, and branching is built into the execution model.

With FHE things are different. It works with ciphertext structures containing mathematical representations of encrypted information, and they could be much bigger than the original data.

Trivial operations in plaintext can require polynomial arithmetic, modular reduction, Number Theoretic Transforms, Fourier transforms, key switching, ciphertext rotations, modulus switching, rescaling, noise management and bootstrapping. The exact workload depends on the scheme.

CKKS, BFV, BGV and TFHE don’t impose the same computational demands. Neither do different ZKP systems.

There’s no single operation called “encrypted computing” that hardware can accelerate universally. There are families of workloads with different mathematical shapes, memory patterns and performance requirements.

CKKS, BFV and BGV Share Some Machinery

CKKS, BFV and BGV are built around polynomial arithmetic over lattice-based structures. Their workloads depend heavily on polynomial multiplication, modular arithmetic, residue-number representations, Number Theoretic Transforms, ciphertext rotations and key switching.

A processor designed to accelerate polynomial multiplication or Number Theoretic Transforms may benefit all three schemes. But shared mathematical primitives doesn’t mean they’re the same.

CKKS performs approximate arithmetic and needs careful management of scale and precision. BFV and BGV are generally used for exact integer or modular arithmetic. The depth of the computation, parameter selection, ciphertext modulus and bootstrapping requirements will differ.

The same accelerator may support several schemes while performing very differently across each one. That’s why saying hardware “supports FHE” isn’t the entire picture.

• Which scheme?

• Which parameters?

• Which operations?

• At what depth?

• For what batch size?

TFHE Is a Different Workload

TFHE puts greater emphasis on programmable bootstrapping, comparisons, lookup tables and exact logical or integer operations.

Programmable Bootstrapping, or PBS, is one of TFHE’s most useful features. It can refresh a ciphertext while evaluating a defined function, making TFHE effective for comparisons, threshold checks, policy decisions, conditional logic, non-linear operations, encrypted lookup tables and exact decision-oriented workloads.

But PBS is expensive. It can involve large evaluation keys, substantial memory movement, Fourier transforms and repeated processing across many encrypted operations. That creates a very different acceleration problem from large, packed CKKS workloads.

CKKS benefits strongly from processing many packed values in parallel. TFHE is frequently considered for transactional or decision-oriented workloads where the cost and latency of repeated programmable bootstrapping become central.

That doesn’t mean TFHE is limited to small or irregular workloads. Modern implementations can batch and parallelise programmable bootstrapping extensively, particularly across GPUs and specialised hardware.

CKKS often favours packed throughput. While TFHE places greater emphasis on the cost, repetition and latency of programmable bootstrapping.

Real systems may need both. That’s where benchmarks become slippery. A machine can perform extremely well when processing large batches under ideal laboratory conditions and still perform poorly in a transactional system handling individual requests.

ZKP Has Its Own Problems

Proof generation may involve polynomial commitments, multiscalar multiplication, fast Fourier transforms, finite-field arithmetic, hashing, Merkle-tree construction, constraint evaluation and large amounts of memory movement. The exact workload depends heavily on the proof system.

A SNARK doesn’t necessarily impose the same demands as a STARK. Different proving systems may prioritise different curves, fields, hashes, commitment schemes and recursion models. Some proofs may be generated on a mobile device. Others may need a server, GPU cluster or dedicated accelerator. Verification is cheap, proving is expensive.

If proof generation takes seconds, consumes gigabytes of memory or drains a mobile battery, it may be unsuitable for a user-facing identity transaction. If the same proof can be created once and verified millions of times, that cost is acceptable.

CPUs, GPUs, FPGAs and ASICs

There’s no single correct hardware platform for encrypted computation. Each approach brings different strengths and compromises.

CPUs

CPUs are flexible and widely available. They’re useful for development, testing, low-volume workloads, orchestration, irregular control flow and systems where deployment simplicity matters more than maximum performance.

General-purpose flexibility has a price. CPUs may be inefficient for the repetitive, highly parallel arithmetic common in FHE and ZKP workloads.

GPUs

GPUs offer massive parallelism. They can be effective for polynomial arithmetic, multiscalar multiplication, Fourier transforms, Number Theoretic Transforms, proof generation and large batched workloads.

But GPU performance depends on feeding the hardware enough parallel work. Small batches may underutilise the device, while memory transfers between the host and accelerator can introduce latency. Power consumption and cooling are significant factors under sustained load. (A great example are cryptocurrency miners. They run hot and require a great deal of cooling power)

FPGAs

Field-Programmable Gate Arrays, or FPGAs, offer a middle ground. They can implement specialised data paths AND be reprogrammable, making them useful where schemes, parameters and libraries are still evolving.

An FPGA can be optimised for bootstrapping, modular multiplication, polynomial transforms, key switching and specific proof-generation stages. The trade-off? Development complexity.

Hardware design, firmware, memory architecture, timing and software integration all need specialised expertise. A theoretically efficient FPGA implementation may still fail commercially if the software layer is awkward or the deployment model is too difficult.

ASICs

Application-Specific Integrated Circuits, or ASICs, can offer exceptional performance and efficiency because they’re designed around a specific workload.

Cryptographic systems evolve. Parameters change. Security assumptions are revised. Libraries introduce new representations. Those can all become problematic forf ASICs.

A chip optimised around one narrow implementation may become less useful if the software ecosystem shifts. Stable primitives such as modular arithmetic, transforms and key switching can be useful across multiple schemes and implementations. The risk depends on how narrowly the hardware has been designed.

ASIC development is also expensive and slow. By the time the chip reaches production, parts of the workload it was designed around may already have changed. This means they need a high degree of confidence that the target operations will still be important.

Memory Is the Real Bottleneck

Discussions about acceleration usually focus on computation, but, memory movement may be just as important. Encrypted data structures are large. Bootstrapping keys can consume a lot of memory. Proof generation may need large intermediate values. If the accelerator spends most of its time waiting for data to move between memory, processors and storage, faster arithmetic units won’t solve the problem.

The system has to consider memory bandwidth, local accelerator memory, cache behaviour, key storage, host-to-device transfer, ciphertext layout, batching strategy and data locality.

A processor may complete one mathematical operation extremely quickly. But if the data has to travel across a slow bus before and after every operation, the application will still feel slow.

Batch Size Is The Key

CKKS can pack many values into one ciphertext and process them together. TFHE and ZKP proving can also benefit from parallelism, aggregation and batched execution. That can produce impressive throughput numbers. But throughput and latency aren’t the same thing.

Suppose an accelerator processes one million encrypted values efficiently when they’re submitted together. That may be ideal for overnight analytics, scientific modelling, large portfolio calculations, aggregate machine-learning inference or bulk compliance processing. It may not be ideal for one login request, one payment decision, one medical eligibility check, one age-verification proof or one access-control decision.

A user doesn’t care how many requests the system could process in an hour if their individual request takes ten seconds. Conversely, a low-latency accelerator may be excellent for individual decisions but inefficient for large analytical workloads.

Sustained Performance Matters

A short benchmark proves that the hardware can perform an operation. It doesn’t prove that the system can operate reliably. Real deployments mean sustained performance.

• What happens after hours of continuous use?

• Does the device throttle? How much cooling is required?

• Does power consumption remain stable?

• Are memory errors detected?

• How are failed computations handled?

• Can workloads be resumed?

• Does performance degrade as keys or parameters increase?

• What happens when multiple tenants share the device?

• How is cryptographic material isolated?

These questions are both security and operational. A failure during ordinary computation is inconvenient. A failure during encrypted computation could produce invalid results, corrupted ciphertexts or unavailable services. If the accelerator becomes a central dependency, it also becomes a central point of failure. Acceleration has to improve the system not create a new concentration of risk.

Key Control Is Not An Afterthought

FHE systems can require evaluation keys, bootstrapping keys, switching keys and other cryptographic material. ZKP systems may depend on proving keys, verification keys, setup parameters or private witness data.

Evaluation, server, switching and bootstrapping keys are commonly intended to be available to the party performing the encrypted computation. They aren’t normally secret in the same way as the decryption key.

Making an evaluation key available doesn’t usually allow the evaluator to decrypt the underlying data. But those keys still need governance because possession may permit computation, resource consumption, service misuse or operational disruption. They may also reveal metadata, parameter choices or implementation details.

ZKP material varies as well. Verification keys can be public. Proving keys can be large not necessarily confidential. The witness, however, is private input and must be protected accordingly.

The architecture has to define where these materials are generated, where they’re stored, which hardware can access them, whether an operator can copy or misuse them, how they’re versioned, how compromised material is revoked and whether the secret keys and private witnesses remain under the control of the data owner.

This is important especially when acceleration is delivered through cloud infrastructure. In which case the user is relying on the provider for availability, correct execution, workload isolation, handling of cryptographic material and protection.

Sovereignty Is Part of the Hardware Question

Who designs the accelerator? Where is it manufactured? Who controls the firmware? Who maintains the compiler and runtime? Where are updates distributed from? Can the platform continue operating if a foreign supplier withdraws support? Does the hardware depend on a cloud environment controlled by another jurisdiction? Could access be restricted during a political or commercial dispute?

These questions are crucial for critical infrastructure, government systems, finance, healthcare and defence.

A system designed to reduce reliance on cloud providers may simply move that reliance into proprietary acceleration hardware. A system designed for data sovereignty may still depend on firmware, drivers or updates controlled elsewhere.

• Technical control isn’t the same as legal control.

• Legal control isn’t the same as operational independence.

• A genuinely sovereign architecture has to consider all three.

Software Integration Determines If Hardware Is Useful

Hardware doesn’t operate in isolation. Developers need libraries, compilers, runtimes, APIs, monitoring tools and debugging support. An accelerator may be extremely fast but commercially irrelevant if using it requires rewriting the entire application. The software layer has to answer practical questions:

• Can existing FHE libraries use the accelerator?

• Does it support standard APIs?

• Which operations are offloaded?

• Which remain on the CPU?

• Can the application fall back to software?

• How are errors reported? Can performance be measured in production?

• Are parameter choices exposed to developers?

• Does the implementation preserve constant-time or side-channel protections? How difficult is deployment?

The best hardware implementation may not win. But the implementation developers can actually integrate will.

Hardware and Software Need Each Other

Software implementations matter because they provide flexibility. They allow schemes to evolve. They let researchers test new parameters, algorithms and hybrid workflows. They can be updated without replacing physical hardware.

Hardware matters because software alone may not achieve the latency, throughput or power efficiency required for deployment. A good accelerator shouldn’t try to replace the cryptographic library. It should expose capabilities the library can use intelligently.

The software should decide which operations to offload, when batching is worthwhile, when latency matters more than throughput, which scheme fits the workload, whether a CPU, GPU or FPGA is appropriate and when a software fallback is safer.

Hybrid Acceleration Will Be Normal

A system may use CPUs for orchestration, GPUs for large CKKS batches, FPGAs for low-latency TFHE bootstrapping, specialised hardware for ZKP proving, local devices for credential proofs and cloud infrastructure for large analytical workloads.

Different workloads need different execution environments. The challenge is ensuring that movement between them doesn’t reintroduce plaintext exposure, leak metadata or create uncontrolled trust boundaries. Each transfer has to be considered part of the architecture.

Where does the ciphertext move? Where is the witness generated? Where is the proof created? Where is the result decrypted? Who controls each component? What can each component infer?

An Infographic to Illustrate the system.

Faster Doesn’t Mean Safer

A faster implementation may still use insecure parameters, leak through timing or memory access, mishandle keys, rely on undocumented assumptions, fail under sustained load, expose metadata, generate incorrect results or accelerate only a narrow demonstration.

The fastest system isn’t automatically the safest. Neither is the slowest system automatically more rigorous. Performance, correctness and security have to be evaluated separately.

Architecture Must Define the Accelerator

What workload are we accelerating? Which FHE or ZKP system is involved? Which operation dominates the cost? Is the workload batched or transactional? What latency is acceptable? What throughput is required? Which keys or witnesses must be protected? Where will the hardware operate? Who controls the firmware and runtime? What happens if the accelerator is unavailable? Can the system fall back safely? Does the hardware reduce trust or merely relocate it?

These questions need to be answered before the choice of hardware become meaningful.

Acceleration Makes the Architecture Practical

Without hardware acceleratoin many FHE and ZKP workloads will be too slow, too expensive or too energy-intensive for broad deployment. But:

• Hardware doesn’t decide what should be encrypted.

• It doesn’t decide what should be proven.

• It doesn’t decide which parties should be trusted.

• It doesn’t decide whether a result reveals too much.

• It doesn’t decide whether a system should exist.

• It makes an already well-designed process faster.

Tomorrow, we’ll bring the pieces together:

• FHE changes how data can be used.

• ZKP changes how claims can be verified.

• Architecture determines how those technologies fit.

• Hardware determines whether the resulting system can operate at scale.

  Thanks for reading PrivID's Substack! Subscribe for free to receive new posts. We will never paywall.

In the second, we looked at ZKPs, and how they can prove that a statement or computation is true without exposing the information behind it.

Neither technology works properly if it’s ‘added’ to an existing system, like an afterthought. They need a different way of designing software.

That is where many organisations will struggle. Not because the mathematics is impossible, but because the architecture they have was built around assumptions these technologies remove.

The Old Model Is Built Around Decryption

Most modern systems follow a pattern:

• Data is encrypted while stored.

• It’s encrypted while transmitted.

• When the system needs to use it, it’s decrypted.

The application reads the plaintext. The processor operates on the plaintext. The service makes a decision using the plaintext. The result is encrypted again.

That model is so prevalent that barely anyone looks twice at it. Encryption is treated as a protective layer around the data.

FHE and ZKP challenge the foundations of the conventional application stack. That’s why they can’t be treated like just another security feature. A system designed around plaintext access will not become privacy-preserving just because FHE or ZKP is incorporated into it. The architecture still expects visibility.

The Plaintext Window Is the Real Problem

Current encryption is good at protecting data while it’s not in use. It protects files stored on a disk. It protects traffic moving across a network. But when the data is needed, it’s decrypted. That creates a plaintext window.

During that window, the data can be exposed to:

• the application processing it;

• the operating system;

• administrators;

• cloud infrastructure;

• debugging and monitoring tools;

• malicious insiders;

• compromised dependencies;

• memory-scraping attacks; and

• anyone who gains control of the system while the data is in use.

This isn’t an exception—it’s the normal operating model. Security teams try to protect that window through access controls, logging, segmentation, endpoint protection and policy.

That doesn’t remove the fundamental condition: the data is still visible somewhere.

The conventional model depends on trust:

• We trust the application.

• We trust the cloud provider.

• We trust the administrator.

• We trust the operating system.

• We trust the identity system.

• We trust that the access-control rules are correct.

• We trust that the software supply chain has not been compromised.

That’s a lot of assumptions based on trust. FHE and ZKP take a different approach. They don’t ask how many controls should surround the plaintext window. They ask does the data (plaintext window) need to be exposed at all.

Encryption in Use Changes the System

With FHE, computation can happen while the data is encrypted. That sounds simple. It’s not. An application may expect to:

• compare values directly;

• branch based on a condition;

• search records;

• perform floating-point calculations;

• update state;

• call external services;

• display intermediate results; and

• log what happened.

An FHE system can’t assume that those operations work in the same way. The data is encoded into ciphertexts. The available operations depend on the scheme. The order of operations matter. The depth of the computation matters. Noise growth matters. Bootstrapping matters. Ciphertext size matters. Memory movement matters.

A process that is trivial in plaintext can become expensive when encrypted. Conversely, a process that looks complicated in ordinary software may become efficient if data can be batched and processed in parallel.

The application has to be designed around the cryptographic model, not the other way around. This is the first major shift.

The Question Changes From Access to Computation

Conventional security architecture begins with: Who is allowed to access this data?

FHE has a different question: What computation is allowed to happen over this data?

A user or service can be permitted to run a calculation without ever being permitted to see the underlying information.

• In finance: A bank could calculate whether a customer satisfies a lending threshold without exposing the customer’s full financial history.

• In healthcare: A medical platform could identify whether a treatment condition is satisfied without revealing every clinical measurement.

• In employment: An employer could verify whether a person holds a required qualification without receiving the qualification record.

The authority is not just permission to read; it could be permission to compute.

That means a more granular security model:

• which inputs can be used;

• which operations can be performed;

• which outputs can be returned;

• who can decrypt the result;

• whether the result itself reveals too much; and

• whether repeated queries could reconstruct the underlying data.

A system can protect the input perfectly and still leak information through the output. Cryptography does not eliminate inference. Architecture has to account for it.

ZKP Changes Verification

ZKP creates a similar change. Verification is usually built around inspection. A person submits a document. A company uploads financial records. A service provides logs. An employee presents a credential. The verifier examines the evidence and decides whether to trust it.

This model creates copies. Every verification creates another recipient. Every recipient may store the evidence. Every stored copy becomes another breach target.

ZKP allows verification to happen without needing to transfer the evidence. That changes the relationship between the prover and verifier. The verifier doesn’t need broad access to the data, it needs a [mathematically] defined claim and a valid proof.

The new architecture distinguishes between:

• the information;

• the claim being made about it;

• the evidence used to support the claim;

• the proof generated from that evidence; and

• the party authorised to verify it.

Those elements are usually collapsed in conventional systems. A scanned passport can simultaneously serve as identity data, evidence, credential and stored audit record. Convenient, but also why organisations end up holding millions of documents they never really need.

Data Minimisation Must Be Designed In

Many organisations ask for the complete record because it is easier. They retain it because it may be useful. They secure it because they now possess it. They delete it only if policy, regulation or litigation forces them to. That is not minimisation.

ZKP makes it possible to design the decision around the minimum necessary claim. FHE makes it possible to process data without automatically exposing it. Together, they allow minimisation to go from policy to protocol.

That doesn’t mean every piece of data disappears. A proof still depends on inputs. An encrypted computation still depends on ciphertexts, keys and authorised outputs. But the architecture can be structured so that fewer systems get plaintext and fewer organisations hold copies. That’s a big change:

• A privacy policy says an organisation should not misuse data.

• A privacy-preserving architecture reduces the organisation’s ability to misuse it.

Identity Isn’t a Binary Gate

Most access-control systems still work in a binary system. A user authenticates, the system determines their role, and the role grants access. This model treats identity as a gateway to data. Once someone is inside the permitted boundary, the application often assumes they may see or process the information associated with that role.

FHE and ZKP allow identity to become more contextual. A system can ask:

• Is this person authorised for this specific operation?

• Do they satisfy the required condition?

• Is the credential valid now?

• Is this request within an approved limit?

• Is the device or service permitted to perform this computation?

• Can the result be released without revealing protected information?

The answer can be proven without necessarily revealing the person’s full identity, and the computation can happen without needing to reveal the data.

That moves the system towards constrained authority.

• Access says: Enter.

• Constrained authority says: You can perform this operation, under these conditions.

The Application Has to Know Less

Traditional application design rewards visibility. Developers want access to logs. Administrators want access to records. Support teams want access to user accounts. Analytics platforms want access to events. Artificial intelligence systems want access to everything.

The argument is usually that visibility improves functionality. But a privacy-preserving architecture has a different argument - what is the bare minimum needed to be functional. Usually, it’s a lot less than organisations say they need.

• The authentication service may need to know that a credential is valid; it may not need to know the credential’s contents.

• The analytics service may need to calculate an aggregate; it may not need to see the individual records.

• The eligibility engine may need to return yes or no; it may not need to know the exact values used to reach that decision.

• The cloud provider may need to process the workload; it may not need access to either the data or the result.

This is not just least privilege applied to users—it’s least knowledge applied to systems. That is a completely different way of thinking.

Existing Software Is Usually the ‘Wrong Shape’

Most existing software was not designed for encrypted computation:

• random access to plaintext;

• conventional branching;

• cheap comparisons;

• unrestricted logging;

• flexible data formats;

• database queries over readable values;

• ordinary debugging; and

• direct integration with external services.

FHE breaks many of those assumptions. ZKP adds new layers around circuit construction, witness handling, proof generation and verification.

Retrofitting these technologies into a legacy application may need more than changing a few functions. The data model may need to change. The workflow may need to change. The database may need to change. The application boundaries may need to change. The identity model may need to change. The team may even need to reconsider which operations should happen at all.

Some processes exist only because plaintext is available. Once visibility is removed, organisations may discover that certain analytics, integrations or administrative practices weren’t really needed. They were just nice to have.

Migration Has to Be Staged

None of this means an organisation needs to replace its entire system overnight. The more practical approach is staged migration.

1. Identify exposure: Start by identifying where the most sensitive plaintext exposure happens. Look for operations involving identity, financial records, medical information, intellectual property, authentication secrets, regulated data, cross-organisational sharing, and cloud processing outside direct control.

2. Isolate operations: Identify which operations can be isolated. A system may begin by encrypting one calculation rather than an entire application. A ZKP may replace one document-disclosure process. An encrypted policy check may replace one database lookup. A protected identity attribute may replace one reusable identifier.

The objective isn’t to force every operation into FHE or ZKP. That would be as misguided as forcing every calculation into TFHE or CKKS. The objective is to identify where plaintext visibility and exposure create the greatest risk. Redesign those parts first.

Hybrid Systems Will Be Normal

The future architecture will probably not be purely FHE, purely ZKP or purely anything else. It will be hybrid.

• Some data may stay in conventional encrypted storage.

• Some calculations may use CKKS.

• Some may use BFV or BGV.

• Some decisions may use TFHE.

• Some claims may be proven with ZKP.

• Some operations may happen in trusted local environments.

• Others may be delegated to accelerated hardware or external infrastructure.

The challenge is not finding one universal cryptographic scheme; it’s coordinating several technologies without reintroducing the exposure they were intended to remove. That includes deciding:

• where keys are held;

• where proofs are generated;

• how ciphertexts move;

• who can request computations;

• how results are validated;

• when scheme switching is required;

• where metadata is exposed; and

• which components still require trust.

The system will only be as private as its weakest architectural boundary. A ZKP protecting one claim does little if the application leaks the underlying information through logs. FHE protecting a calculation doesn’t do much if the result is decrypted into a poorly secured service.

Hardware Doesn’t Fix Bad Architecture

Hardware acceleration will be essential to making many FHE and ZKP workloads practical, but acceleration can’t fix a badly designed system.

• A processor can make bootstrapping faster; it can’t decide whether TFHE was the right scheme.

• A GPU can reduce proof-generation time; it can’t tell whether the circuit proves the right claim.

• An FPGA can accelerate polynomial arithmetic; but it can’t prevent an application from logging plaintext elsewhere.

Hardware can reduce latency, increase throughput and lower computational cost. It can’t remove architectural contradictions.

This is why performance benchmarks need to be treated carefully. A claim that an accelerator performs a particular operation thousands of times faster may be accurate, but:

• Is that the operation the application needs?

• At the required security parameters?

• With realistic key sizes?

• Under sustained load?

• With acceptable memory consumption?

• For single requests or only large batches?

• Without moving sensitive data into a new trust domain?

Faster is good. Faster in the wrong architecture is just a faster mistake.

The Security Model Needs To Be Rewritten

FHE and ZKP force organisations to confront assumptions that conventional security leaves untouched.

• Why does this service need the plaintext?

• Why does this verifier need the document?

• Why does this administrator need broad visibility?

• Why is this identifier reused across systems?

• Why is this dataset copied?

• Why is the cloud provider trusted?

• Why is the result decrypted here?

• Why is the evidence retained after the decision?

The usual answer is some version of: “Because that is how the system works.”

That’s just rationalising a bad design.

Architecture Before Cryptography

The first questions in any modern redesign should be:

• What should the system accomplish?

• What information is actually needed?

• Which components really need plaintext?

• Which claims need to be verified?

• Which operations can happen over encrypted data?

• Which outputs are safe to reveal?

• Which trust assumptions can be removed?

• Which ones still remain?

FHE and ZKP are not just layers added to an existing application. They change the relationship between data, computation, identity and trust. FHE allows the system to compute without seeing. ZKP allows the system to verify without being shown.

They both point to an architecture in which access is narrower, disclosure is reduced and trust is no not the default setting.

That is the real change. Not stronger encryption. Different thinking.

In the next article, we will look at what happens when this architecture meets hardware—and why acceleration has to support the workload rather than define it.

Today, we look at something different: ZKP, Zero-Knowledge Proof.

ZKP lets someone prove that a statement is true without revealing the information used to prove it.

Right, at this point you are either asking yourself why are we discussing this, it has nothing to do with FHE! What if I told you it does?

FHE protects data while it’s being processed. ZKP reduces, or eliminates, how much data needs to be disclosed. One protects the computation. The other proves the information or computation without exposing it. Together, they have the potential to change how digital trust is designed.

What Is a ZKP?

ZKP is a method where one party can demonstrate that a claim is valid without revealing the information supporting that claim. Bear with me, this is a bit tricky.

The party creating the proof is called the prover. The party checking it is called the verifier. The private information used to generate the proof is often called the witness.

Let’s say someone needs to prove that they’re over 18. A conventional identity system might require them to provide:

• their full name;

• date of birth;

• home address;

• photograph;

• identity-document number; and

• a copy of the document itself.

But the organisation checking the requirement doesn’t really need any of that It needs the answer to one simple question: Is this person over the required age?

ZKP can let the individual prove that the answer is yes without revealing their date of birth or showing the underlying document(s) to every service that asks. The verifier learns that the condition has been satisfied. More importantly it doesn’t learn any private information beyond the confirmation of age.

What “Zero Knowledge” Actually Means

The term zero knowledge doesn’t mean the verifier learns nothing at all. The verifier learns that the statement being proved is valid. That’s all they need. They don’t need documentation to be uploaded or scanned. They just need validation of the question or statement. A well built zero-knowledge system will satisfy three broad properties:

Completeness

If the claim is true and the parties follow the protocol correctly, the verifier should accept the proof.

Soundness

If the claim is false, a dishonest prover shouldn’t be able to convince the verifier that it’s true, except with an extremely small probability.

Zero knowledge

The verifier shouldn’t learn the witness or other protected information beyond what can be inferred from the validity of the claim itself.

A system that hides the evidence but allows false claims isn’t useful. A system that proves the claim but leaks the evidence isn’t zero knowledge. Achieving both means verification and privacy.

Proof Is Not Encryption

ZKP proves that a statement about data or computation is true.

• a person satisfies an age requirement;

• a transaction falls within an authorised limit;

• a credential was issued by a recognised authority;

• a calculation was performed correctly;

• a password or private key is known;

• a model produced an output according to an agreed process;

• a software component followed a defined rule; or

• an account has sufficient funds without revealing its balance.

Proof confirms a condition. FHE is about performing operations while the data is encrypted.

Interactive and Non-Interactive Proofs

Early zero-knowledge systems were interactive. The prover and verifier exchanged multiple messages. The verifier issued challenges, and the prover responded in ways that demonstrated knowledge of the secret without disclosing it.

That isn’t practical in large systems. Many modern applications use Non-Interactive Zero-Knowledge proofs, or NIZKs. This can be used in:

• distributed systems;

• blockchains;

• identity credentials;

• asynchronous transactions;

• audit records;

• cloud services; and

• systems in which many parties may need to verify the same proof.

A proof can be created once and verified as needed. That doesn’t mean the same proof should always be reused. It means the verification process doesn’t need a conversation.

SNARKs and STARKs

Two acronyms usually appear in ZKP discussions: SNARK and STARK.

A SNARK is a Succinct Non-Interactive Argument of Knowledge.

A STARK is a Scalable Transparent Argument of Knowledge.

Both are families of proof systems. The word succinct means the proof can be relatively small and efficient to verify, regardless of the size of the underlying computation. The word transparent implies that the system avoids the trusted setup of SNARK constructions.

A trusted setup creates shared cryptographic parameters. If the material isn’t processed, and destroyed, properly, it can compromise system integrity.

That doesn’t mean every SNARK needs the same type of trusted setup, or that SNARKs are unsafe. As with all things methods and results may vary. It just means the setup assumptions need to be understood.

STARKs are usually larger and typically need more verification. They’re associated with hash-based techniques that may offer stronger positioning against future quantum attacks. Neither are right or wrong. The correct proof system depends on:

• the size and complexity of the computation;

• proof-generation time;

• proof size;

• verification cost;

• trusted-setup requirements;

• recursion requirements;

• security assumptions; and

• the environment in which the proof will be checked.

The Circuit Defines the Claim

ZKP proves that a specific relationship has been met. That relationship is presented through a circuit, constraint system or equivalent structure. Suppose a proof needs to establish that someone is over a certain age, the circuit needs to confirm:

1. the date of birth came from a valid credential;

2. the credential was signed by an accepted issuer;

3. the credential hasn’t expired or been revoked;

4. the current date minus the birth date exceeds the required threshold; and

5. the proof is bound to the correct service and session.

The verifier doesn’t need to see the birth date. The system, on the other hand, still needs a precise definition of what is being proved. The proof will establish what is actually checked, not what its designers intended it to check. A flawed circuit can produce a perfectly valid proof of the wrong thing.

A Valid Proof Doesn’t Mean a Valid Source

ZKP can prove that a statement follows from the inputs provided to the proof system. It doesn’t automatically prove that those inputs were truthful, current or not stolen. Let’s look at an age verification proof:

The cryptography may prove that the date in a credential meets or exceeds the age requirement. But someone still needs to establish that:

• the credential was issued by a legitimate authority;

• it belongs to the person presenting it;

• it hasn’t been revoked;

• the issuer’s signing key hasn’t been compromised; and

• the original identity-verification process was reliable.

A proof is only as meaningful as the trust placed in the inputs and the rules being proven. The same applies to artificial intelligence.

ZKP may prove that a model was executed against a particular input and a result was produced. It doesn’t prove that the model was fair, sensible or appropriate. It proves that the specified process happened.

That difference tends to get lost when the word proof enters the discussion

Selective Disclosure Is Not the Same as Zero Knowledge

Selective disclosure lets someone to reveal only part of a credential.

For example, a digital identity credential might contain a name, address, date of birth and citizenship, while the holder reveals only the citizenship field. That’s better than disclosing the entire credential. But it isn’t specifically zero knowledge.

A zero-knowledge proof could prove that the person belongs to an authorised jurisdiction without revealing which jurisdiction it is; assuming the use case permits that.

Selective disclosure reduces unnecessary exposure. Zero knowledge can go further by proving a derived condition without revealing the attribute itself. Both work, but they are not the same.

This Is Already Happening in the EU

The revised eIDAS Regulation, which establishes the European Digital Identity framework, specifically calls for privacy-preserving technologies such as ZKP to be integrated into the European Digital Identity Wallet, or EUDI Wallet.

The objective is straightforward: a relying party should be able to confirm that a statement about someone is true without receiving the personal information on which that statement is based. The wallet could prove that someone:

• is over a required age;

• holds a valid qualification;

• has a recognised licence;

• is legally resident in a jurisdiction; or

• is entitled to access a particular service.

The organisation receives the answer it needs rather than the person’s complete identity record. At least that’s the idea.

The EU’s age-verification initiative brings the same model into a more controversial setting. The Commission has developed a technically ready system that lets someone prove they meet an age threshold without disclosing their exact age, identity or other personal details. The blueprint includes ZKP technology and can function as a standalone application or be integrated into an EUDI Wallet.

That is materially better than needing people to upload passports, national identity cards or selfies everytime a proof of age is needed. But ZKP doesn’t automatically make the surrounding system private, proportionate or safe.

The cryptographic proof may reveal only that the user is over a certain age. The broader architecture may still depend on:

• the organisation that originally verifies the person’s age;

• the issuer creating the credential;

• the wallet or age-verification application;

• the mobile operating system and app store;

• the device presenting the proof;

• the service requesting it; and

• the rules governing when that service is allowed to ask.

The Commission’s design tries to separate credential issuance from presentation. Once the proof of age has been issued, the proof provider shouldn’t learn which service the person visits, and the service shouldn’t receive identity information that could be used to trace them.

Metadata can still create patterns. Devices can still be fingerprinted. Poorly implemented credentials can still be correlated. Issuers can still make mistakes. Wallet software can still contain vulnerabilities. Governments and platforms can expand the situations in which proof is demanded.

A mechanism introduced for pornography, gambling or other age-restricted services can gradually become an identity checkpoint for ordinary online activity. A privacy-preserving gate is still a gate. That’s the difference between cryptography and governance.

ZKP can limit what is disclosed when a question is asked. It can’t decide whether the question should have been asked in the first place.

While eIDAS establishes the legal framework now, the EUDI Wallet rollout is still being implemented. Member States are expected to make at least one wallet available by the end of 2026. The age-verification is technically ready, but deployment and adoption are uneven.

Both eIDAS and EUDI Wallet show the promise of ZKP and its limitations. But it can’t guarantee that institutions or organisations will demand less.

Why ZKPs And Identity

Most identity systems still operate on a disclosure model.

• The service asks for data.

• The user provides it.

• The service stores it.

The organisation spends years securing information it probably never really needed in the first place. That architecture creates predictable problems:

• duplicated identity records;

• large centralised databases;

• unnecessary retention;

• insider access;

• breach exposure;

• cross-service correlation; and

• secondary use of personal data.

ZKPs use a different method, instead of repeatedly transmitting identity attributes, the user can present cryptographic evidence that a requirement has been satisfied.

• The service receives less information.

• Less information needs to be stored.

• Less information can be breached.

• That identity risk isn’t gone.

Metadata, device fingerprinting, transaction patterns and poorly designed identifiers can still allow users to be tracked. A privacy-preserving proof wrapped inside a surveillance-heavy system is still a surveillance-heavy system. But ZKPs make data minimisation enforceable at the protocol level. It’s not just a policy promise.

Why ZKPs Matter Beyond Identity

ZKPs can also be used to prove the integrity of computation. A service may perform a calculation and return both the result and a cryptographic proof that it followed the rules. The service can support:

• verifiable cloud computation;

• confidential audits;

• private compliance checks;

• supply-chain validation;

• financial solvency proofs;

• decentralised systems;

• machine-learning verification; and

• policy enforcement across organisations.

• A company could prove that it meets a regulatory threshold without showing every transaction.

• A cloud provider could prove that a defined operation was performed correctly.

• An AI system could prove that an approved model version and policy set were used.

• A user could prove authorisation without revealing a reusable identifier.

The common principle is the same: Trust the proof rather than demanding all the underlying data.

Proof Isn’t Free

ZKPs can reduce disclosure at a computational cost. Creating a proof may need more work than verifying it. The prover may need to change the computation into a constraint system, generate cryptographic commitments and process a large number of mathematical operations.

Depending on the proof system and circuit, proving may need:

• significant CPU or GPU time;

• large amounts of memory;

• specialised libraries;

• careful circuit optimisation;

• precomputation;

• parallel execution; and

• hardware acceleration.

Verification is supposed to be cheaper. That asymmetry is useful because one party can generate a proof that others can verify easily. But it also creates practical design questions:

Where is the proof generated?

• On the user’s device?

• Inside secure infrastructure?

• By the service performing the computation?

• Does the prover have enough memory and power?

• How much latency is acceptable?

• Can the proof be generated for every transaction, or must operations be aggregated?

ZKP and FHE Solve Different Halves of the Problem

FHE and ZKP become very interesting when considered together.

FHE can allow a service to compute over encrypted data without seeing it.

ZKP can then show that the encrypted computation was done correctly or that the inputs satisfied a particular set of rules. Let’s consider a confidential eligibility system.

FHE could calculate a result for encrypted financial or medical data.

ZKP could prove that:

• the correct algorithm was used;

• the data came from authorised sources;

• the calculation satisfied the agreed rules; and

• the result falls within an approved category.

• The service may never need to see the underlying values.

• The user may not need to expose the evidence.

• The verifier doesn’t need to rely entirely on institutional trust.

• This doesn’t make the system automatically private or secure.

• Key management, metadata, circuit design, software integrity, credential issuance and access control still matter.

Now it can replace a model based on disclosure and trust with one based on encrypted computation and verifiable claims.

Architecture Comes Before Proof

• What exactly needs to be proven?

• Who is making the claim?

• Who is verifying it?

• Which information must remain private?

• Which information can be public?

• Where does the witness come from?

• Why should the verifier trust that source?

• Can the proof be linked across transactions?

• What happens when a credential is revoked?

• How expensive is proof generation?

• Does the system require a trusted setup?

• What metadata remains exposed?

Without those answers, a ZKP can become just an expensive privacy label. The technology is powerful precisely because it can formalise trust. But formalising the wrong assumptions only makes the mistake mathematically consistent.

Proof Without Unnecessary Disclosure

The central value of zero knowledge isn’t secrecy for its own sake. It’s reducing the amount of information a system needs to collect, expose and trust. Most systems ask for far more data than needed. And copying information has historically been easier than proving facts about it. ZKP changes that.

• They separate the claim from the evidence.

• Allow verification without disclosure.

And they allow systems to establish that rules were followed without exposing everything. FHE keeps data encrypted while it’s being used. ZKP proves that a claim or computation is valid without exposing it. Together, they point towards a different security architecture. One where trust is reduced, data is minimised and verification doesn’t need visibility.

In the next article, we’ll look at why FHE and ZKPs require more than stronger encryption.