Protect the Confidentiality And Integrity of Sensitive Information with GO-ITS 25.12

The Government of Ontario Information Technology Standards (GO-ITS) program sets the guidelines, standards, and practices that Ontario Public Service ministries and their vendors must follow. GO-ITS 25.12, Security Requirements for the Use of Cryptography, is the standard that tells every ministry, agency, and third party working with Ontario government data exactly which cryptographic algorithms, key lengths, and protocols are approved to protect the confidentiality and integrity of sensitive information.

In the standard, requirements phrased with must are mandatory, and requirements phrased with should are recommendations. GO-ITS 25.12 applies to Ontario government ministries, former Schedule I and IV agencies, Cloud Service Providers, and any vendor or third party under contract with the Government of Ontario that creates, stores, transmits, or processes Ontario Public Service information.

Published: March 2022. Updated: August 2026. Reviewed by Encryption Consulting’s Compliance Advisory team.

What Does GO-ITS 25.12 Require?

GO-ITS 25.12 requires that sensitive Ontario government information be protected using approved cryptographic algorithms at every stage: creation, storage, distribution, use, revocation, destruction, and recovery of the keys involved. The requirements are organized into distinct areas, and each one maps to a real operational control rather than a vague principle.

• Education and training. Technical staff who develop, implement, or manage systems that use cryptography must understand the standard’s requirements before they touch production systems.
• Information in storage. Sensitive data should be encrypted at rest, and data held longer than two years must use encryption suitable for a high-risk environment. Mobile devices must use full-disk encryption, and sensitive fields must be encrypted at the column or cell level before they reach a data repository.
• Communications security. Sensitive information must be encrypted in transit, and its integrity must be verified with an approved message authentication code or a digital signature carrying an accurate, trusted timestamp.
• Cryptography deployment. Applications must use an approved random or pseudo-random number generator, validate certificates before trusting them, purge decrypted data from cache or temporary memory immediately after use, and pass security testing and evaluation (STE) before going live.
• Protection of cryptographic material. Access to keys is restricted to authorized users and services, key protection scales with data sensitivity, and key generation should happen on an approved software module or a Hardware Security Module (HSM), on premises wherever the information is highly sensitive.

Who Must Comply with GO-ITS 25.12?

GO-ITS 25.12 binds a wider circle than just the ministries that write the checks. Anyone touching Ontario Public Service data through a contract inherits the standard’s obligations.

• Ontario government ministries and former Schedule I and IV agencies.
• Third-party service providers and system integrators working under contract with the Government of Ontario.
• Cloud Service Providers hosting Ontario Public Service workloads or data.
• Any organization that creates, stores, transmits, or processes Ontario government information, regardless of where that processing physically happens.

In practice, this means a vendor bidding on an Ontario government contract needs to demonstrate GO-ITS 25.12 alignment during procurement, not retrofit it after the contract is signed. Encryption Consulting’s Compliance Advisory Services exist for exactly this gap: mapping a vendor’s current cryptographic posture against the standard’s Appendix A before a bid goes out the door.

How Do You Select the Right Algorithms and Key Lengths?

Cryptography protects the confidentiality and integrity of sensitive information through three families of algorithms: symmetric encryption for bulk confidentiality, asymmetric encryption for digital signatures and key exchange, and hash functions for integrity checking. GO-ITS 25.12’s Appendix A sets a minimum key length for standard use and a higher one for high-risk environments, and each choice maps to an underlying NIST standard, since GO-ITS does not define its own cryptographic primitives.

Algorithm Category	Approved Algorithm	Minimum Key Length	High-Risk Environment	Underlying NIST Standard	Status
Symmetric encryption	AES	128-bit	256-bit	FIPS 197	Approved
Symmetric encryption (legacy)	3DES (Triple DES)	168-bit nominal, 112-bit effective	Not recommended	SP 800-131A Rev. 2	Deprecated, phase out by 2030 per GO-ITS; NIST already disallows new use
Symmetric encryption (stream)	ChaCha20-Poly1305	256-bit	256-bit	RFC 8439	Approved
Asymmetric encryption and signatures	RSA	2048-bit	3072-bit	FIPS 186-5	Approved
Asymmetric signatures (elliptic curve)	ECDSA	P-256	P-384	FIPS 186-5	Approved
Asymmetric signatures (edwards curve)	EdDSA	Ed25519-equivalent	Ed448-equivalent	FIPS 186-5	Approved
Hash functions	SHA2-256 family, SHA3-256 family	256-bit output	256-bit output or stronger	FIPS 180-4, FIPS 202	Approved
Hash functions (legacy)	MD5, SHA-1	N/A	N/A	SP 800-131A Rev. 2	Prohibited for digital signatures; SHA-1 legacy verification only
Message authentication	HMAC (SHA2-256+), CMAC, GMAC, Poly1305	Matches underlying algorithm	Matches underlying algorithm	SP 800-38B, SP 800-38D, RFC 8439	Approved

Table: GO-ITS 25.12 approved algorithms mapped to their governing NIST standards.

The 112-bit security strength threshold in NIST SP 800-131A Rev. 2 is what sits behind GO-ITS 25.12’s RSA-2048 and ECC P-256 minimums: RSA needs a 2048-bit modulus and elliptic curve schemes need roughly a 224-bit or larger group order to reach that same 112-bit strength floor. For a deeper look at how FIPS 140-3 categorizes these same algorithms by approval status, see our post on transitioning to FIPS 140-3.

What Threats Does GO-ITS 25.12 Defend Against?

Every requirement in GO-ITS 25.12 traces back to a specific way sensitive government data gets exposed. Understanding the threat model makes the requirements feel less arbitrary and easier to prioritize when resources are limited.

• Interception in transit. Unencrypted or weakly encrypted network traffic can be captured and read by an attacker positioned on the network path, which is why the standard mandates encryption for all communications and prohibits SSL and early TLS versions that are vulnerable to protocol downgrade attacks.
• Exposure of data at rest. A stolen laptop, a misconfigured database, or a breached storage bucket exposes unencrypted sensitive data directly, which drives the full-disk encryption and column-level encryption requirements.
• Cryptanalysis of weak or legacy primitives. MD5 and SHA-1 both have practical collision attacks, and 3DES is vulnerable to meet-in-the-middle and birthday-bound attacks at high data volumes, which is why the standard deprecates them in favor of SHA2/SHA3 and AES.
• Key compromise and insider misuse. A poorly protected key undermines every control built on top of it, which is why GO-ITS 25.12 restricts key access to authorized users and services and requires documented generation, distribution, rotation, and destruction procedures.
• Implementation flaws. Reusing an initialization vector under AES-GCM, or using Electronic Codebook (ECB) mode, leaks structural information about the plaintext even when the underlying algorithm is sound. GO-ITS 25.12 explicitly prohibits ECB mode for this reason.
• Harvest-now-decrypt-later. Adversaries can capture encrypted traffic today and decrypt it once a cryptographically relevant quantum computer exists. GO-ITS 25.12 does not yet mandate post-quantum algorithms, but its own text calls out cryptographic agility as a defense against emerging threats, which is the same posture NIST recommends in its post-quantum migration guidance. See our guide to post-quantum cryptography migration deadlines for how other jurisdictions are handling this same transition.

How Do You Achieve GO-ITS 25.12 Compliance?

Compliance with GO-ITS 25.12 is a sequence, not a checkbox. Organizations that treat it as a one-time audit tend to drift out of compliance the next time an algorithm gets deprecated or a new system gets stood up.

1. Inventory cryptographic assets. Identify every algorithm, key, certificate, and protocol in use, and classify the sensitivity of the data each one protects. Without this inventory, none of the following steps have a reliable starting point.
2. Map current state against Appendix A. Compare every algorithm and key length in the inventory to the GO-ITS 25.12 approved algorithms table, flagging anything prohibited, deprecated, or below the required key length for its risk tier.
3. Retire prohibited and deprecated primitives. Remove DES, ECB mode, MD5 for signatures, SHA-1 for signatures, and SSL or early TLS wherever they still appear, prioritizing internet-facing systems first.
4. Select approved algorithms and key lengths per risk tier. Standard-risk data gets the standard’s minimum key lengths; high-risk data (or anything retained more than two years) gets the high-risk minimums from the table above.
5. Deploy HSM-backed key generation and storage. Meet FIPS 140-2 or FIPS 140-3 / ISO/IEC 19790:2012 Level 2 at minimum, and Level 3 for high-risk information or off-premises deployment, keeping high-sensitivity key generation on premises wherever the standard recommends it.
6. Build documented key management procedures. Cover generation, assignment, distribution, rotation, revocation, and destruction, and keep test keys and production keys in strictly separate environments.
7. Complete security testing and evaluation (STE). Any application that processes or accesses sensitive data needs STE before it reaches production, not after.
8. Establish ongoing training, audit, and monitoring. Technical staff need standing awareness of the requirements, and HSMs and key management systems need continuous monitoring, not a once-a-year review.

What Are the Performance and Interoperability Trade-offs?

GO-ITS 25.12 approves more than one algorithm for most categories precisely because no single choice wins on every dimension. Picking the right one for a given system means weighing performance against interoperability against the hardware actually deployed.

Choice	Relative Performance	Interoperability	Best Fit
AES-256-GCM vs. AES-128-GCM	AES-256 runs more rounds and is marginally slower, though negligible on hardware with AES-NI acceleration	Universal across modern TLS stacks and HSMs	AES-256 for high-risk and long-retention data; AES-128 acceptable elsewhere
RSA-2048 vs. ECDSA P-256	RSA signs slower and verifies faster; ECDSA signs faster with a much smaller key and signature size	RSA has the broadest legacy client support; ECDSA needs a reasonably modern TLS stack	ECDSA for new deployments and constrained clients; RSA where legacy interoperability is a hard requirement
TLS 1.3 vs. TLS 1.2	TLS 1.3 completes its handshake in one round trip (or zero, with resumption), reducing latency	TLS 1.2 still has broader support among older clients and middleboxes	TLS 1.3 as the default; keep TLS 1.2 available only where legacy clients require it
On-premises HSM vs. off-premises/cloud HSM	On-premises avoids network round trips to a remote HSM, at higher upfront cost	Cloud HSM scales faster but must meet FIPS 140-2/140-3 Level 3 for high-sensitivity, off-premises use per GO-ITS 25.12	On-premises for the most sensitive key generation; cloud HSM for scale once Level 3 validation is confirmed
ChaCha20-Poly1305 vs. AES-GCM	ChaCha20 is faster on devices without AES-NI hardware acceleration; AES-GCM is faster where that acceleration exists	Both are standard cipher suite options in TLS 1.2 and 1.3	Match the cipher to the endpoint’s hardware profile: ChaCha20 for mobile and IoT, AES-GCM for standard server hardware

Table: Performance and interoperability trade-offs among GO-ITS 25.12-approved choices.

What Key Management Dependencies Does GO-ITS 25.12 Create?

Key management is where most GO-ITS 25.12 programs actually succeed or fail, because algorithm selection is a one-time decision while key management is an ongoing operational discipline.

• Government ownership of keys. The Government of Ontario retains ownership of cryptographic keys protecting its information, which constrains how any managed service or Cloud Service Provider can architect key custody.
• HSM dependency. High-sensitivity key generation and storage requires an HSM meeting the FIPS 140-2/140-3 level appropriate to the data’s risk tier, which means HSM procurement and lifecycle management becomes a compliance dependency, not just an infrastructure decision.
• Recovery obligations. Decryption keys must remain recoverable after expiration so that archived backups stay readable, which requires a documented key escrow or recovery mechanism, not just a rotation policy.
• Test and production separation. Keys created for testing must never appear in production, and production keys must never appear in test environments, which has real implications for how CI/CD pipelines and staging environments are provisioned.
• Ownership transfer handling. When data custody moves to another organization, that data must be re-encrypted under a new key rather than the old key simply changing hands, which affects any migration or offboarding project.
• Visibility as a prerequisite. None of the above is achievable without first knowing which keys, certificates, and algorithms exist across the environment, which is why a cryptographic inventory tool like CBOM Secure is often the first practical step in a GO-ITS 25.12 program rather than an afterthought.

What Does a GO-ITS 25.12-Compliant Deployment Look Like?

The requirements above translate into concrete architecture decisions. A few representative examples:

• Public-facing web application. TLS 1.3 terminated at the load balancer using an ECDSA P-256 certificate, with the private key generated and held inside an HSM rather than on the application server’s disk, and cipher suites restricted to the algorithms in the GO-ITS 25.12 table.
• Sensitive database fields. Column-level encryption using AES-256-GCM for fields containing personal or health information, with the data encryption keys wrapped by an HSM-protected master key rather than stored alongside the data.
• Inter-ministry file transfer. SSH 2.0 or newer for transport, AES-GCM or ChaCha20-Poly1305 for payload confidentiality, and an HMAC-SHA2-256 or digital signature for integrity verification with a trusted timestamp.
• Code signing and document signing. RSA-3072 or ECDSA P-384 signatures backed by an HSM-protected signing key, with a timestamp from a valid, trusted reference source so the signature remains verifiable after the certificate expires.

Limitations

• GO-ITS 25.12 does not yet mandate NIST’s post-quantum algorithms (ML-KEM, ML-DSA, SLH-DSA); it names cryptographic agility as a goal without requiring a specific PQC migration timeline.
• The standard names approved algorithms and key lengths but does not specify exact TLS cipher suite strings, leaving room for inconsistent implementation across ministries and vendors.
• Many requirements use “should” rather than “must,” which makes them recommendations rather than binding obligations, and enforcement of “should” language varies by ministry.
• The standard predates widespread cloud-native and ephemeral-key architectures in detail, deferring cloud-specific controls to the related GO-ITS 25.21 cloud services standard rather than covering them directly.
• GO-ITS 25.12 does not itself mandate a specific crypto-agility tooling or inventory requirement, even though it names crypto-agility as a defense against emerging threats.

What Would Encryption Consulting Recommend?

Most organizations we work with on GO-ITS 25.12 do not fail on algorithm selection. The table in Appendix A is not hard to read. They fail on the operational layer underneath it: nobody has a current inventory of what algorithms and keys actually exist, HSM procurement takes months, and key management procedures live in someone’s head rather than in a document an auditor can review.

Our recommendation is to work the problem in this order. Start with a gap assessment through Compliance Advisory Services that maps current algorithms, key lengths, and protocols directly against the GO-ITS 25.12 Appendix A table, producing a prioritized remediation roadmap instead of a generic audit report. Where the gap is HSM validation level, HSM-as-a-Service gets an organization to FIPS 140-2/140-3 Level 2 or Level 3 validated key protection without a multi-month hardware procurement cycle, which matters when a bid deadline is fixed. Where the gap is certificate issuance, revocation, or CP/CPS alignment, our PKI Services team builds the policy and technical framework that keeps certificate practices auditable against the standard rather than improvised per project.

We would also push back gently on treating 2030 as a comfortable deadline for retiring 3DES. NIST’s own transition guidance already disallows new 3DES encryption, and specifying AES from day one on any new Ontario government system costs nothing extra and removes a future remediation item entirely.

Conclusion

GO-ITS 25.12 exists to protect the confidentiality and integrity of sensitive information across the Ontario Public Service, and it does that by pointing every ministry and vendor at the same table of approved algorithms, key lengths, and HSM validation levels rather than leaving cryptographic choices to individual project teams. The technical requirements are not the hard part. Building the inventory, key management discipline, and HSM infrastructure that keep those requirements true on an ongoing basis is where organizations actually need help, and it is where a structured compliance program pays for itself well before an audit ever happens.

Frequently Asked Questions

What is GO-ITS 25.12? GO-ITS 25.12 is the Government of Ontario IT Standard titled Security Requirements for the Use of Cryptography. It sets the approved cryptographic algorithms, minimum key lengths, and protocols that Ontario Public Service ministries, agencies, and their vendors must use to protect sensitive government information in storage and in transit.

Who has to comply with GO-ITS 25.12? The standard applies to Ontario government ministries, former Schedule I and IV agencies, Cloud Service Providers, and any third party or vendor under contract with the Government of Ontario that creates, stores, transmits, or processes Ontario Public Service information.

What HSM validation level does GO-ITS 25.12 require? Hardware Security Modules protecting Ontario government keys must be validated to at least FIPS 140-2 or FIPS 140-3 / ISO/IEC 19790:2012 Level 2. HSMs storing highly sensitive information off premises should meet Level 3.

Does GO-ITS 25.12 require TLS 1.3? GO-ITS 25.12 requires support for TLS and calls for TLS 1.2 and 1.3 specifically, while prohibiting SSL and early, vulnerable versions of TLS. Cipher suites must be chosen from the standard’s approved algorithm and key length table.

Is 3DES still allowed under GO-ITS 25.12? GO-ITS 25.12’s algorithm table still lists 3DES, with Government of Ontario guidance targeting discontinuation by 2030. NIST’s own transition guidance already disallows 3DES encryption for new use, so Encryption Consulting recommends specifying AES rather than 3DES for any new Ontario government deployment.

References

• Government of Ontario: GO-ITS 25.12, Security Requirements for the Use of Cryptography
• Government of Ontario: Information Technology Standards program
• NIST FIPS 140-3, Security Requirements for Cryptographic Modules
• NIST FIPS 197, Advanced Encryption Standard (AES)
• NIST FIPS 186-5, Digital Signature Standard (DSS)
• NIST SP 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths
• NIST CSRC: FIPS 140-3 Transition Effort