How far down the supply chain

On September 25 Shared Services Canada opened its Invitation to Qualify for sovereign cloud, CS-SOVC-2026. After two extensions, the first intake closes October 28 at 23:59 Eastern.¹ Only companies that qualify get into the sovereign cloud solicitations that follow. Qualifying takes proof that the company is Canadian-owned and -controlled all the way up to its ultimate parent, plus a description of at least one cloud offering it sells today.² The day it opened the ITQ, SSC also posted an award notice for the first contract under its main public cloud solicitation. That one went to Amazon Web Services Canada in July and runs 300 months, to July 2051.³ The sovereign stream is “intended to complement, and not replace, existing cloud procurement approaches”,² and that framework is one of them.

The ITQ repeats the definition SSC settled on in March. Cloud services have to stay under the control of providers, “including their ultimate parent corporations”, that “are not subject to foreign laws permitting foreign governments to access or compel actions affecting Canada’s data or services without Canada’s prior written consent.”² When the request for information went out in August 2025, the same sentence said “obtain access to Canada’s data”. The words “compel actions” went in on March 3.^{4 5} Annex A turns that verb into something a company signs. Each respondent attests, for itself and every parent up to the ultimate one, that no foreign law would let a government, or “any other foreign entity or person”, “require, compel, or otherwise impose measures that could affect, interfere with, or discontinue the services”.

What the attestation reaches

Ownership is a reasonable first test for a provider that holds Canada’s data, and it reaches what residency can’t. An earlier note made that case at length; M1 settles it in one row of a table, through the parent.

But the attestation stops at the parent. SSC has answered suppliers’ questions twice, most recently in a list posted October 25. Asked whether the attestation reaches past the parent chain, SSC said it “does not extend to non-parent infrastructure providers, subcontractors, sub-processors, or other suppliers.” Another answer says it more broadly: “The ITQ does not assess the sovereign or foreign attributes of the technologies used to deliver a cloud service.”⁶

A supplier asked the supply chain question outright. “Will Canada consider vendor-controlled mechanisms, such as remote administration, licensing, activation, telemetry or software updates, when assessing whether a foreign entity could affect, interfere with or discontinue a service?” The ITQ “does not assess specific technical or operational mechanisms associated with third-party technologies”, SSC answered, and those considerations “will be addressed in future procurement processes.” Most of the answers around it end the same way.

On October 8 SSC told suppliers it’s examining four classified clouds, from Amazon Web Services, Microsoft Canada, Google Cloud and Oracle Cloud Infrastructure, and that it may contract qualified Canadian managed service providers to prepare, configure and maintain them.⁷ SSC’s answers add that all four already qualified under CS-IAAS-2024, the solicitation behind the July award.⁶ The ITQ says Canada “may also consider managed service providers that have unique access to such cloud service solutions, even where those solutions are owned by foreign entities. In such cases, the managed service provider will need to demonstrate full control over the technology and the delivery of services.”² M1 lands on the operator, then. The technology stays with whoever owns it, and what “full control” over it means is one of the things left for later.

What later will ask

Slide 11 of the webinar deck lists five objectives Canada says it’ll use “to evaluate how effectively vendors support Canada’s sovereignty objectives in future sovereign cloud procurements”.⁷ SSC’s answers to suppliers say they were “provided at a high level for information purposes”, so none of them binds anyone yet.⁶ SOV-1 is the ITQ’s own ground, ownership and jurisdiction. The other four are questions:

• SOV-2, operational: “Who and where are the people operating the core systems and exercising administrative control?”
• SOV-3, services: “How resilient are the services to interruption, including dependencies outside Canadian control?”
• SOV-4, technology: “Can critical technology and service components be sourced and operated domestically?”
• SOV-5, supply chain: “How far down the software and hardware supply chain can domestic autonomy be maintained?”

Underneath, the slide says Canada will assess how effectively each bidder “resists or mitigates foreign influence, extra-territorial requests, service interruption and export restriction”. M1 is the resisting half, done once, at the level of the company; everything the company’s service runs on falls to the other verb.

The solicitations will also carry a supply chain integrity requirement “at a minimum of security profile Protected B Medium Integrity Medium Availability”.² That’s the profile the previous note read, now ITSP.10.033-01, with its SA-400 assessment of injury from external legal compulsion and its twelve supply chain items. SSC’s answers say there’s “no relationship” between M1 and that requirement, and that “SCI is not assessed as part of the ITQ.”⁶

How far down

Take SOV-5 down the software side of a classified cloud service, or of a Protected B system a department deploys onto one. Base images and operating system packages come out of public registries. The platform is assembled from upstream projects with maintainers all over the world. Builds run on hosted build services; artifacts are signed through signing services and checked against a public transparency log. Licences activate against a vendor’s licence server, and the scanners read a vulnerability feed someone else publishes. Then there’s the provider’s own update channel for the platform, which on a managed service is the one that reaches everything. Very little of that is domestic, and most of it can’t be. Nobody is going to re-host the open-source commons in Canada, and a Canadian fork would just be one more upstream to keep patched.

At the UN on September 22 the Prime Minister, talking about the partnership with Europe, said: “Our goal is not self-sufficiency. It is collective resilience.”⁸ For software, autonomy runs out a layer or two down, and the work is in what an operator does about every link below that.

The ITQ’s own verbs sort those links. A link that could “discontinue the services” is an availability problem, and for anything that can be copied the answer is familiar. Keep the images, packages and feeds inside the boundary, and an interruption costs you time. A licence that phones home can’t be kept that way, and neither can the provider’s platform; that’s SOV-3’s question. Integrity is harder. If a link could “affect” what the service does, a stockpile won’t help, since the copy you’re holding might be the altered one. The first note in this series sorted a delivery chain the same way.

What mitigation looks like

Integrity can be mitigated without owning the technology. Provenance travels with the artifact, so the record of where a build came from doesn’t depend on an account at the provider staying open. Verification happens inside the enclave against keys the operator holds, without calling out to anyone, and each deployment leaves dated evidence the operator keeps for the assessor.

Built that way, a foreign-held link that gets compelled can still cost the system freshness. An update doesn’t arrive; a feed goes stale. Whatever it does deliver gets checked against the operator’s keys before it’s deployed, and the record shows what came in and where it says it was built. The check only knows what the operator vouched for, so a poisoned base image the operator signed in good faith goes through, and the record is how someone traces it afterwards. The provider’s own platform, and the update channel that reaches everything, sit underneath the operator’s check and never pass through it. So for a Canadian operator running a stack it doesn’t own, this answers the part of “full control over the technology” that covers what gets deployed. SSC hasn’t said how it’ll score SOV-5, or whether “full control” gets a definition before the solicitations, and the managed service providers qualifying now will want to know.

Before the solicitations

The first intake closes October 28, and SSC says each respondent hears its result within 20 working days. The next cut-off is January 31. Whatever comes after will ask the slide 11 questions in some form, and a respondent can answer them for its own chain now. That means a list of every link from the base image to the update channel, marked two ways: whether it can be held in Canada, and if it can’t, whether what it delivers can be checked without asking its owner. Under the Protected B profile, the same list is where an SA-400 assessment starts.

Northfleet is a Canadian-incorporated vendor 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 under their own keys. Northfleet holds no customer data and no customer signing keys. Every release Northfleet ships carries provenance binding it to the source it was built from, which the customer can check without Northfleet’s participation. The architecture assumes the vendor can be compromised or compelled. That assumption is what stops a compelled vendor from silently changing what runs in the cluster.

If you’re qualifying under the ITQ, or running a stack you don’t own, and want to take slide 11 down your own chain, get in touch.