Skip to content

CONCEPT Cited by 1 source

FIPS cryptographic boundary

Definition

FIPS cryptographic boundary is the deployment-topology surface defined by which regions / environments / tenants are required to use only FIPS-140-validated cryptographic modules and FIPS-approved primitives. Inside the boundary: only approved primitives can be negotiated on the wire. Outside the boundary: the full vendor- supported primitive set is available.

The boundary is distinct from data residency though the two often co-locate:

  • Data residency constrains where bytes live at rest / in transit. Answer set: geography.
  • FIPS boundary constrains which cryptographic primitives can be negotiated. Answer set: primitive-allowlist.

A workload can be inside both, one, or neither. The US-region GitHub Enterprise Cloud with data residency sits inside both: US-only data residency and FIPS-approved-only cryptography. Non-US GHEC regions have data residency but no FIPS constraint — which is why GitHub can roll sntrup761x25519-sha512 to non-US data-residency regions but not to the US region. (Source: sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github)

What "FIPS-approved" means

FIPS 140 (currently FIPS 140-3) validates cryptographic modules — the libraries or HSMs that implement primitives. FIPS publications (FIPS 180, 186, 197, 198, 202, 203, 204, 205...) enumerate the primitives allowed. A module is FIPS-validated if it:

  1. Implements only FIPS-approved primitives (AES, SHA-2/3, RSA, ECDSA with approved curves, X25519 since FIPS 186-5, ML-KEM / ML-DSA / SLH-DSA since 2024, etc.)
  2. Passes NIST-certified lab testing.
  3. Maintains its certified configuration (non-approved modes are disabled at runtime when in FIPS mode).

Regulated deployments (US federal workloads, healthcare, finance) often require the module to be operated in FIPS mode — where non-approved primitives aren't just unused, they're actively inaccessible.

Why this creates a boundary, not just a knob

FIPS mode is set at the module level. When a server is in FIPS mode, the list of supported cryptographic algorithms it advertises to clients is filtered — non-approved primitives are removed from the algorithm negotiation list entirely, not merely deprioritized. This means:

  • The FIPS-constrained region's SSH endpoint advertises a strict subset of the algorithms the non-FIPS fleet advertises.
  • Clients negotiating against the FIPS region automatically fall through to the best FIPS-approved option.
  • A composite primitive like sntrup761x25519-sha512 is not available even though X25519 alone is FIPS-approved — the negotiated algorithm is a single FIPS entry, not a product of two.

This is structurally the same shape as concepts/aws-partition — distinct partitions advertise distinct primitive surfaces. The FIPS boundary is a narrower version specific to the cryptographic primitive list rather than the whole service surface.

Canonical instance: GitHub 2025 PQ rollout

GitHub enables sntrup761x25519-sha512 on github.com SSH endpoints and GHEC with data residency "with the exception of the US region" because "only FIPS-approved cryptography may be used within the US region, and this post-quantum algorithm isn't approved by FIPS." (Source: sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github)

The specific reason the hybrid isn't FIPS-approved: Streamlined NTRU Prime (the PQ half) isn't in NIST's approved list. NIST's PQC standardization selected ML-KEM (Kyber, FIPS 203, 2024-08-13) as the primary KEM; OpenSSH's historical PQ-KEX was Streamlined NTRU Prime, predating ML-KEM standardization. The migration path is clear: once OpenSSH (or GitHub's SSH library) ships an ML-KEM-based hybrid, the FIPS region can enable it.

Design implications

1. Crypto-agility is enforced by the boundary. A product running inside the FIPS boundary can't adopt new crypto primitives at vendor pace; it must wait for FIPS approval + library support. Plan for this lag when designing cryptographic-deployment roadmaps.

2. Regional primitive divergence is normal, not a bug. The same product can legitimately negotiate different primitives for different customers depending on which region / tenancy they're using. Telemetry should report the negotiated primitive, not just success / failure, so the divergence is visible.

3. Store-now-decrypt-later is worse inside FIPS boundaries. Until FIPS-approved PQ primitives are available in the relevant library, FIPS-constrained regions are stuck with classical-only KEX and are the most exposed to the store-now-decrypt-later threat. This is an uncomfortable consequence of the compliance frame — regulated workloads are often the highest-value capture targets but last to get PQ protection.

4. Boundary can be narrower than region. An organization might run some environments in FIPS mode and others not, all within the same region, depending on workload classification. The boundary is an operational / deployment choice layered on top of geography.

Boundary What it constrains Example
concepts/aws-partition Service availability, API endpoints, account space AWS GovCloud, China, European Sovereign Cloud
Data residency Storage geography, in-transit geography GHEC US-region, EU-region, etc.
FIPS cryptographic boundary Allowed cryptographic primitives on the wire GHEC US-region, US federal workloads
concepts/digital-sovereignty Operational control + infra + data + tech access Composite of the above

The FIPS boundary typically sits inside a data-residency / partition boundary — not all US-region customers are in FIPS mode, but all FIPS-mode customers must be inside at least an approved data- residency region.

Seen in

Last updated · 200 distilled / 1,178 read