Security
Security at CertGov
CertGov governs the certificates that protect your infrastructure, so it has to be trustworthy itself. This page describes how we protect your data, where it lives, what access CertGov has to your environment, and how to reach us about security.
Updated
Your private keys stay with you
For Kubernetes certificates, cert-manager generates the key pair inside your cluster and the cert-manager external issuer sends CertGov only the certificate signing request (CSR): the public key and subject. Private keys for those certificates never leave your cluster.
For network devices and private infrastructure, the open-source connector runs inside your network and connects outbound to CertGov, so no inbound firewall rules are needed. CSRs for internal certificates can be signed by your own CA on premises.
Data protection
- Encryption in transit: TLS 1.2 or higher for all connections.
- Encryption at rest: customer data is encrypted at rest, and sensitive credentials and private keys held by CertGov are stored encrypted with AES-256-GCM.
- Passwords: hashed with bcrypt.
- Backups: regular, encrypted, and integrity-verified.
- Availability: high-availability infrastructure with redundant nodes.
- No model training: we don't use your certificate data or customer data to train machine learning models.
Access control
- Role-based access control with least-privilege principles for staff and system components.
- Scoped API keys, so automation gets only the permissions it needs.
- Multi-factor authentication, with options to enforce it for your accounts.
- Single sign-on through any OIDC provider, including Okta, Microsoft Entra ID, Google Workspace, Keycloak, and Ping Identity.
- IP allow-listing for dashboard access.
A tamper-evident audit trail
Every certificate request, approval, rejection, issuance, and renewal is written to an audit log in which each record's SHA-256 hash covers its content and the previous record's hash, so any alteration is detectable. Logs can be exported as CSV or JSON, and on Enterprise they can be streamed to your SIEM.
Data residency
Each organization is pinned to one region: US East (Virginia) or EU West (Frankfurt, Germany). Certificates, keys, and audit data stay in that region. Some operational data, such as billing and email delivery, is processed by US-based sub-processors under appropriate safeguards. For full control, CertGov can be self-hosted in your own environment, including air-gapped networks.
Sub-processors
CertGov uses the following sub-processors to deliver the service:
| Sub-processor | Purpose | Location |
|---|---|---|
| Akamai / Linode | Cloud infrastructure hosting the service | USA, EU (Frankfurt) |
| Cloudflare | DNS, CDN, DDoS protection, TLS termination, load balancing | USA / Global |
| Let's Encrypt / ZeroSSL | ACME public certificate issuance for customer domains | USA |
| Resend | Transactional email | USA |
| Stripe | Payment processing and billing | USA / Global |
| crt.sh (Sectigo) | Certificate Transparency monitoring for discovery | USA |
We notify customers at least 14 days before adding or changing a sub-processor. See the Data Processing Agreement for the full terms.
Incident response
If we confirm a security incident affecting your personal data, we notify affected customers without undue delay and, where feasible, within 72 hours of becoming aware of it, with the details available and the measures taken.
Data retention and deletion
When you close your account, account, certificate, and configuration data is deleted within 90 days. Billing records may be kept for up to 7 years for accounting and legal requirements. See the privacy policy for details.
Open source you can inspect
The components that run inside your environment, including the cert-manager issuer, the network device connector, and the discovery agent, are open source under the Apache 2.0 license and public on GitHub. You can review exactly what runs on your infrastructure.
Compliance and assurance
CertGov does not yet hold its own SOC 2 report or ISO 27001 certification. We're happy to complete your security questionnaire and sign our DPA. CertGov also helps you meet your own obligations: see compliance for framework reports covering SOC 2, ISO 27001, PCI DSS, and HIPAA.
Contact and vulnerability reports
To report a vulnerability, request a security questionnaire, or ask a security question, email security@certgov.app. Our security.txt lists the same contact. Please include enough detail for us to reproduce any issue, and give us reasonable time to respond before disclosing it publicly.