RESOURCE
The Treasury Board direction on cyber security readiness took effect October 1, 2026, with critical services lists due November 30. This guide maps each requirement the Discovery Program covers, contributes to, or leaves to you, so a federal reader can see the fit without a call.
Fabric Networks
The Treasury Board of Canada Secretariat's Direction on Government of Canada Cyber Security Readiness in the Frontier Artificial Intelligence Era is a Security Policy Implementation Notice that took effect on October 1, 2026. It applies to organizations under the Policy on Government Security and covers servers, workstations, virtual machines, mobile devices, routers, switches, firewalls, IoT and lab equipment, on premises, roaming or in the cloud. Its first deadline is November 30, 2026, when every department submits a prioritized list of critical services to TBS. Section 7.3 carries the requirements into procurement documents and contracts, so suppliers to departments will be asked next.
It is not a post-quantum direction. The only cryptographic reference is a pointer to ITSP.40.111 for protecting logs. ITSM.40.001 remains the migration roadmap. The two start in the same place, though: you cannot harden, segment, migrate or report on what you have not inventoried. This guide sets out, requirement by requirement, what a Discovery Program engagement covers, what it contributes evidence to, and what stays with your team. The labels are deliberate. Where the program does not do something, it says so.
Covers: the program deliverable answers the requirement for the networks in scope. Contributes: the program produces evidence or a starting inventory that your team completes. Not in scope: a policy, tooling or process obligation that is yours, listed so nothing is implied.
IDT-1, prioritized critical services list (due November 30, 2026). Contributes. The list is a business decision and it is yours. If you want the list to be defensible, the scoping call fixes which services and network boundaries the probes watch, so the inventory arrives already organised by critical service.
IDT-2, application inventory in the TBS portfolio tool. Not in scope. The program observes encrypted flows, not application records. Where a flow maps to a known application, the findings say so from customer supplied information, labelled as such.
IDT-3, architecture diagrams showing critical services, systems, components and attack paths. Contributes. Passive probes record which endpoints talk to which, over what protocol, cipher suite, key length and certificate. The result is an observed map of the encrypted paths in and out of each critical service, with the weak ones ranked by consequence. That is the attack path layer of the diagram, drawn from traffic rather than from memory. The rest of the diagram, the systems and components themselves, comes from your records.
IDT-4, complete list of Internet connections, public facing addresses, subnets and subdomains for the National Cyber Threat Notification System. Contributes. Every external flow the probes see is inventoried with its endpoints and the cryptography protecting it, which gives you an observed list of connections in use to reconcile against the connections you believe you have. The discovered list is labelled discovered; the gaps between it and your records are usually the most useful finding in the report.
IDT-5, software bill of materials. Not in scope. The program produces a cryptographic bill of materials for network traffic, which is a different document. The two sit well side by side in a submission.
IDT-6, endpoint visibility and awareness. Not in scope. No agents are installed on endpoints and no production configuration is changed.
ACC-2, risk based vulnerability management and replacement of unsupported technology. Contributes. Deprecated protocol versions, weak cipher suites, short keys, expired or self signed certificates and manually managed preshared keys are flagged per flow and ranked. That is the cryptographic slice of your vulnerability picture, with the Internet facing items marked for the faster patch cycle the direction asks for.
HRD-1 to HRD-8, identity, MFA, privileged access, non person entities, awareness. Not in scope. These are identity and administration controls. The program does not assess them, and this guide does not claim otherwise.
FTY-1, harden edge devices, remote access, administrative interfaces, Internet facing services and APIs to Cyber Centre guidance. Covers the cryptographic part. The inventory shows exactly what each VPN concentrator, firewall tunnel, remote access gateway and management interface is negotiating today. Remediation, if you choose it after the roadmap, delivers quantum-safe symmetric keys into the IPsec VPNs on the firewalls you already run; no hardware is replaced. Hardening beyond cryptography (service minimisation, interface exposure, patch state) is your team's work against the Cyber Centre guidance the direction cites.
FTY-2, vendor remote access inventoried, approved, time limited, logged and removable. Contributes. Vendor tunnels show up in the discovered inventory whether or not they are in your records: the endpoint, the protocol, the cipher and how long the session persisted. That gives you the inventory half of FTY-2. The approval, time limits and removal process are policy and remain yours.
FTY-3, critical services in network zones segmented per ITSP.80.022 and ITSG-38. Contributes. Observed flows crossing zone boundaries, and the cryptography on each crossing, are evidence for a segmentation design. The design itself is architecture work; Fabric does it as a separate scope when asked.
FTY-4 and FTY-5, outbound blocking and hardened administrative endpoints. Not in scope, beyond the observed record of outbound flows that FTY-4 enforcement would need to allow explicitly.
MTR-2, event logs protected with approved cryptographic safeguards under ITSP.40.111 and forwarded centrally. Contributes. Log forwarding is an encrypted flow like any other. The inventory records what protects it between each source and the central facility, so you can show, with evidence, that the safeguard meets ITSP.40.111 or fix the ones that do not.
MTR-1 and MTR-3, logging and endpoint detection. Not in scope.
PRP-1 to PRP-5, plans, exercises, playbooks, backups. Not in scope. One note on PRP-5: backup replication is also an encrypted flow, and the inventory will show what protects it.
If you supply a department rather than run one, the same mapping applies to your own network, and the contract clause will ask you to show it. A supplier who arrives with an observed inventory, labelled by how each finding was established, has an easier conversation than one who arrives with a policy binder.
Three months. Virtual probes at the boundaries you choose, installed remotely, watching live traffic across IT and OT without touching endpoints. Findings ranked by consequence and mapped to the Canadian and NIST frameworks that apply to you, with the direction's requirement numbers added for federal clients. A findings workshop at week six. A board ready summary and a phased roadmap with estimated costs, which is also the ITSM.40.001 deliverable, in the same report. Every finding labelled customer supplied, discovered or our judgment. A written, fixed scope quote before any work starts, structured to fit a fiscal year.
The eight weeks between now and November 30 are enough to scope, deploy probes and have an observed inventory in hand for the services on your list. Request a scoping call, or start with the five minute risk check.
Start with a conversation about your cryptographic posture.