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.
A one-person company is a fair question to ask, and the architecture is the answer. Your keys live in an AWS account that’s yours to take under a published fee, exercisable as long as the account is up to date on payments. There’s no support backdoor anyone could phish out of me, because one was never built. The custody model stands on its own.
SanctiKey is designed to run autonomously: no hands on a keyboard are required for customers to get the intended result. A paid checkout provisions the account by itself. Keys and certificates are issued, revoked, and audited through the API. The jobs that reconcile, expire, and shred run on a schedule, under alarms that fire when a run goes missing and not just when one fails, because a backstop that quietly stopped running is the failure you never hear about. That design is deliberate, because besides running SanctiKey I also work full time.
Every service component carries its own alerting, designed against its failure modes and tested against the edge cases before launch. Detection does not depend on anyone watching a dashboard. What still runs through me is written down in the limits section of the security model: infrastructure changes I apply by hand, support that’s one inbox, every administrative role held by the same person.
The background
The background, and why it is relevant to key custody.
Dissect my resume and it tells the story of SanctiKey’s creation. Each component of the platform grew out of a major project I worked on, and out of the cryptography that project demanded.
- 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. That work is why the RED section of the compliance page addresses secure storage mechanisms and signing key custody rather than reciting the article numbers.
- Matter compliance work
- Device attestation, the PAA and PAI chain, and the Distributed Compliance Ledger. That work is why 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 why it names the conformance check still being wired rather than rounding the chain up to shipped.
- 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. The failure modes this site addresses are ones I have designed around directly, not hypotheticals collected from incident reports.
- 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. Key custody is not theoretical for me, and the custody model on this site reflects that experience.
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.
The compliance work is why I expect the CRA deadline to be the point where this starts mattering commercially. The cloud security work is why the isolation model looks the way it does.
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.