The Armored Car Between Vaults

Opening Scene

Valuables perfectly secured inside a locked safe are still genuinely vulnerable the moment they’re moved between two different vault buildings, unless that transport itself is equally well protected — an armored car, guarded and monitored throughout the journey. Data moving between systems faces this exact same exposure, and encryption in transit is the armored car that protects it along the way.

In Plain English

Encryption in transit protects data as it moves across a network — between a client and a server, between two cloud services, between regions — typically implemented through protocols like TLS. This closes a gap that encryption at rest alone doesn’t cover: data that’s perfectly secure while stored can still be intercepted and read while actually moving between systems, if that movement itself isn’t independently protected.

The Old Way

Before encryption in transit was a widely and consistently applied default practice, data movement between systems was sometimes left unprotected:

• Data sometimes moved between systems over unencrypted connections, leaving it genuinely exposed to interception during transit, even when it was well protected at rest.
• There wasn’t yet a well-established practice of treating encryption in transit as a default, non-negotiable requirement for any data movement, not just movement across public networks.
• Internal, service-to-service traffic within a single cloud environment was sometimes left unencrypted, on the mistaken assumption that internal network traffic was inherently safe.

Unencrypted data movement, based on a mistaken assumption of inherent internal safety, is what default, consistently applied encryption in transit directly addresses.

What’s Changing (and Why AI Is the Reason)

1. Organizations increasingly encrypt all data movement by default, including internal, service-to-service traffic, rather than assuming any network segment is inherently safe.
2. This connects directly to the zero trust principle covered in Article 3, since zero trust’s “never trust, always verify” logic extends naturally to never assuming any network path is safe by default.
3. As AI pipelines increasingly move significant volumes of sensitive training data between storage and compute environments, sometimes across cloud providers, encryption in transit has become an especially important, non-negotiable safeguard specifically for these data movement patterns.

The Metaphor, Fully Extended

The Vault Building	Cloud IAM Concept
An armored car protecting valuables during transport	Encryption protocols like TLS protecting data during network transit
Vulnerability during the journey between vaults	Vulnerability during data movement between systems
Guarded and monitored throughout, not just at the endpoints	Encrypted throughout the connection, not just at the endpoints
Closing a gap that a secure vault alone doesn’t cover	Closing a gap that encryption at rest alone doesn’t cover

Quick Recap

• Encryption in transit protects data as it moves across a network, closing a gap encryption at rest alone doesn’t cover.
• Internal, service-to-service traffic deserves the same encryption discipline as external, public network traffic.
• This connects directly to zero trust’s broader principle of never assuming any network path is inherently safe.
• Cross-environment AI training data movement makes this safeguard especially important.

Where This Fits in the Series

Article 10 covered protecting data while it’s actually moving. Article 11 turns to a related, foundational challenge: a separate box for the master keys themselves.