SecurityBrief Canada - Technology news for CISOs & cybersecurity decision-makers
Canada
Canada's Digital Sovereignty Depends on Keeping Encryption Strong

Canada's Digital Sovereignty Depends on Keeping Encryption Strong

Wed, 21st Oct 2026 (Today)
Andre Duttmann
ANDRE DUTTMANN Founder and Executive Director Linux Association of Canada

For Canada to realize its ambition of building digital sovereignty, the systems we rely on every day must be secure. Canadian ownership, domestic hosting and local know-how are important. So are the assurances that we can trust our communications and infrastructure aren't being spied on.

Much of that trust depends on encryption. It safeguards financial transactions, your personal health data, work-related communication and government services. It can also be a lifeline for people experiencing harassment or domestic abuse. As such, conversations about encryption go well beyond the technology sector.

As Parliament debates Bill C-22, Canada needs a principle: Lawful access demands should never require adversaries' access, not secure end-to-end encryption, or prohibit providers from fix flaws.

Effective investigations and secure infrastructure are both in the public interest. Canadians deserve legislation that moves us forward together.

A legitimate purpose requires clear technical boundaries

Law enforcement and intelligence agencies have a right to investigate serious crime and national security threats. Sometimes digital evidence is essential to that effort. Providers need transparency and process in responding to lawfully issued requests.

Where it gets difficult is if the provider does not have access to the information it's asked for. Under end-to-end encryption the provider does not usually have the keys to the users' content. Demanding a new method of gaining access to that content may alter the security properties of the service.

A legal right is created by an authorization. An authorization does not by itself ensure the feasibility of an access means.

It's a distinction that needs to be made as the argument continues. Something implemented for a specific investigation may add extra code, credentials or privileges that need to be guarded. We need to consider the security impact of that, even if no malice was intended.

Imagine a Canadian organisation selecting a secure messaging service to share sensitive work. Whether that organisation evaluates the provider based on its being unable to read message content. If a new requirement mandates the provider creating an alternate access channel, this organisation has to understand how that increases its own level of exposure. And so the concern remains, whether that organisation is a business, or a community group, or a public institution.

Such is why, if technical review is to be done at all, it must be conducted over the whole system. A requirement could be narrowly defined, but still be dependent on common infrastructure or shared code. Reviewers need to consider whether implementation impacts other users, whether it generates reusable functionality, or whether possession of the credential reveals information outside the scope of the investigation.

Bill C-22 should be debated in a way that takes into account the amendments.

As of October 12, Bill C-22 is before the Senate at second reading. Debates of October 8 are on record. It continues to be tabled legislation.

The government claims the revised framework provides safeguards so that providers can decline technical obligations that create systemic risk or would otherwise hinder their resolution. Its statement also mentions a provision prohibiting compelled decryption "if the user provided the encryption data in the first place, and they have the knowledge to decrypt it."

But all that is deserved to be noted. Public debate should be based on the amended proposal.

The guarantees will need to be weighed against the legislation, the regulations that it may require and the technical effects of implementation. On 8 October, Mozilla cautioned that the framework could still facilitate requirements that undermine encryption and security. Its intervention underscores ongoing disagreement about the scope of the powers proposed.

Prior to this, in May, the Privacy Commissioner expressed conditional support for an improved version of the previous proposal, calling for stronger protection against issues of proportionality, encryption and systemic vulnerability. This testimony predates the June amendments and should be viewed in that light.

What's a good question now is whether the protections are sufficiently clear so as not to cause harmful requirements in practice? Parliament should obtain independent technical evidence on that.

Sovereignty includes the security of Canadian systems

Canadian ownership does not protect data hosted in Canada. Data in Canada is not protected from software bugs, compromised credentials, or risks caused by privilege.

Digital sovereignty means the ability for organizations to use and defend infrastructure, under accountable governments. Canada should be willing to defend the security underpinnings of the digital tools that it expects institutions to rely on.

Open-source software might assist via transparent code, shared standards, and the potential for a system to be maintained or modified by oneself. Those benefits require continued maintenance, expertise, and responsible security practices. A public repository alone does not ensure safety.

Investigators and operators need to be able to look into problems, work together on responsible disclosure and fix them. Laws should enable that. Secrecy obligations for investigations require formal channels for technical review, oversight and remediation.

In Canada, that means there is a need for people who can evaluate such issues: security researchers, Linux administrators, software maintainers and folks with an understanding of cryptography and infrastructure. Building that knowledge is part of building sovereignty.

Smaller Canadian providers may especially benefit from such access. A provider may be able to deliver a secure offering without a large legal staff or dedicated team to assess government technical requirements. A workable process must offer an efficient, transparent way for these providers to access review and opportunity to voice issues with sufficient time to evaluate before changes are implemented.

All in all, a complex compliance framework could undermine another Canadian priority: a vibrant, diverse homegrown tech industry. Parliament will want to evaluate whether mandates are proportional to the service, and whether the mandate's bearers have the capacity to implement them securely. Security standards should be rigorous but the review process accessible to a range of organizations.

Make the protections meaningful in practice

An accountable lawful-access system must have binding technical limits. There should be an administrable process for providers to raise concerns about unsafe requirements prior to implementation with expert review.

Laws should be defined by what is necessary and proportionate in relation to data collection, retention or disclosure. The retention and collection of more sensitive data imposes additional security obligations and consequences when data is compromised. Every obligation should have a rational purpose, scope and limit.

Must include the operation of the measures? For example, are the technical measures creating new vulnerabilities, can providers address faults in a timely way, are small operators getting real oversight, are checks working properly?

Public reporting can be used to answer those questions while still protecting the particulars of individual probes. Canadians should be able to evaluate whether the regime preserves their safety and their rights.

The review process must also consider things that happen once the software is deployed. Software updates, emerging attack methods and invalidated assumptions from an initial review can all leave organizations with a method of re-evaluating an obligation when new findings mean it poses a security threat. Provider-approved, yes, but what happens when the time comes to fix?

For buyers of digital services, that means an added foundation for their decisions. They can look at a provider's security design and patching process and feel assured that those protections will be in place. That kind of confidence is important in Canada's push for institutions to build domestic options and share their data.

The Linux Association of Canada welcomes an in-depth debate that is driven by technical facts, open to public scrutiny and mindful of proper inquisitorial processes.