Technical analysis

Why the Italian public cloud does not deliver digital sovereignty

Encryption and confidential computing are real, useful security measures. They are also, on their own, unable to deliver sovereignty over a cloud controlled from another jurisdiction — and the French cyber-security agency says so in writing.

Every statement above is documented below, with a link to the primary source and, where the source is a file, an archived copy. A reader who wants to check rather than believe should start from how to verify this analysis.

The programme's own strongest defence, and why it does not hold

Confronted with the sovereignty question, the Italian public cloud programme answers with two technical measures, and they are the ones it puts forward first. It is worth stating them at their strongest, because both are real.

Source: PSN, Secure Public Cloud Azure user manual, ed. 04/04/2025 (PDF, 64 pp.) · services with Cloud Service Providers page

Taken together, these two would be a serious answer: the keys are outside the provider's hands, and the data is unreadable even while it is being computed on. If that held, the jurisdictional question would largely dissolve.

The technical reasons behind these four sentences — why a datum must be in the clear to be processed, why external key custody cannot prevent compelled use, and why attestation verifies software rather than location — are set out in Part II. A reader who accepts the four quotations can go straight to the table of the five offerings.

What the National Strategic Hub is, and what it promises

The Polo Strategico Nazionale is the infrastructure on which Italian public administrations are moving their systems, financed with European recovery funds. It exists to bring into a few supervised facilities the servers scattered across thousands of public bodies.

But the programme is not presented only as consolidation. Its own pages promise that public administrations will access services “in full security, autonomy and sovereignty”. This page examines that second word — because it is the one that carries a legal meaning, and because in the programme's own documents it turns out to mean something else.

Source: PSN, Secure Public Cloud Azure user manual, ed. 04/04/2025, backup service section

Read precisely, this is not a definition of sovereignty — and that is the point. The passage sits in the section describing the backup service, and states that one of that service's two requirements is “related to data sovereignty”, satisfied by a monthly replica. Anyone objecting that this is simply a recovery-point objective would be right about the mechanism.

How to verify this analysis

This page is written to be checked, not believed. Every quotation is from a document we downloaded and read in full, not from secondary reporting. A security or infrastructure practitioner should be able to reproduce every finding independently, and this section says how.

The three conventions we use, and what they mean

Reproducing the two scans

The two quantitative findings on this page are full-text searches, and both can be re-run in a few minutes.

1. The 161 pages. Download the four documents linked in section 1 — the concession agreement, the guide to the convention, the technical specification of services and the user manual for the Azure tier — extract the text, and search for: CLOUD Act, extraterritorial, nazionalità, capogruppo, paese terzo, controllo societario, immunità, legge straniera.

   A methodological trap we fell into, and you will too. The text layer of the convention guide is extracted without spaces: a naive search for software di base returns zero, falsely. Normalise whitespace out of the extracted text before searching, or you will report absences that are not there.

2. The French catalogue. Download the official catalogue of qualified products and services linked in section 8 and search for Oracle, Microsoft, Amazon, AWS, Polo Strategico.

The evidentiary standard we hold ourselves to

These twelve rules govern what may and may not be concluded on this page. They are published so that a reader can check whether we have followed them.

1. A marketing page does not prove a technical property unless accompanied by specifications, an audit or a contractual clause.
2. A generic vendor document does not prove the concrete implementation inside this programme.
3. The absence of a word does not prove the absence of a rule.
4. The presence of a connection or a dependency does not prove access to content.
5. The ability to update software is relevant, but is distinct from the present ability to read data.
6. A qualification is not an absolute guarantee and must be described within its scope.
7. “Not documented” is not “non-existent”.
8. “Mitigated” is not “eliminated”.
9. “Technically possible” is neither “legally authorised” nor “actually occurred”.
10. “Legally orderable” is not “technically executable without further modification”.
11. Every temporal claim must carry its date.
12. Every comparison must state whether the objects compared are genuinely comparable.

Source manifest — files, sizes and hashes

Every file below has been archived in the project repository. The SHA-256 hash lets anyone confirm they are examining the same document we examined, and not a later revision.

The “161 pages” cited throughout refers to the four contractual and operational documents: 53 + 11 + 33 + 64. The remaining files in the manifest support specific findings and are cited where used.

Documents we have not read, and what they would change

The corpus examined is contractual and operational. It does not include the national cloud strategy documents, which are known to acknowledge the risk arising from non-EU legal systems. That acknowledgement is not in dispute here, and this page does not claim the question was never raised in Italy — on the contrary, Italy co-authored the European immunity criteria in 2021.

Where the sources are kept

Commercial pages change and PDFs are withdrawn. Every source file cited here has been archived in the project repository, so that the evidence does not depend on the continued availability of the vendors' websites. Links point to the original; the archived copy is the fallback.

Part I

1. Why this concerns Italy: the National Strategic Hub

The Italian public cloud programme — the Polo Strategico Nazionale, PSN — offers exactly these two measures as its protection, on the tier delivered from the hyperscalers' own public regions.

2. “PSN Managed” is two different architectures under one name

The Italian public cloud's most protected tier is presented as a single service. Its own page says otherwise, in one sentence:

“The service is based on two technologies: Google Assured Workload and Oracle Alloy.” — “These infrastructures are hosted in Italian regions or within Polo Strategico Nazionale Data Centres.”

Source: PSN, PSN Managed Public Cloud · service price list, 04/2026 · guide to the convention, 08/2025

That “or” carries the whole weight. These are not two suppliers within one architecture: they are two opposite architectures, and only one of them is inside PSN's own data centres.

PSN's own price list confirms both halves: on the Google side it lists a line item called “Sovereign Controls”, described as the ability to “set policies within GCP”. Sovereignty as a price-list item, and as a policy setting.

3. The five offerings, side by side

The first column is the benchmark: the only one of the five that holds a sovereignty qualification. Everything to its right does not.

Source: Google, Italy Data Boundary by PSN · France Data Boundary by S3NS · PSN price list 04/2026

4. The comparison, requirement by requirement

The Italian public cloud is delivered in three tiers, with three very different levels of control — all promoted under the same word. This table places them against the requirements that the French framework actually measures. Every cell about PSN comes from documents we downloaded and read in full: the concession agreement, the guide to the convention, the technical specification of services and the user manual for the Azure tier — 161 pages.

On method. Where a cell says “not documented” we mean exactly that: we read the documents and did not find it — which is different from asserting it does not exist. Where a cell says “zero occurrences”, we ran a full-text search across all four documents and state the result. The distinction is deliberate.

5. Why France is ahead — and it is not the reason usually given

The real difference is not in the purity of the providers. It is that France wrote a requirement that can be measured, and Italy did not write one at all. Three checks, each of which is either satisfied or not: where is the company established, who controls its capital, from where is the service administered.

That is the whole gap, and it is not a gap in technology, budget or engineering skill. Italy has excellent data centres, competent operators and a real consolidation programme. What it does not have is a sentence in a binding document saying what a provider must be in order to hold the state's most sensitive data. France wrote that sentence. It cost nothing to write. It changed the market.

And there is a detail that makes the comparison sharper still. Italy did not fail to think of this. In 2021 Italy co-authored, with France, Germany and Spain, the European proposal that would have introduced immunity from foreign law into the Union's cloud certification. Those requirements were removed in March 2024. Italy asked for the rule in Brussels — and in the same five years never wrote it at home, in the one instrument that depended on nobody else's vote.

6. Oracle Alloy, in Oracle's own words

First, what must be credited. Alloy is a genuinely separate realm, with “its own control plane”, “physically and logically separated” from Oracle's public cloud. PSN states two regions, an exclusive network with no public internet, all data in its own data centres, encryption to national-authority specifications. On the infrastructure plane this is more than the Google Data Boundary offers.

And Oracle's own vocabulary for the partner is unambiguous: the operator “resells Oracle cloud services” and manages “the lifecycle of their cloud reselling business”. A telling detail: the Oracle post titled “Expanding Control & Flexibility” for Alloy operators is about multiple currencies and contract renewals. The control being expanded is commercial.

Source: Oracle, Alloy Overview · oracle.com/cloud/alloy · Alloy Business Reporting

Updates: who does what — stated precisely

Oracle's product page says the operator “can independently manage all standard operational tasks, such as basic patching and service updates”, and can rely on “Oracle teams for troubleshooting, nonstandard upgrades, outage resolution, and escalations”. Oracle's own VP for Dedicated Cloud sums it up: it is “effectively a whole OCI region that the partner operating team can independently manage, maintain and enhance, assisted by Oracle's upgrades and support”.

And what the operator gets over the changes themselves is a dashboard that “provides visibility into scheduled and completed OCI service changes, including emergency, mitigating, normal, and routine changes”. The verbs are observational throughout. No approval, no refusal, no deferral is documented.

Operator Access Control — real, and with three declared holes

Oracle offers a mechanism that is genuinely stronger than anything in the Google package: the customer can approve or deny access by Oracle employees, with time limits, full command logging and optional keystroke recording. It should be credited.

Source: Oracle, Operator Access Control — overview

The gate controls people. It does not control the automation that runs as root.

Two honest caveats. Operator Access Control is documented for Exadata Cloud@Customer and Compute Cloud@Customer, not for Alloy as a whole — PSN does use Exadata on the Alloy platform, so it is pertinent, but we do not claim it covers everything. And Oracle's strongest claim — “an Oracle Alloy Operator retains full control of the data and applications” — is a company statement we could not independently verify, of the same kind as Microsoft's “it has never happened”.

7. Amazon: Nitro Enclaves, and where the boundary actually is

Amazon is the fourth cloud service provider integrated into the Italian public cloud: PSN's own price list records the “integration of the 4th cloud service provider, AWS” in 2024, and describes Secure Public Cloud as based on the public services of “the hyperscalers Microsoft Azure, Google Cloud, AWS and Oracle, with regions on Italian territory”. So the question applies here too.

What Nitro Enclaves protects against — in AWS's own documentation

Nitro Enclaves is a genuinely well-built isolation technology. Its documented threat model is stated precisely, and it is worth reading twice:

“the data and applications inside the enclave cannot be accessed by the processes, applications, or users (root or admin) of the parent instance” — “The Nitro Hypervisor ensures that the parent instance has no access to the isolated vCPUs and memory of the enclave.”

Two further details from the same page. The enclave's life is bound to the instance: “Enclaves are active only while their parent instance is in the running state. If the parent instance is stopped or terminated, its enclaves are terminated.” Whoever controls the hypervisor controls the switch. And attestation is integrated with AWS KMS — the key service operated by AWS.

Source: AWS, What is Nitro Enclaves? · European digital sovereignty

The Nitro System: the strongest claim of the four providers, and what supports it

AWS states that the Nitro System “provides a strong physical and logical security boundary to enforce access restrictions so that nobody, including AWS employees, can access customer workloads or data”. It is the boldest claim any of the three makes, and it deserves to be met with evidence rather than contradiction.

The claim rests on an external audit of the Nitro System. That audit declares four limits of its own:

• the auditor was paid by AWS;
• it is a design review without testing — the auditor states it cannot attest that the implementation matches the design;
• it places outside its scope the EC2 control plane, the hypervisor, the firmware and the Nitro Cards;
• and it gives no assurance regarding future technical changes “chosen or compelled”.

An independent assessment not funded by AWS — Trail of Bits — puts the residual plainly: “you must completely trust AWS”.

The European structure, and what the commercial register says

On the corporate plane Amazon has done more than Google or Oracle in Italy, and it should be credited. AWS announced “a new parent company and three subsidiaries incorporated in Germany”, a management team of “EU citizens residing in the EU”, and an advisory board of four EU citizens “including at least one independent board member who is not affiliated with Amazon”, “legally obligated to act in the best interest of the AWS European Sovereign Cloud”. First region: Brandenburg.

We then looked the company up in the German commercial register, on two independent register services. The entry is Amtsgericht Potsdam, HRB 40853:

Source: German commercial register — Amtsgericht Potsdam, HRB 40853 · AWS governance announcement

The “new European parent company” is a pre-existing corporate vehicle, incorporated in 2021 and named Amazon Germany Holdco 1 GmbH until July 2025, with the statutory minimum capital of €25,000 and a corporate purpose of holding shares in other companies. And the managing director presented as the face of European governance ceased to hold the office within roughly six months.

And the sentence about it never having happened — better drafted than Microsoft's

Amazon's formulation is that since 2020 “there have been no data requests to AWS that resulted in the disclosure of content stored outside the USA from corporate or government customers to the US government”.

Three restrictions in a single line. It does not say there were no requests: it says none resulted in disclosure. It covers only content outside the United States. And only corporate or government customers. It is the same class of statement as the one examined in section 12 — and it is unverifiable for the same reason: the prohibition on saying so is itself the law.

Two further findings, stated for completeness. AWS's own announcement of the European Sovereign Cloud governance does not discuss the CLOUD Act at all: as with the Italian documents, the jurisdictional question is not answered weakly — it is not raised. And in the French agency's official catalogue of qualified products, Amazon and AWS appear zero times: neither qualified nor under assessment. Microsoft set up Bleu and entered assessment; Google set up S3NS and reached qualification. Amazon set up a German GmbH and did not take it to French qualification.

8. Who holds a sovereignty qualification, and who does not

The French agency publishes an official catalogue of qualified products and services. We read it in full — 130 pages — and searched it.

Source: ANSSI, catalogue of qualified products and services (PDF, 130 pp.) · list of providers under assessment

The sixteen offerings currently under assessment are equally telling: Adista, Bleu SAS, BLUE, Cegedim, Cloud Temple, Ecritel, Free Pro, GIP Mipih, ITS Integra, NumSpot, NRB, Orange Business, OVH, Prolival, Scaleway, Scalingo. Bleu — the Microsoft, Orange and Capgemini venture — is on that list. Oracle is not.

Microsoft, on the same road, set up Bleu — French controlling capital — and entered the assessment. Google set up S3NS with Thales and reached qualification, registered to Thales Cloud Sécurisé: the holder is the European controlling shareholder. Oracle announced a discussion.

9. The four vendors, and the point where they coincide

Each of the four providers used by the Italian public cloud has built something real, and each has drawn a security boundary. Read one at a time, the four look different. Read side by side, they exclude four different parties — and none of them excludes the same one.

9.1 How the mitigations themselves create the exposure

This is the part that is easy to miss, and it is the sharpest point on this page. The American statute reaches data in a provider's possession, custody or control. Each of these mitigations, in order to work, must create a new object — and that object ends up in exactly that condition.

9.2 What the four have in common when they speak

The pattern repeats in the language, too. Each vendor makes a strong statement, and each statement is true as written — and narrower than it sounds.

• Microsoft, under oath: “No, I cannot guarantee it, but, once again, this has never yet occurred.” The first half is the admission; the second half is unverifiable by design.
• Amazon: “no data requests that resulted in the disclosure of content stored outside the USA from corporate or government customers”. Three restrictions in one line.
• Oracle: “an Oracle Alloy Operator retains full control of the data and applications” — a company statement, alongside a documentation page that excludes root automation from the access controls.
• Google, in a document written for schools: “we carefully review each request”. Carefully review. Not: refuse.

And a silence they also share: in the official announcement of the AWS European Sovereign Cloud governance, in the Google data-boundary pages, and across 161 pages of Italian contractual documents, the American statute is not discussed at all. The jurisdictional question does not receive a weak answer. It is not put.

Part II — the technical measures

A technical answer to a legal question

The providers subject to the CLOUD Act — Microsoft, Google, Amazon — are not standing still. They have invested heavily, and visibly, in what is marketed as sovereignty: European legal entities, national regions, local operations staff, external key management, encrypted enclaves, dedicated boundaries for EU data. Some of these are serious pieces of engineering, built by competent people, and this page will credit them individually.

It is worth being clear about why this is happening. It is not a change of heart: it is a commercial response to a legal exposure. European public administrations began asking an awkward question, France wrote it into a certification framework, and the market produced answers. That is healthy — and it is also where the problem starts.

The table below is the map of this page. On the left, each measure and what it genuinely solves — because each one solves something real. On the right, the point at which it closes back on itself, with a link to the section that examines it. Read the right-hand column downwards and you will notice that the reason is always the same, expressed six different ways.

Read that threat model again: a hostile administrator. Not an outside hacker, not another tenant — the operator of the platform itself. That is exactly the situation a legal order under a foreign jurisdiction creates: a provider that is not malicious, but is compelled, and forbidden to say so.

10. A datum exists in three states. Encryption covers two.

This is the whole technical argument, and it fits in one table. It is not controversial: it is how computers work.

Whoever controls the hypervisor and the physical machine controls that moment. They can pause a virtual machine and dump its memory; they can snapshot it; they can read the CPU registers. None of this is exotic — it is ordinary platform administration, the same capability used every day for live migration, debugging and backup.

11. What confidential computing is — and what it genuinely achieves

Confidential computing is the industry's answer to the third row of that table. The processor creates an encrypted, isolated enclave — a Trusted Execution Environment — whose memory is encrypted with a key held in the silicon and, in principle, not available to the hypervisor. The main implementations are Intel TDX, AMD SEV-SNP and ARM CCA. A mechanism called remote attestation is supposed to let the customer verify, cryptographically, that their workload really is running inside such an enclave.

12. Four reasons it does not produce sovereignty

12.1 The threat model excludes precisely our threat

Confidential computing is designed against a curious operator and against neighbouring tenants. It is not designed against an operator who is determined, who controls the firmware and the provisioning chain, and who has time. ANSSI's conclusion on that scenario is the sentence at the top of this page. And ANSSI adds what to do instead: users “must avoid running on shared infrastructure operated by providers they cannot trust”.

A legal order does not make a provider malicious. It makes it compelled — which, in the threat model, is the same thing.

Note the word prerequisite. ANSSI does not present a trusted provider as an alternative to the technology: it presents it as the precondition without which the technology should not be relied upon at all. The order of operations is the opposite of the one implied by every “sovereign cloud” offering built on a provider under foreign control.

12.2 It does not meet the sovereignty standard — according to the agency that wrote the standard

Section 19.6 of SecNumCloud is the immunity clause: the requirement that a qualified provider be shielded from non-European extraterritorial law — through establishment, capital control and where the service is administered from. ANSSI wrote that clause. And ANSSI says confidential computing does not satisfy it.

This is the single most important fact on this page. Every argument that offers confidential computing as a substitute for jurisdictional requirements is answered, in advance, by the authority that invented those requirements.

12.3 Whoever operates the platform decides whether it is switched on

Confidential computing is not a property of the data. It is a configuration of the platform: a machine type to be selected, a feature to be enabled, firmware to be kept current. The entity that decides whether the enclave is active, for which workloads, and after which update, is the same entity the enclave is supposed to protect against.

This is why the wording used by providers matters so much. When a service is described as offering confidential computing “where enabled”, the protection has been made conditional — and the condition is not in the customer's hands.

12.4 A weakness found in how attestation is bound to the channel

The whole construction rests on remote attestation: without it, the customer has no way to know whether the enclave is real. The finding below does not invalidate attestation in general — it concerns a widely deployed way of binding attestation evidence to a TLS channel. In 2026 researchers led by Muhammad Usama Sardar (TU Dresden), with Mariam Moustafa and Tuomas Aura, showed that attestation performed inside the TLS handshake can be defeated by a relay attack. In The Register's summary of the work:

“A connection intended for one server can be silently redirected to a different, compromised machine running identical software, anywhere in the world, without the client ever knowing.”

The protocol checks the software's integrity, not its location. The vulnerability is tracked as CVE-2026-33697 (CVSS 7.5) and affected systems already in production. The research is published as Identity Crisis in Confidential Computing (AsiaCCS 2026) and Intra-handshake.fail (ESORICS 2026). And on whether it can be fixed, the paper concludes that full protection “may not be possible” within intra-handshake attestation as currently architected, without breaking properties of TLS 1.3.

12.5 And the marketing claim ANSSI corrects directly

ANSSI notes that the technology “is often presented by commercial providers as a solution to run remote workloads with the same level of confidentiality and integrity as a local setup, i.e. resistant to a physical attack” — and then states plainly: “physical attacks are explicitly out-of-scope of the security model”.

Whoever owns the building has physical access to the machines. The security model of confidential computing does not cover that, and says so.

13. And the keys? The same problem, one level down

The second technical answer usually offered is key management: the customer holds the encryption keys outside the provider's perimeter, typically in a hardware security module. The models have names — BYOK (bring your own key), HYOK and external key management — and they differ in how far the key stays away from the platform.

This too is real, and it too must be credited before it is criticised. Keys held in a customer-controlled HSM genuinely remove a class of exposure: stored blocks cannot be read by copying a disk, an operator cannot casually browse an archive, and a key can be revoked.

An analogy that survives scrutiny: you may keep the key to the safe in your own pocket, in another country. But if the safe is in someone else's building, and you ask their staff to open it and read the document out to you, the location of the key is not what determines who can read the document. External key management changes who has to be compelled, and how visibly. It does not change whether the plaintext exists inside the provider's perimeter.

That single sentence disposes of the argument that external key custody produces sovereignty. The key is yours; the hands that use it are not. Trust in the provider is not removed by the architecture — it is relocated from “trust them with the data” to “trust them to use the key only as instructed”. For a provider under a legal duty to comply with a foreign order, that is the same trust.

13.1 Where exactly BYOK stops working, step by step

It is worth following the key through an ordinary operation, because the point is not subtle once you see the sequence. Suppose an administration stores an encrypted database in the provider's cloud, with the key in its own hardware module.

The external key module is therefore not a barrier to reading the data. It is a switch that decides whether the system works at all. Its real power is to stop everything — which is a genuine and valuable property, and also a very blunt one: an administration cannot revoke its own key every time it suspects something, because revoking it means shutting down the service.

And ANSSI notes the same trap from the availability side: making the platform depend on an external key introduces a failure mode that “may result in an outage of the whole system”. Key externalisation buys a kill-switch and pays for it in fragility — but it does not buy confidentiality against the operator.

There is one genuine benefit worth naming, because it is the strongest argument on the other side: revoking an external key is observable. A customer who withdraws the key learns that access has stopped. That is a real property — but it is a property about future access, and it is useless against an acquisition that already happened and that a non-disclosure order forbids anyone from mentioning.

14. Why a technical measure cannot solve a legal problem

This is the part that is worth understanding even if you skip everything else on this page, and it takes about a minute.

Every security measure ever built assumes an adversary who has to get around something. Encryption assumes someone who does not have the key. Access control assumes someone without credentials. Network segregation assumes someone on the wrong side of a boundary. Confidential computing assumes someone who must break out of an enclave. All of these work by raising the cost of circumventing the rules of the system.

Source: Google, Monitor an Assured Workloads folder for violations

This is why the question “which technical measure protects against the CLOUD Act?” has no answer. It is like asking which lock protects against the landlord's own key. The lock is not defective. The question is aimed at the wrong layer.

And it explains why stacking measures does not help. Defence in depth multiplies the work of an attacker who must defeat each layer in turn. It does nothing when every layer is administered by the same entity, because that entity does not have to defeat them: it configures them.

15. The objections, one by one

These are the answers a provider or a public cloud programme can legitimately give. Each is reported in the strongest form we can give it, then answered. Where the objection is partly right, we say so.

16. Seven scenarios, graded

A binary verdict — sovereign or not sovereign — is easier to write and easier to refute. What follows is the same evidence organised by threat scenario, because the programme performs very differently across them. In three of the seven it performs well; that is not a concession, it is the result.

17. The best arguments in favour of the programme

An analysis that only presents the case against itself is not an analysis. What follows are the strongest arguments a competent defender of the Italian public cloud would make, stated as well as we can state them — and then answered with what the evidence supports, and only that.

18. What could be done — six measures, in order of feasibility

Criticism that offers no alternative is commentary. What follows is ordered by how soon each measure could be adopted, and every one of them rests on an instrument that already exists. None requires abandoning the current providers.

19. The conclusion, stated carefully

Presenting these measures as sovereignty is not a technical error. It is a category error: answering a legal question with an engineering artefact. The measures are a mitigation. They are not an immunity — and the agency that defined immunity has said so in writing.