Zhivko Todorov
ALL CASE STUDIES

CASE 33 · QUILL · 2024

ACM PRIVATE CAmTLSCERTIFICATESIOT

A private CA hierarchy that engineers can actually use.

An industrial IoT company had a homegrown CA running on a single EC2 instance, with a 4096-bit private key on an EBS volume nobody had rotated in three years. Every new device type required a manual signing ceremony. We replaced it with ACM Private CA hierarchy and a self-service signing API.

INDUSTRY

Industrial IoT

DOMAIN

LANDING ZONE

DELIVERED

2024

STACK

ACM PRIVATE CA·KMS·API GATEWAY·LAMBDA·IOT CORE·CLOUDWATCH METRICS

RESULTS

What changed, by the numbers.

CA INCIDENTS

0

180 DAYS POST-CUTOVER

SIGNING CEREMONIES

−93%

AUTOMATED

DEVICE ONBOARDING

−72%

TIME-TO-FIRST-PING

ROOT KEY EXPOSURE

HSM-BACKED

WAS ON EBS

HOW IT WENT

The EC2-hosted CA was a textbook concentration of risk. One server, one key, one person who knew the rotation procedure (and that person had switched teams six months earlier). Auditors had been polite about it. Customers shipping firmware to factory floors had stopped being polite.

We built a three-tier hierarchy in ACM Private CA: a root CA (offline, only used to sign the subordinate), a subordinate CA per device class, and short-lived client certificates issued through an API Gateway endpoint. The root key sat in CloudHSM with no human access. IoT Core consumed the new certificate format directly.

Device onboarding now takes a fraction of the previous time. The original CA was retired with a documented decommissioning procedure (the regulator asked for it). The team’s certificate-related Slack channel went quiet two weeks after cutover. They renamed it #certificate-archaeology.

READY WHEN YOU ARE

Let's get your AWS bill (and architecture) in order.

The discovery call is free. You walk away with at least one concrete idea — even if we never work together.

Or email directly →