Encryption Isn't Enough. Canada Now Says So In Writing.

Pillar 03 · Residency

How SkyeConnex measures against CAN/DGSI 100-8:2026

Standards usually describe outcomes and leave the mechanism to the vendor. That's how sovereignty theatre survives an audit. You promise the outcome, you document the promise, you pass.

The second edition of CAN/DGSI 100-8, the National Standard of Canada for digital sovereignty, published this June, does something I didn't expect. Clause 4.3.2 says encryption is not a sufficient mitigation where foreign legal or administrative mechanisms could compel access to the data or the keys.

Or the keys.

A national standard has written down the thing most of this industry still won't say out loud. A key you can be ordered to produce isn't a control.

Clause 4.3.3 follows it through. Control over key management, access controls and monitoring has to sit under the organization's direct authority, and it can't be subject to unilateral override by a third party or a foreign entity. Annex B is normative, names the U.S. CLOUD Act outright, and requires you to demonstrate that no foreign entity, parent or affiliate holds authority, direct or indirect, to compel access.

Worth noting what changed between editions. The first one was called Framework for Geo-Residency and Sovereignty. The second dropped geo-residency from the title. Technical Committee 1 arrived at the position we built the company on: residency is a location, sovereignty is a key hierarchy.

We read the whole document against our own architecture. Some of it was uncomfortable. Most of it wasn't.

Where we conform

4.3.2 and 4.3.3, compelled access to data or keys.

This is the clause that separates architectures from assurances, and it's the one that disqualifies most of the market on sight.

Raidr.cloud encrypts client-side before anything reaches our infrastructure, then applies RS(5,2) erasure coding across independent jurisdictions. No shard location holds a reconstructable copy. No operator holds a key that produces plaintext on demand, and that includes us.

The point isn't that we'd refuse a lawful order. It's that complying with one produces nothing useful. That's a property of the key hierarchy, not a commitment in a contract, which means it survives a change of management, an acquisition, or a jurisdiction changing its mind.

4.2.2 and 4.2.3, classification and lineage across custody chains.

The standard wants documented evidence of origin, lineage, transformation history and authority-for-use, applied at every transfer point in a multi-party chain rather than just at the front door. That last part is the sharp bit and most people will skim past it.

We handle it cryptographically instead of documentarily. MMR manifests and Ed25519 signing produce tamper-evident lineage at each custody event. The standard asks whether you can produce documentation. We produce proof. An assessor will understand the difference in evidentiary weight even if the standard doesn't distinguish between them.

4.4.1, zero-trust and end-to-end security for critical systems.

Satisfied by construction rather than configuration. There's no privileged internal path to plaintext for us to lock down, because nobody ever built one.

4.7.4, AI decisions logged and auditable, model providers barred from learning from sensitive operational data.

SkyeGXU predates the clause but reads like it was written for it. Attested runtime, federated fine-tuning, no provider retention. When the standard says external model providers shall not derive value from or learn from sensitive operational data without documented authorization, it's describing the default posture of a sovereign AI substrate and the precise opposite of the default posture of every commercial model API you can buy today.

4.1.5, multi-principal pass-through.

If you run infrastructure on behalf of multiple principals, you have to document the chain of sovereignty obligations for each one and apply governance at individual data-flow level rather than platform level. Per-conversation HKDF-derived keys make each principal's flow cryptographically distinct, and crypto-shredding operates at that same granularity.

Any OEM partner reselling a sovereign platform inherits this clause the day the contract is signed. Most haven't read it yet.

Where we go past it

Clause 4.1.4 is the most forward-looking sentence in the document. You can interoperate with foreign systems and still hold effective sovereignty, provided Canadian control over cryptographic services, portability, auditability and bounded interoperability is preserved and demonstrable.

That's a mechanism test. We pass it.

Then Annex A, which is informative rather than normative, defines the strongest posture as internalization. No external access, no foreign cloud dependency, providers under a single domestic jurisdiction, data stored and processed inside the border. Cross-border distribution shows up as a risk indicator.

So an architecture that satisfies 4.3.2 by construction, sharded across independent jurisdictions precisely so no single party can reconstruct anything, scores worse on the assessment instrument than one that satisfies it by owning the racks.

Both clear the clause. Only one of them is affordable to an organization that can't build its own data centres, which is nearly all of them.

I don't read this as a flaw in the standard. Annex A is informative, 4.1.4 is normative, and the normative text is already right. The scorecard just hasn't caught up to the framework it's scoring, and that's a reasonable thing to raise in the next review cycle. Sovereignty by insourcing is a legitimate answer. It isn't the only one.

The broader gap is evidentiary. Conformance across this standard is demonstrated through documentation, attestation and audit access. Correct requirements for a technology-agnostic standard, and the weakest form of evidence available. Where 100-8 asks for a documented chain we produce a signed one. Where it asks for demonstrable control over cryptographic services, the demonstration is structural. You can conform to this standard with a binder. We think the binder should be a proof.

What we're not claiming

Clause 4.1.2 requires organizations to identify exclusions and formally accept the residual risk. Fine. A conformance claim that admits nothing isn't a conformance claim.

Our user master keys are system-generated. We store no reconstructable key material and the wrapping key is derived rather than persisted, but generation happens on our infrastructure and there's a moment where the platform handles plaintext key material. A compelled-access order doesn't need historical keys. It needs prospective instrumentation of the generation path.

We attest that path today. We're moving to fully client-side derivation, which eliminates the residual instead of mitigating it. Until that ships it's a documented risk acceptance and I'm not going to describe it as anything else. Anyone telling you their sovereign platform carries zero residual exposure has either closed this specific gap or hasn't gone looking for it.

Second thing. 100-8 normatively references CAN/DGSI 100-1, 100-2 and 100-9, and their content constitutes requirements of 100-8. Full conformance means conformance across all four. Our assessment against the referenced parts is underway and isn't finished. We'll publish it when it is.

What procurement should do with this

Ask one question before the demo and before anyone talks about pricing.

Can you, under any lawful order, in any jurisdiction where you operate or hold a corporate affiliate, produce our plaintext?

If the answer is yes, then residency doesn't fix it, contractual commitments don't fix it, and a sovereign-branded cloud region definitely doesn't fix it. There's now a National Standard of Canada that says so in normative language.

Most vendors will respond to that question by describing their controls. That isn't an answer. It's a change of subject, and you should treat it as one.

The standard is a floor. Canada needed a floor, and TC 1 built a better one than most jurisdictions have managed. But 4.1.4 already tells you where the ceiling is, and it's architectural.

Sovereignty by architecture, not by promise.

Bias declaration: I'm the founder and CEO of SkyeConnex, which sells sovereign data infrastructure. This is an assessment of our own conformance against a standard I have a commercial interest in seeing read strictly. Weigh it accordingly, and go read the standard yourself. DGSI publishes it at no cost.