Encryption Is Not Diplomatic Immunity

The Meeting Where “Encrypted” Became a Liability

The incident began politely, as these things do.

A vendor slid a glossy security overview across the table. Their representative spoke with calm confidence: “All customer data is encrypted.” They paused, as if the conversation had ended. Our procurement lead nodded. A project manager exhaled in relief.

We did not.

Because “encrypted” is not a diplomatic passport. It is not a flag that grants immunity from foreign courts, administrative access, or compelled assistance. Encryption is a fence. Jurisdiction is the border checkpoint. If the vendor controls the checkpoint, the fence is decorative.

So we asked the questions that make rooms quiet: Who can reset account access? Who holds the keys? Which legal regime governs the provider and its subcontractors? Where are support staff located, and what privileged access exists during incidents? What metadata is retained and for how long?

The representative repeated: “It’s encrypted.”

This was unacceptable to the municipality. We cannot negotiate on this point.

The Threat: Encryption ends the criminal conversation. It does not end the sovereign conversation.

The Treaty: We will accept encryption only as one clause inside a wider agreement: key custody, metadata minimization, auditable access, and an exit we can execute.

What Encryption Does—and Does Not—Protect

Encryption in transit prevents opportunistic interception. Encryption at rest reduces damage after certain categories of breach. End-to-end encryption can protect content from the provider—if implemented correctly and if the provider cannot silently change client code, capture keys, or compel key escrow.

But encryption does not automatically protect us from:

• Compelled disclosure under the provider’s jurisdiction. If a company is subject to the US CLOUD Act, a lawful order can reach data in its possession, custody, or control—even if the server is physically in Europe. Geography is not sovereignty.
• Account takeover and administrative access. If the provider can reset credentials, assume roles, or access tenant environments for “support,” encryption becomes irrelevant. The attacker becomes a process, not a person.
• Metadata exposure. Who talked to whom, when, from where, about which case number—this is often more sensitive than content. Many systems “encrypt data” while leaving metadata as an open ledger.
• Backups, logs, and telemetry. Vendors frequently encrypt primary storage while exporting logs to separate systems, retaining backups for months, and collecting diagnostic data that escapes our data residency expectations.
• Client-side weakness. If the provider controls the application layer, they control what is encrypted, when, and how. A “secure” system that can be changed unilaterally is a shifting border.

Here is the practical truth: encryption is a technical measure. Sovereignty is a governance posture. One does not replace the other.

A Sovereignty Threat Model We Can Defend

Municipal data is not consumer photos. We hold the records of vulnerable Citizens. We cannot treat this as a product decision; it is a civic obligation.

So our threat model must include not only hackers, but also:

• Foreign legal compulsion (orders served on the provider or its subprocessors).
• Insider access (support engineers, contractors, incident responders).
• Vendor failure (bankruptcy, acquisition, sanctions, service termination).
• Political drift (policy changes, export controls, jurisdictional disputes).

If our controls do not address these, we are defending the city’s borders with a ceremonial guard.

The Threat: The belief that “encrypted” ends the conversation is a surrender dressed as a safeguard.

The Treaty We Require: Controls Beyond the Encryption Claim

We do not reject encryption. We reject the idea that it is the end of the discussion.

Our minimum “treaty terms” look like this:

1. Key custody under municipal control

   • Customer-managed keys in an HSM controlled by the municipality or a domestic trusted operator.
   • No unilateral vendor access to keys. No silent key rotation initiated outside our approval.
   • Clear separation of duties: support cannot access key material.

2. Provable limits on privileged access

   • Break-glass access must be time-bound, logged, and require our explicit approval.
   • Administrative actions must be auditable in immutable logs we can export.
   • If remote support crosses into foreign infrastructure or foreign staff, we treat it as cross-border access.

3. Metadata minimization and retention discipline

   • Define metadata as data. Case identifiers, contact graphs, access patterns.
   • Minimize collection; strictly cap retention; document all processing purposes.
   • Disable optional telemetry by default. If a feature sends Citizen data to California, turn it off.

4. Disclosure and legal process transparency

   • Vendor must disclose legal demands unless prohibited, and must challenge overbroad orders.
   • Clear statement of governing law, corporate entities involved, and subprocessors with their jurisdictions.
   • We require a written description of what the vendor can technically disclose.

5. Exit within 30 days

   • If we cannot leave the vendor in 30 days, we have been colonized.
   • Export in open formats, including logs and metadata necessary for continuity.
   • No “professional services” ransom to retrieve our own records.

The Treaty: Encryption is one line item. Sovereign control is the contract.

A simple sovereignty diagram is useful here:

Citizen Data Exposure Layers
┌──────────────────────────────────────────┐
│ Content (messages, documents, records)    │  ← often encrypted
├──────────────────────────────────────────┤
│ Metadata (who/when/where/case IDs)        │  ← often exposed
├──────────────────────────────────────────┤
│ Account Control (reset, admin, support)   │  ← jurisdiction & access
├──────────────────────────────────────────┤
│ Legal Power (orders served on provider)   │  ← foreign courts
└──────────────────────────────────────────┘

The Sovereign Decision

At the end of the meeting, we thanked the vendor. We requested their answers in writing, including key custody, privileged access pathways, metadata retention, and legal jurisdiction across all subprocessors.

They offered another brochure.

We returned the contract unsigned.

Encryption is welcome. Immunity is not granted. Our duty is not to feel safe—it is to be governable, auditable, and able to exit.

That is what sovereignty looks like in municipal IT.

FAQs

Is end-to-end encryption enough for municipal data?

It is necessary in some cases, but it is not sufficient. The provider’s jurisdiction, account control, and metadata still matter.

What should we ask a vendor beyond “is it encrypted”?

Who holds the keys, who can reset access, what metadata is retained, and what legal process compels disclosure under their governing law.

What is the single most important safeguard?

Key custody we control, plus an exit path we can execute in 30 days. Without that, encryption becomes ceremonial.