External Key Management Service: Keep Your Encryption Keys, Keep Control of Your Data

[Marco Braun]

More and more companies are moving their workloads to the cloud - but for many of them, one thing has always been a dealbreaker: who holds the encryption keys? With the Australia release, ServiceNow introduces External Key Management Service (EKMS), a feature that puts that control squarely in the customer's hands.

Why Key Control Matters

Security teams in regulated industries have been asking the same question for years: if our data lives in a cloud platform, how do we make sure we can cut off access to it when we need to? The answer comes down to who owns the encryption key. If the cloud provider holds it, the customer has to trust that provider completely. If the customer holds it, they're in the driver's seat.

Earlier ServiceNow encryption options addressed parts of this problem. Field Encryption let customers manage keys, but those keys still lived inside the ServiceNow environment - so there was no real way to "pull the plug" from the outside. Edge Encryption and Database Encryption – Customer Controlled Switch (DBE CCS) gave customers external control, but came with complex setups, fragile connections, and a lot of implementation work.

EKMS works differently. Customers create and store their own key. For the purposes of this article, we’ll call the customer’s key encryption key - “KEK2” - in their own AWS Key Management Service (KMS). KEK2 never leaves AWS. Here's what happens under the hood: ServiceNow creates an internal AES-256 key encryption key - called External Key Encryption Key (EKEK) - that controls Data Encryption Keys (DEKs) for Field Encryption. EKEK is wrapped with another ServiceNow AES-256 key encryption key – called Instance Root Key (IRK) - and sends the IRK wrapped EKEK to the customer's AWS KMS. AWS then wraps the whole thing again with the customer's KEK2 and sends it back to ServiceNow. The end result is the ServiceNow EKEK ultimately wrapped by the AWS KEK2 and stored in ServiceNow, but the key material is useless without the customer’s KEK2 in AWS to unlock it.

This gives customers a straightforward kill switch. If they disable or delete their key in AWS, ServiceNow can no longer unwrap the EKEK, which means the DEKs that actually protect field-level data can't be decrypted either. The data becomes completely inaccessible. A background job checks the key status every 30 minutes to ensure connectivity and the cache where decrypted DEKs reside is flushed every 4 hours.

Built to Withstand Quantum Computing

Quantum computing is still years away from being a practical threat to symmetric encryption, but the security community isn't waiting around. The biggest concern right now is what's called "harvest now, decrypt later" - the idea that bad actors are already collecting encrypted data today and planning to crack it once quantum computers are powerful enough.

EKMS is designed to hold up against this threat. The entire key wrapping chain uses AES-256 symmetric encryption, which both the National Institute of Standards and Technology (NIST) and the Internet Engineering Task Force (IETF) consider safe from quantum attacks. The best-known quantum attack against symmetric encryption - Grover's algorithm - would cut the effective strength of AES-256 down to about 128 bits. That's still a massive amount of security, well beyond what any computer, quantum or otherwise, could realistically break.

What this means in practice: the EKEK that gets sent to the customer's AWS KMS is already wrapped in AES-256 encryption (the IRK) before it ever leaves ServiceNow. Even if someone were to intercept the data in transit - say, by somehow breaking TLS - all they'd get is an AES-256 encrypted blob, not usable key material.

This isn't a feature that was added on top after the fact. It's built into how the architecture works. Because every key wrapping step uses AES-256, the whole chain is quantum-resistant by default. Down the road, when new post-quantum algorithms like ML-KEM (NIST FIPS 203) get formally built into transport protocols by IETF working groups, ServiceNow is planning to adopt them too. But the protection at the data layer is already there today.

The Natural Next Step for Field Encryption

EKMS is really the upgrade that Field Encryption needed to meet the expectations of the most security-focused customers. Field Encryption Enterprise already provides strong protection - it encrypts data at the column level, and Module Access Policies let admins control exactly which roles can see decrypted data. What EKMS adds is the ability to move the master key outside of ServiceNow entirely.

The setup also reflects lessons ServiceNow learned from earlier encryption products. Where older solutions needed proprietary proxy servers or on-premises middleware, EKMS simply connects to cloud services - ServiceNow and AWS KMS - through standard API calls. All a customer needs is an AWS KMS key, an IAM user with three permissions (DescribeKey, Encrypt, Decrypt), and a short configuration workflow in their ServiceNow instance. No extra servers, no middleware, no complicated infrastructure.

The architecture is also built to grow. The Australia release supports AWS KMS with Field Encryption. Future releases are planned to add support for additional key storage providers, as well as extending the capability to Cloud Encryption. The long-term vision is simple: one pattern - your key, your KMS, your control - across all of ServiceNow's encryption capabilities.

The Bottom Line

EKMS changes the encryption conversation for ServiceNow customers in three important ways.

First, it gives you real key ownership. Your master key stays in your AWS KMS, governed by your IAM policies, visible in your CloudTrail logs. ServiceNow can't touch your encrypted data without your key being active and available.

Second, it protects your data against quantum threats right now, not as a future promise. The AES-256 key chain is resistant to known quantum attacks, which means data you encrypt today stays safe against the harvest-now-decrypt-later scenario.

Third, it's easy to set up. Going from "we need external key control" to "we have external key control" is a configuration task, not a major deployment project.

For organizations that want the benefits of a cloud platform without giving up control over the keys that protect their most sensitive data, EKMS is a big step forward.

EKMS is available as part of the ServiceNow Platform Encryption subscription bundle or the ServiceNow Vault bundle.

Demo Video

Watch a 3 minute demonstration of the EKMS feature below:

https://app.guidde.com/share/playbooks/tz3MitmMQLuPhTQJEgXZKU?origin=Hei2fxsw2HTnYNGRYzIXJWCJy5w2

For full setup instructions, configuration details, and operational guidance, visit the official [External Key Management Service documentation](https://www.servicenow.com/docs/r/platform-security/ekms-external-key-management.html).