Who builds this
SanctiKey is one person, and that person is me.
I’m Brad Duhon. I built SanctiKey and I run it. There’s no team behind the logo: the support address reaches me directly, and my name is the one on the incident response plan. If you’re evaluating an out-of-band key store, you should know exactly who operates it.
Doubt is a good first response to a one-person custody company. It’s also why I built the product to run without a person. You shouldn’t have to trust an operator’s presence for the custody model to survive. Your keys live in an AWS account that is yours to take under a published fee, any time the subscription is valid and paid up, for any reason you like. There is a reason no support backdoor exists for anyone to phish out of me, and the reason is that one was never built. The custody model stands on its own.
SanctiKey runs without hands on a keyboard. A paid checkout provisions the account by itself, keys and certificates are issued, revoked, and audited through the API, and the jobs that reconcile, expire, and shred all run on a schedule. The alarms over those jobs fire when a run goes missing, not just when one fails: a job that errors makes noise on its own, a job that never started is silent, so the silence itself is what trips the alarm. That design is deliberate. A custody system that needs its operator awake is broken by design.
Every component carries its own alerting, shaped against its own failure modes, tested against the edge cases before launch, watching whether anyone is watching or not. The parts that still run through me are not hidden, I wrote them down in the limits section of the security model: every change reaches production through the same built, reviewed, and submitted pipeline with me as the only engineer in that loop, support that is one inbox, every administrative role held by the same person. If you read one thing before trusting me, read that.
The background
The background, and why it is relevant to key custody.
Take my resume apart and you’ll find SanctiKey already in it, one component at a time, each one grown out of a project I shipped and the cryptography that project demanded of me.
- BLE encryption specification under the EU Radio Equipment Directive
- I authored a Bluetooth Low Energy encryption specification for a connected product line under the RED cybersecurity requirements. When the compliance page’s RED section talks about secure storage mechanisms and signing key custody instead of reciting article numbers, that’s this work talking.
- Matter compliance work
- Device attestation, the PAA and PAI chain, and the Distributed Compliance Ledger. The Matter section of this site separates the attestation route a vendor can operate from the parts of the program that never leave the vendor, and it names the conformance check still being wired instead of rounding the chain up to shipped, because I’ve watched what happens when someone rounds up.
- GDPR deletion orchestration
- I built the orchestration that erases a person across a distributed system. That is where the difference between an encryption policy and an enforced key lifecycle stops being academic, and it is the origin of the enforced lifecycle SanctiKey applies to every key.
- Eight years in IoT product security
- Threat modelling, secure boot chains, provisioning, and key management for connected devices that shipped in volume, which means the failure modes this site addresses are ones that have already tried to happen to products I was responsible for.
- Cloud security standards work across two organizations
- AWS organization design, IAM boundaries, and the blast-radius analysis that produced the trust-axis argument this product is built on, applied across two organizations. The isolation model on the security page is the direct result.
- YubiHSM and HSM migration work
- Hands-on work with hardware security modules, including migrating key material between them, a procedure with no undo and no one to call if the ceremony goes wrong. You do it once and custody stops being a theory.
Why I built this
Every compliance mandate I worked through followed the same pattern, and the CRA is the largest yet.
The Radio Equipment Directive, GDPR, Matter, and now the Cyber Resilience Act each arrived the same way: a deadline, usually there for good reason, with no path to a deliverable, landing on top of everything the team was already committed to. The companies through the door first end up as QA for the requirement itself, because the enforcing body is still working out what it will accept.
The assessor’s questions are all fair ones: why that cipher suite, why that protocol, why that architecture, where are the logs, where is the justification, what does the decision tree for access look like. Any single one is straightforward to document and defend. All of them at once, against a date, with a small security team that is also carrying privacy and compliance, is a bottleneck. The engineering was never the part that was struggling.
The Cyber Resilience Act reaches every product with digital elements sold into the EU, carries a ten-year documentation duty, and imposes reporting obligations that reach backwards to products already on the market. The same teams are about to face the same questions again, at a scale where buying a hardware security module and hiring someone to run it is not a proportionate answer for most of them.
None of the controls that fix this are novel: non-extractable keys, a real CA hierarchy, rotation that cannot be forgotten, an audit trail written to be read by someone outside your company. What did not exist was a version a five-person hardware company could buy on a card, held in an account that a compromise of their own cloud cannot reach.
Everything above is why I believe the CRA deadline is where this starts mattering commercially. I’ve stood inside that bottleneck, and I’d rather be the relief for it this time.
Elsewhere
Where else to check my work.
- brad-duhon.com for the professional record.
- The security model is honestly the version of this page that matters most, since ninety numbered controls and a known-limits section tell you more about how someone works than a biography does.