The CLOUD Act gap in Canadian defence infrastructure

12 min read Original article ↗

Every meaningful managed Kubernetes service available to Canadian buyers (Red Hat OpenShift, AWS EKS and GovCloud, Azure AKS and Government, Google GKE) is operated by a US-incorporated vendor. Every customer workload running on one of those services is therefore exposed to the 2018 US CLOUD Act regardless of physical data residency in Canada. That posture was a tolerated technical compromise until February 2026, when Canada’s Defence Industrial Strategy named Secure Cloud as a sovereign capability and committed 70% of defence procurement to Canadian-controlled firms. What was previously an architectural footnote is now a procurement-evaluation criterion.

“Operated by” carries a specific procurement meaning. The vendor’s engineers hold administrative access to the control plane, ship updates to the running software, debug incidents under their own corporate governance, and answer to the regulators of the country where the vendor is incorporated. Each of the four services named above (OpenShift, EKS and GovCloud, AKS and Government, GKE) meets that definition with a US-incorporated vendor in every case.

The hyperscaler “government” variants are the most common procurement misunderstanding. AWS GovCloud and Azure Government are partitioned environments with stricter access controls, US-personnel requirements, and FedRAMP High accreditation. They are still operated by US-incorporated subsidiaries of US-incorporated parent companies.12 The partition addresses US federal compliance requirements; it doesn’t relocate the vendor outside US legal authority. A Canadian customer signing a contract for either gets the partition’s operational controls and the parent’s jurisdictional reach.

Red Hat OpenShift presents a different surface. Red Hat ships software the customer installs on infrastructure the customer operates, which makes “operated by” ambiguous at first read. The ambiguity resolves on inspection. Red Hat is a wholly-owned subsidiary of IBM, incorporated in Delaware, governed by US law.3 The OpenShift trust path, including the signing keys for the container images that compose the platform itself, resolves to a US-incorporated entity. The customer running OpenShift in their own data centre still inherits Red Hat’s jurisdictional posture for everything they pull from Red Hat’s registries.

A prime that runs upstream Kubernetes on its own Canadian bare metal is having a different conversation than a prime buying any of these services. That conversation is less common at the scale Canadian primes operate, and is addressed later in this piece.

What the CLOUD Act actually compels

The 2018 US CLOUD Act (codified as 18 U.S.C. §2713) is short and direct. It extends US warrant authority to compel US-incorporated providers of remote-computing services (the statutory category that covers cloud and platform vendors) to produce data in their possession, custody, or control, regardless of where the data is physically stored. The provider’s data centre might be in Toronto or Montréal; the warrant is served at the provider’s US headquarters and operates against the legal entity, not against the physical location of the storage. The statute makes no exception for foreign-citizen customers, foreign-government contracts, or contractual data-residency commitments.

A Canadian defence prime running classified workloads on a US-incorporated cloud platform is therefore one US warrant away from compelled disclosure of those workloads. The disclosure can be served on the provider with no notification to the Canadian customer or to any Canadian authority, and the provider can be obligated under a gag order to never disclose that the request occurred. Whether the disclosure has happened to any Canadian customer is, by design, unknowable from public records.

The most direct confirmation of the exposure came from Microsoft France in June 2025. Anton Carniaux, Microsoft France’s director of public and legal affairs, testified under oath at the French Senate. Asked whether Microsoft could guarantee that data of French customers stored in EU regions wouldn’t be transferred to US authorities under the CLOUD Act, his answer was “Non, je ne peux pas le garantir.” No, I cannot guarantee that.4

The Office of the Privacy Commissioner of Canada has held the corresponding position for over a decade: “no contract, no matter how well crafted, can override the laws of the foreign jurisdiction.”5 The Canadian Bar Association’s submission on the US-Canada CLOUD Act agreement recommends that any enabling legislation include mandatory Canadian-court review of US requests, an implicit acknowledgement that current arrangements lack it.6 Citizen Lab’s 2025 analysis of the cross-border surveillance regime reaches the same destination from the constitutional-rights angle.7

Canadian region is not a defence

The natural procurement response is “we’ll use the Canadian region.” Microsoft Azure operates regions in Toronto and Quebec City. AWS operates a Canada Central region in Montréal. Google Cloud operates a Montréal region. Each region is a physical cluster of data centres inside Canadian borders, often paired with contractual commitments that customer data at rest won’t leave the country. None of those facts changes the vendor’s legal jurisdiction.

Microsoft’s December 2025 announcement of $19 billion in Canadian investment, of which $7.5 billion goes to expanded Azure regions in Toronto and Quebec, was framed under the explicit banner of “digital sovereignty.”8 Six months earlier the same company’s French subsidiary admitted under oath that customer data in EU regions can’t be guaranteed against US CLOUD Act compulsion.4 The two statements describe the same operational structure. The marketing language and the sworn testimony arrive at different conclusions because they answer different questions: where the data sits versus whose law applies to the entity that holds it.

Residency is a question about geography, and jurisdiction is a question about law. The CLOUD Act operates on jurisdiction. A “Canadian region” answer addresses only the geography question, and addresses it well; the question of which country’s law applies to the legal entity holding the data is left untouched. “If you don’t control the software, you don’t control the data.”9 The procurement evaluation that stops at “data resides in Canada” is evaluating the wrong dimension.

The deeper distinction (Canadian-jurisdictional versus Canadian-hosted, and the full surface where the two diverge) is the subject of a later piece in this series.

A Canadian defence prime that runs upstream Kubernetes on its own Canadian bare metal, in a Canadian-operated data centre, with Canadian-cleared engineering staff, has done real work to reduce jurisdictional exposure. The decision is less common at the operational scale Canadian primes typically work at, but it is the correct decision for the workloads that demand it. This section is precise about what it accomplishes and what it leaves open.

What bare metal accomplishes is closing the data-holder exposure that this essay has described so far. There’s no managed-service vendor sitting between the prime and the workload, so there’s no US-incorporated entity that a US warrant can compel to disclose what’s in the cluster. The load-bearing concern of the CLOUD Act argument is answered.

The procurement question that opens in its place isn’t jurisdictional. It asks whether the prime can prove what was deployed into the cluster, prove it to an accreditor, and prove it without trusting any foreign-jurisdictional vendor in the proof chain. Software bills of materials, signed attestations, tamper-evident audit logs, customer-owned signing keys: these are the procurement-evaluation items the question resolves to. ITSG-33 evidence collection and CPCSC certification evaluate against this question, not the first one.

A later essay in this corpus walks the supply-chain-provability question in procurement-evaluation form.

The Defence Industrial Strategy turned the posture into a procurement problem

On February 17, 2026, the Government of Canada launched its first Defence Industrial Strategy. The headline numbers are large: $81.8 billion in additional defence investment by 2030, $180 billion in ten-year procurement opportunity, $290 billion in capital-investment opportunity, and a $125 billion downstream economic-benefit target by 2035.10 More consequential for software vendors is the procurement-preference architecture inside those numbers. Of the strategy’s procurement target, 70% is reserved for Canadian-controlled firms.10 Ten “sovereign capability areas” are named. One of those areas, “Digital Systems”, expands to name Secure Cloud, Integrated Command and Control, and High-Assurance Communications Equipment as priority capabilities the Strategy commits Canada to building.11 Multinational suppliers are required to do a greater percentage of their work in Canada and with Canadian-controlled firms, and to reduce customer reliance on ongoing foreign software updates, intellectual property, and schematics.11

The financial machinery for that procurement preference is visible. BDC’s Defence Platform expanded to $6 billion in March 2026, with a $300 million StrongNorth Fund dedicated to dual-use deep tech.12 Canada was confirmed in April 2026 as the host country for the Defence, Security and Resilience Bank, a multilateral defence-financing institution stood up by Canada and allied partners.13 Both are procurement-adjacent capital pools that signal which firms the strategy expects defence customers to evaluate.

The procurement gate is operational. The Canadian Program for Cyber Security Certification opened Level 1 self-assessment on April 1, 2026, required in select defence contracts beginning summer 2026, with Level 2 assessments scheduled for spring 2027 and Level 3 for “highest risk scenarios, weapon systems, critical infrastructure, sensitive Five Eyes information.”14 Level 3 will be assessed by the Government of Canada itself. A vendor whose incorporation, jurisdiction, or supply chain fails procurement scrutiny does not reach Level 3, regardless of technical merit.

Together, these three elements (policy commitment, financial infrastructure, certification gate) make foreign-jurisdictional vendor selection a procurement liability that a Canadian defence customer cannot defend in a contracting review.

Three questions every Canadian procurement evaluation can now ask

The Defence Industrial Strategy makes the evaluation framework clearer than it was a year ago. The three questions below are the concrete form of that framework. Each is derived from one of the surfaces this essay walked through. None of the three is sufficient on its own; together they cover the structural compatibility of a vendor with the procurement environment the DIS creates.

  1. Where is the vendor incorporated, and which country’s legal authority applies to the vendor’s corporate operations? This is the data-holder question. The CLOUD Act and equivalent foreign-jurisdictional regimes operate on the legal entity, not on the physical location of the data. A vendor incorporated in Canada and not operating a US-incorporated subsidiary that holds the customer relationship answers this question; a vendor incorporated anywhere else doesn’t.

  2. Where does the cryptographic trust chain for the vendor’s artifacts resolve, and can the customer verify those artifacts without trusting any foreign-jurisdictional service? This is the supply-chain-provability question. The signing certificate authority, the transparency log, and the trust root must all sit in entities the customer can audit independently. A vendor whose verification path requires reaching a US-incorporated public transparency log or a US-incorporated public certificate authority does not answer this question, even if the runtime is Canadian-operated.

  3. Does the vendor’s product require ongoing connectivity to foreign-incorporated services to function in classified environments? This is the air-gap-correctness question. Software updates that phone home, license-validation pings, telemetry beacons, identity-provider lookups, and secrets-backend calls all open exfiltration paths and procurement liabilities a classified deployment will not tolerate. A vendor whose product cannot be operated in a fully air-gapped configuration, with verification done using only cryptographic tooling the customer already owns, does not answer this question.

All three are necessary, and no single one settles the evaluation. A complete procurement checklist, with the specific RFP language, the evidence each item demands, and the rubric for evaluating answers, is the subject of the closing essay in this series. The three above are the first questions to ask today, and they are the three questions any RFP for the sovereign supply chain into a Canadian classified Kubernetes deployment should answer in plain language.

The procurement question this strategy is still answering is who supplies the sovereign supply chain into Canada’s classified Kubernetes. The CLOUD Act argument and the Defence Industrial Strategy together have made foreign-jurisdictional vendor selection a procurement liability that primes can’t defend in a contracting review. The three questions above are concrete language for the evaluation. The vendors that answer those three questions are the vendors the strategy expects defence customers to buy.

Northfleet is a Canadian-incorporated vendor, outside US CLOUD Act reach, building the sovereign supply chain that wraps a customer-operated classified cluster: a deploy-time bundle protocol, attestation chain, and tamper-evident audit trail. The customer’s cleared engineering teams operate the cluster on Canadian-jurisdictional infrastructure. Northfleet supplies the trust path between build and apply, signed by the customer’s own keys and verified with stock cryptographic tools the customer already owns.

The CLOUD Act opened the gap, and the Defence Industrial Strategy turned it into a procurement problem. A vendor that does not pass the three questions above is not procurable for classified workloads under this strategy.

  1. AWS GovCloud (US) is operated by Amazon Web Services, Inc., a US-incorporated subsidiary of Amazon.com, Inc. AWS documents that GovCloud regions are “administered exclusively by AWS personnel that are U.S. citizens only.” https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/whatis.html. ↩

  2. Azure Government is operated by Microsoft Corporation, US-incorporated, governed by US law. Microsoft documents US-person personnel requirements and FedRAMP High accreditation for the partition. https://learn.microsoft.com/en-us/azure/azure-government/documentation-government-welcome. ↩

  3. Red Hat, Inc. became a wholly-owned subsidiary of IBM Corporation on July 9, 2019. Both companies are Delaware-incorporated and governed by US law. https://www.ibm.com/investor/news/ibm-completes-acquisition-of-red-hat. ↩

  4. Anton Carniaux, director of public and legal affairs at Microsoft France, testifying under oath before the French Senate Commission of Inquiry, June 10 / 18 2025. Coverage: https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee. ↩ ↩2

  5. Office of the Privacy Commissioner of Canada, standing guidance on cloud computing. https://www.priv.gc.ca/en/privacy-topics/employers-and-employees/outsourcing/02_05_d_57_os_01/. ↩

  6. Canadian Bar Association, submission on the proposed Canada-US CLOUD Act agreement. https://cba.org/our-impact/submissions/cloud-act-agreement/. ↩

  7. Khoo and Robertson, “Canada-US Cross-Border Surveillance Negotiations Raise Constitutional and Human Rights Whirlwind under US CLOUD Act,” Citizen Lab, University of Toronto, February 24 2025. https://citizenlab.ca/2025/02/canada-us-cross-border-surveillance-cloud-act/. ↩

  8. Microsoft, “Microsoft deepens its commitment to Canada with landmark $19 billion AI investment,” December 9 2025. https://blogs.microsoft.com/on-the-issues/2025/12/09/microsoft-deepens-its-commitment-to-canada-with-landmark-19b-ai-investment/. ↩

  9. Blayne Haggart, Brock University, “Microsoft’s investment in Canadian AI infrastructure puts data at risk, Brock expert says,” December 16, 2025. https://brocku.ca/media-room/2025/12/16/microsofts-investment-in-canadian-ai-infrastructure-puts-data-at-risk-brock-expert/. ↩

  10. Prime Minister of Canada, “Prime Minister Carney launches Canada’s first Defence Industrial Strategy,” February 17, 2026. https://www.pm.gc.ca/en/news/news-releases/2026/02/17/prime-minister-carney-launches-canadas-first-defence-industrial. ↩ ↩2

  11. Borden Ladner Gervais, “How Canada’s Defence Industrial Strategy reshapes defence acquisition and procurement law,” February 2026. https://www.blg.com/en/insights/2026/02/how-canadas-defence-industrial-strategy-reshapes-defence-acquisition-and-procurement-law. ↩ ↩2

  12. BDC, “BDC boosts Defence Platform after providing financing; names StrongNorth Fund leader,” March 12, 2026. https://www.bdc.ca/en/about/mediaroom/news-releases/bdc-boosts-defence-platform-after-providing-financing-names-strong-northfund-leader. ↩

  13. Department of Finance Canada, “Canada welcomes progress towards the establishment of the Defence, Security and Resilience Bank and hosting its headquarters,” April 29, 2026. https://www.canada.ca/en/department-finance/news/2026/04/canada-welcomes-progress-towards-the-establishment-of-the-defence-security-and-resilience-bank-and-hosting-its-headquarters.html. ↩

  14. Public Services and Procurement Canada, “Government of Canada introduces Level 1 of the Canadian Program for Cyber Security Certification,” April 2026. https://www.canada.ca/en/public-services-procurement/news/2026/04/government-of-canada-introduces-level-1-of-canadian-program-for-cyber-security-certification.html. ↩