Quantum-safe networking design patterns for the data centre fabric and DCI

Quantum-safe networking becomes real when it shows up in designs, configs, telemetry, and lifecycle. This article focuses on architecture patterns you can apply to a data centre fabric and interconnect while building a migration path to post-quantum cryptography (PQC).

Nokia’s position is that quantum-safe security comes from defence-in-depth across network layers, combining multi-layer encryption, key distribution, and operational controls.

That aligns with how most of us build networks today: multiple layers, multiple domains, and lots of automation.

Threat model

Three main technological risks in a post-quantum world:

• Public-key cryptography used for key exchange and signatures becomes vulnerable (RSA, DH, ECC)
• Post-Quantum Cryptography (PQC) is still in development and does not inherently secure the lower layers of the network stack.
• Quantum Key Distribution (QKD) faces deployment challenges, including the requirement for dedicated optical fibre infrastructure, with satellite-based solutions still several years from widespread availability

Therefore, the "harvest now, decrypt later" threat highlights the critical vulnerability of currently encrypted sensitive data to future decryption capabilities. At the same time, symmetric encryption with suitable key sizes, quality and rotation mechanism remains viable in a post-quantum world. So the near-term focus is on protecting bulk traffic and improving key practices while preparing the trust layer for PQC.

Even if symmetric encryption protects the bulk data, the initial key exchange and authentication steps remain vulnerable.

Start with a reference architecture

For most enterprises, a practical scope is:

• Leaf-spine data centre fabric (east-west)
• DCI between sites (often optical plus IP/MPLS or Ethernet)
• WAN/edge on-ramps (cloud connectivity, branches, OT)
• Management plane and automation stack (controllers, APIs, CI/CD, AAA)

Map quantum-safe controls to each zone, and keep the approach consistent with your operational model.

Four quantum-safe design patterns

Based on the reference architecture above, the following four patterns provide a practical way to embed quantum-safe principles into the data centre fabric, DCI, and management stack.

They are not mutually exclusive. Together, they create layered protection across transport, service, and trust domains while building a migration path towards PQC and crypto-agility.

Each pattern addresses a different control plane or data plane concern:

• Fabric-level confidentiality inside the data centre
• Multi-layer protection across DCI
• Trust and identity in the management and automation stack
• Long-term crypto-agility across the full lifecycle

Pattern 1: Fabric link encryption as a baseline control

Goal: protect east-west traffic and reduce capture value inside the data centre.

Common approach:

• Use link-layer encryption on fabric links where platforms support it at line rate, with operationally manageable key rollover.
• Keep visibility in mind: ensure you can still do the telemetry and troubleshooting you rely on, and validate how encryption interacts with taps, SPAN, or out-of-band monitoring.

What to decide early:

• Where encryption terminates (ToR to spine only, or deeper)
• How keys are handled and rotated
• What telemetry you get for encryption state, failures, and renegotiation

This is also a good place to standardise lifecycle: template-driven config, compliance checks, and drift control.

Pattern 2: DCI encryption with clear layer ownership

Goal: protect replication, backup, storage sync, and service-to-service traffic between sites.

Nokia’s quantum-safe networking content emphasises multi-layer cryptography and key distribution as building blocks.

• Deploying encryption at the Optical/transport layer for foundational, high-throughput, and low-latency protection of the physical link, serving as a primary barrier against eavesdropping on the fibre itself.
• Adding encryption at the Ethernet or IP layer to provide finer-grained security, offering topology flexibility, service separation, and protection against logical attacks or compromised network devices further up the stack.
• Implementing a combination of these layers is often the most effective strategy, creating a resilient security posture where the failure or bypass of one encryption layer does not compromise the overall data integrity and confidentiality. This layered approach is particularly crucial when different teams manage distinct network segments or when regulatory compliance demands comprehensive, multi-faceted controls

Engineering considerations:

• Latency and throughput headroom
• Failure modes during rekey and link events
• Interoperability across vendors and domains
• Operational responsibility for keys, alarms, and audits

If you are using DCI refresh projects, treat quantum-safe as a first-class requirement rather than a later add-on.

Pattern 3: Management plane and automation - prepare for PQC and hybrid transition

Goal: keep device identity, admin access, API trust, and signed artefacts trustworthy as PQC rolls out.

This is where PQC shows up first for many environments because it touches:

• TLS for APIs and northbound integrations
• SSH access and jump hosts
• Certificate chains for device identity and service authentication
• Software signing and secure boot chains

The transition is rarely “pure PQC overnight”. Hybrid approaches are common because they enable interoperability while providing quantum resistance. The IETF TLS working group has an active draft on hybrid key exchange in TLS 1.3, which reflects how the industry is approaching staged migration.

Engineering tasks to put on the roadmap:

• Inventory where TLS, SSH, and certificate validation live in your network tooling
• Validate crypto libraries used by controllers, collectors, and orchestration
• Test hybrid or PQC-capable stacks in non-prod first, then edge use cases, then core management services

Pattern 4: Crypto-agility as an engineering requirement

Goal: Ensure the network can adapt cryptographic algorithms and key practices without architectural redesign.

You want the ability to:

• Swap or add algorithms without redesigning transport
• Rotate keys at scale with predictable operational behaviour
• Keep audit trails that satisfy internal governance and external obligations

NIST’s approval of the first PQC standards (FIPS 203/204/205) is a practical anchor for vendor roadmaps and for your own testing strategy.

Where Quantum Key Distribution fits in engineering terms

QKD can be relevant for specific high-assurance links, but it comes with deployment constraints and ecosystem maturity questions. Space-based QKD is advancing, yet commentary still points to the first commercial applications being a few years out.

Engineering takeaway:

• Do not block near-term controls while waiting for QKD
• Keep an architecture that could incorporate QKD later, where it provides value, without forcing it into every link

A practical 6–12 month plan for engineers

If you want something you can execute without making it an impossible task, aim for these deliverables:

1. Crypto and trust inventory for the network stack
   Protocols, devices, controllers, CI/CD components, PKI dependencies, and external integrations.
2. Fabric encryption baseline and rollout plan
   Scope, key handling, telemetry, and operational runbooks.
3. DCI encryption design with layer decisions documented
   Clear ownership, performance validation, and failure-mode testing.
4. PQC readiness testing for management plane services
   Lab validation for TLS/SSH stacks, certificate chains, and upgrade paths aligned to vendor releases and NIST standards.
5. Procurement checklist for crypto-agility and roadmap support
   Algorithm support, hybrid options, upgradeability, observability, and lifecycle commitments.

Where Nomios and Nokia fit

Nokia’s quantum-safe networking approach focuses on outcomes backed by practical deployments and a defence-in-depth model across layers.

Nomios brings the integration, design, and operationalisation side: mapping these controls into real data centre fabrics and interconnects, tying them to PKI and identity programmes, and making sure the runbooks, monitoring, and governance are workable at scale.