Accreditation by emission, not collection

Anyone who has staffed an ITSG-33 accreditation reads the title and knows the contrast already. Today, the evidence that a Protected B system meets its security controls is collected. A team assembles it by hand, control by control, over a year or more, into a body of evidence an authorizing official can sign against. Then a significant change arrives, or the authorization comes up for renewal, and a meaningful share of the work happens again. The evidence is a project, and the project’s never quite finished.

This essay is about the other word. Evidence can be emitted instead of collected: produced by the deployment chain at the moment of each signed apply, mapped to the controls it satisfies, in a form an accreditor can read directly. One word leaves you with an accreditation cycle that consumes a year of senior security staff; the other leaves you with an afternoon of verification against a record the system kept for itself.

What collection costs

ITSG-33 is the Government of Canada’s framework for IT security risk management, and its control catalogue is the menu a departmental authority draws from to build a system’s control profile.¹ For a system handling Protected B information with medium integrity and medium availability needs, the reference profile is the well-known PBMM baseline, and it isn’t short.² Each control in the selected profile has to be shown to be implemented, and shown in a way an authorizing official will accept as the basis for granting authority to operate.

In most Canadian defence environments that showing is a manual artifact. Configuration exports, screenshots, interview notes, architecture diagrams, and policy references are gathered into a security assessment package, control by control, by the team that operates the system. The work is real, it is senior, and it is slow. It’s also perishable. The package describes the system as it stood on the day the evidence was gathered, and the system doesn’t stand still. Every significant change reopens the question the package was assembled to close, and the re-authorization that follows reopens it again on a schedule. The cost isn’t a one-time tax on standing a system up but a standing tax on operating it.

The framework already asked for continuous

The part worth sitting with is that the framework didn’t ask for a point-in-time binder. The CCCS guidance on cloud security assessment and authorization recommends ways to authorize a service, continuously monitor it, and maintain that authorization over time.³ Continuous monitoring and maintained authorization are the stated intent. The annual-binder reality is the gap between that intent and the systems that have to satisfy it, and the gap exists for a simple reason. The systems weren’t built to emit evidence. They were built to run, and the evidence was reconstructed afterward by people reading their state.

A deployment chain that produces its own evidence as it operates closes that gap from the other side. It doesn’t ask the accreditor to accept less. It gives the system a way to keep the record the framework already wanted, as it happens, instead of having a team rebuild it later.

What emission looks like

Emission means that the act of deploying produces the evidence of the deployment, bound into the same operation. At each signed apply, the chain writes a record: which artifact was applied, by which individual identity, at which time, under which enforcement posture, with which provenance. The record is individual-bound, so the audit answer to “who applied this” is a person and not a shared service account, which is the distinction the audit-accountability controls in the catalogue are written to demand. The record is hash-chained, so altering a past entry breaks the chain at exactly that point, which is the property the audit-protection controls ask for. The record is retained on the operator’s own infrastructure for the required period, and it verifies offline with stock cryptographic tooling, so the evidence is auditable without trusting the vendor that produced it.

Stated in the catalogue’s own vocabulary, a chain like this emits the evidence the audit family of controls is written to require, carries the cryptographic-posture evidence the system-and-communications-protection controls ask for, and records what was deployed in a form the configuration-management controls can consume. This is not the whole of a Protected B profile. It’s the evidence the deploy-time and audit-time controls need, which is precisely the body of evidence that’s most expensive to reconstruct by hand and most perishable once reconstructed. The accreditor still reads it. The difference is that the accreditor is reading a record the system produced by construction, rather than a binder assembled after the fact by the team being assessed.

A line an RFP can add

The contrast resolves into a question that fits on one line of an evaluation. Does the vendor’s deployment chain emit accreditation-grade evidence at apply time, or must that evidence be assembled by hand after deployment?

The question is worth asking because the answer changes the cost structure of every system the vendor touches. A chain that emits turns the audit-and-deploy portion of an accreditation package from a multi-month assembly project into a query against a tamper-evident log the operator already holds. A chain that doesn’t emit leaves that project in place, to be paid once at authorization and again at every re-authorization and significant change for the life of the system. The federal government has already moved in this direction for the open supply chain, making signed provenance the supplier’s deliverable rather than a courtesy.⁴ An accreditation evaluation that asks the same question of the deployment chain is asking the vendor to deliver evidence the system emits, not promises the vendor makes.

What emission does not do

Emission is not a compliance claim, and it’s worth being exact about the boundary. Emitting evidence does not authorize a system; an authorizing official does that. Nor does it implement the controls; it records that the deploy-time operations happened, by whom, and under what posture, in a form that resists tampering. The whole control profile is a wider thing than emission touches: a Protected B authorization rests on far more than audit and deployment evidence, and the rest of that profile is unaffected by anything described here. None of this amounts to a certification, either. Alignment with the CCCS Medium control profile is a posture a system can be built toward, not a stamp a tooling vendor can assert on a customer’s behalf.⁵

What emission does is narrower and real. It moves the most perishable, most expensive portion of the evidence from something a team reconstructs to something the system produces, and it gives that evidence the integrity properties (individual-bound, tamper-evident, offline-verifiable) that make an accreditor trust it without trusting the vendor. That’s the whole claim, and an honest vendor doesn’t stretch it into a compliance guarantee a sharp authorizer will see through.

The earlier pieces in this series argued that a serious vendor answers procurement questions structurally rather than with marketing copy. Accreditation evidence is one of those questions, and emission is its structural answer. The vendor whose chain emits the evidence is the vendor whose customers spend their accreditation cycles verifying a record instead of building one.

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 on Canadian-jurisdictional infrastructure, 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 evaluating sovereign infrastructure for classified workloads, and you’ve staffed an accreditation cycle and recognized the contrast in the title, the conversation is open.