Key custody
Bring your own keys, or trust ours — explicitly
Key custody is a deliberate decision, not a buried implementation detail. We default to platform-managed keys for the customers who want simplicity, and we are building a customer-managed pathway (BYO KMS) for the customers whose compliance posture requires that signing material never leave their environment.
Executive summary
Today, document-signing keys are X.509 certificates with private keys encrypted at rest using AES-256-GCM, decrypted only inside the signing path, and never logged. This is the right model for most customers. For customers whose compliance posture requires that signing material never leave their HSM, we are building AWS KMS-backed signing — the private key resides in the customer's KMS, we hold only the key reference, and every signature is an authenticated KMS API call.
Our commitments
Five rules for key custody
Plaintext keys never live outside a process boundary
Decryption happens inside the signing path. Keys never reach disk in plaintext, never enter logs, and are explicitly redacted from Inspect and telemetry.
Customer-managed keys are a real option, not a footnote
BYO AWS KMS support is in active development. The KMS key ID is the only thing we store; signing is a KMS API call, and the customer can revoke our access at any moment.
Key rotation is auditable and non-disruptive
Old documents remain verifiable with the certificate that signed them. New documents use the new certificate. We never re-sign retroactively.
Certificate lifecycle is auditable
Upload, activate, and internal revocation events are recorded as hash-chained audit entries. The audit trail is the source of truth for certificate status.
Customer-uploaded certificates are honored as-is
A cert from your own CA is signed by your CA — we do not re-issue or re-sign. Your trust chain remains intact and independent of EngineeringID.
Implementation — platform-managed keys (default)
How keys are stored today
The full picture
What is built, what is being built, and what we chose not to build
Live today
Field-level AES-256-GCM private key encryption
LiveSigning certificates carry encrypted private keys; decryption happens inside the signing path only.
Bring-your-own-certificate
LiveCustomers can upload a cert from their own CA; we never see the source of trust, only the cert itself.
Audit-logged certificate rotation
LiveEvery cert lifecycle event (upload, activate, revoke) is a hash-chained audit event with actor and timestamp.
Building now
AWS KMS-backed signing (BYO KMS)
Building nowCustomer-managed signing keys resident in the customer's AWS KMS. We hold only the key ID; signing is an authenticated KMS API call. The customer revokes our access by removing the IAM grant.
KMS provider records, AWS SigV4 client, and signer module are scaffolded. Production launch pending end-to-end audit and customer onboarding pilot.
Per-organization key isolation
Building nowOrg-scoped boundaries for field-level encryption so a compromise in one tenant cannot decrypt another.
Roadmap
Azure Key Vault and Google Cloud KMS
RoadmapSame pattern as AWS KMS: customer-resident keys with API-only access. Following AWS KMS once that is GA.
Post-quantum signing keys
RoadmapCRYSTALS-Dilithium primitives are compiled into our Rust NIF. Production signing callers and schema columns are not yet wired.
Considered & rejected
Holding plaintext private keys for convenience
Considered & rejectedConvenience is not a security argument. Encrypted-at-rest private keys are non-negotiable.
Why we rejected it: caching the plaintext for performance is a way to keep the key in memory longer than the signing operation that needed it. The right answer is: decrypt, sign, drop. The performance cost is one symmetric decryption per signature. We pay it.
Self-managed CA for customer signing certificates
Considered & rejectedA CA only EngineeringID trusts is no better than self-signed.
Why we rejected it: customers who want CA-issued signing material should use their existing CA — DigiCert, Sectigo, or a private CA they control. Us spinning up our own intermediate CA is a trust-multiplication problem we should not take on.
Key escrow for regulatory compliance
Considered & rejectedEscrow is a key-disclosure mechanism, not a regulatory requirement. We are not building one.
Why we rejected it: regulators ask for audit trails and revocation, not for the private key. Escrow creates a single point that, once compromised, gives every signature ever made. Our customers' obligation to regulators is met by the audit chain and the revocation surface, not by handing keys over.
Auto-rotating signing certs without customer involvement
Considered & rejectedA signing key is a legal identity. Rotating it without explicit customer action is a property change we have no business making.
Why we rejected it: data encryption keys can rotate silently because the wrapped data does not care which key wrapped it. Signing keys are different — they are tied to the engineer's professional identity and to the seals already in the world. Rotation is a deliberate act, audit-logged, with customer approval.
Compliance mappings
Controls this surface satisfies
Data Transmission and Disposal
Cryptographic erasure on key destruction
Key management
Lifecycle: generation, storage, rotation, archival, destruction
Recommendations for Key Management
Algorithm choice and key sizes per Table 2
Encryption and Decryption
Encrypted-at-rest signing keys with field-level wrap
For compliance teams
Questions you do not need to call to ask
Where exactly are private keys stored today?
Can an EngineeringID employee sign a document on my behalf?
When does BYO AWS KMS launch?
If I use BYO KMS, what does EngineeringID actually hold?
How is rotation logged?
What digital signature formats do you produce?
Your keys, your custody, our integration
Talk to our security team about whether platform-managed or BYO KMS fits your compliance posture.