Slack EKM is not end-to-end encryption. Here's the architecture, in plain English.

If you've read a sales deck claiming Slack Enterprise Key Management is "end-to-end encryption," the deck is wrong — and not just slightly. The two architectures sit on opposite sides of the cryptographic-vs-administrative server-blindness line. This post walks through what EKM actually does, sourced from Slack's published documentation, and what it doesn't.

The summary: EKM is envelope encryption with Slack-side decrypt on every operation that touches message content. The customer's KMS is consulted during the encrypt/decrypt pipeline; Slack's servers still see cleartext at the moment a search query runs, a message is rendered, an AI feature reads a thread, or an eDiscovery export is generated. EKM's two real benefits are an audit trail (every Slack subsystem that decrypted is logged) and a kill switch (revoking the KMS key locks Slack out of future operations on already-stored ciphertext). Both are meaningful. Neither is end-to-end encryption.

Envelope encryption is the standard pattern for managing keys at scale: every piece of data (file, message, blob) is encrypted with a fresh per-object data encryption key (DEK); the DEK itself is then encrypted under a master key encryption key (KEK) and stored alongside the ciphertext. To read the data, you fetch the encrypted DEK, decrypt it with the KEK, and use the resulting DEK to decrypt the data.

The trick of envelope encryption is that the high-value master key (the KEK) is consulted once per object access; the bulk encryption work happens with the much cheaper per-object DEK. AWS KMS, Google Cloud KMS, and Azure Key Vault are all envelope-encryption-friendly designs.

What matters for EKM: the KEK is what lives in the customer's KMS. The DEKs still pass through Slack's servers in plaintext form whenever Slack needs to read the data.

Without EKM (default Slack posture): Slack generates DEKs server-side, wraps them under Slack's own KMS-held KEK, stores wrapped DEKs alongside ciphertext. Slack's services decrypt as needed by calling Slack's internal KMS. The customer has no visibility into when and why Slack decrypted what.

With EKM enabled: the customer provisions a CMK (Customer Master Key) in their own AWS KMS account. Slack's encryption pipeline is reconfigured to call the customer's KMS for KEK operations (wrap/unwrap of DEKs) instead of Slack's own. Every wrap/unwrap call is logged by AWS CloudTrail in the customer's account, giving a per-event audit trail keyed to which Slack subsystem decrypted what and when. The customer can revoke the CMK; from that moment, Slack can no longer unwrap stored DEKs and the ciphertext at rest becomes unreadable to Slack.

What does not change with EKM: Slack's services still decrypt on every operation that touches message content. Search, AI, threading, mentions, integrations, eDiscovery — all of them require Slack's servers to obtain plaintext at runtime. EKM gives the customer's KMS a role in supplying the unwrapped DEKs; it does not make Slack's runtime servers blind to the cleartext.

A customer evaluating EKM is usually doing it because of one of three concerns: legal-process exposure, breach-blast-radius, or insider-access risk. EKM's effect on each is meaningfully different.

Legal process: a subpoena, search warrant, or NSL served on Slack for a customer's data will yield cleartext, because Slack's runtime still has the plaintext path. EKM's audit log shows the customer that a decrypt happened, but the data is already produced. EKM is not a defense against legal compulsion of content.

Breach blast-radius: a Slack-side breach that exfiltrates at-rest ciphertext + wrapped DEKs requires the attacker to also compromise the customer's KMS or Slack's KMS-call pathway to decrypt. This is a real protection. EKM reduces the at-rest blast radius. It does not reduce the runtime breach blast-radius — an attacker on a live Slack production server decrypts in the normal pipeline.

Insider access: a Slack engineer or support agent who wants to read a specific channel still can. The runtime decrypts; the engineer reads the cleartext. The customer's CloudTrail will eventually show the access, which provides post-hoc accountability — but the access happened.

If you use Slack — even with EKM — and Oracle uses Slack, Slack has access to Oracle's data. The same is true of any other Slack customer. Each customer's encryption is administered by Slack's runtime; the keys live in different KMSes but the runtime that operates on the content is shared. That's not a security flaw of Slack's design; it's the design.

The honest framing in vendor evaluations is: "the workspace tool can read every message in service of every feature." Whether the operational guardrails (audit logging, KMS revocation, employee access policy, regional residency) are sufficient for your risk profile is the actual question. EKM strengthens the audit and revocation halves; it doesn't change the underlying access pattern.

Vendors that genuinely want to make the runtime blind to cleartext have to architect for end-to-end encryption from the outset — keys generated on user devices, ciphertext only on servers, server-blind feature design. That's a different product, not a configuration toggle.

Two scenarios where EKM is genuinely the right buy:

Compliance frameworks that mandate customer-held keys at rest. Some regulatory regimes (or contractual obligations from a customer's customers) require demonstration that data at rest is encrypted under customer-controlled keys with audit and revocation. EKM is built for that requirement. The customer needs the audit trail, accepts the runtime access pattern as normal SaaS behavior, and uses the kill switch as a worst-case incident-response tool.

Forensic accountability for Slack-side access. If the customer wants a structured log of every Slack subsystem that touched the data — for vendor-risk review, internal audit, or post-incident analysis — EKM's CloudTrail integration delivers it. The log doesn't prevent the access; it documents it.

EKM is not the right answer if the goal is "Slack cannot read the messages." For that, the answer is an end-to-end encrypted workspace tool — Koaich is one; Wire is another in the messaging-only segment.

Slack EKM vs. end-to-end encryption is not a difference of degree. It's a difference of who reads what:

Slack EKM: Slack reads every message in service of every feature; customer holds an audit log of when and a kill switch for revoking future reads.

End-to-end encryption (Koaich's model): vendor servers never see cleartext content; cryptographic keys live on user devices; vendor cannot produce content under legal compulsion because no decryption path exists.

Both are legitimate architectures with different trade-offs. EKM keeps the rich server-side feature set; end-to-end gives up some of it for the property of cryptographic server-blindness. The mistake to avoid is treating them as equivalent in a vendor evaluation — they answer different questions.