Security
Protect historical evidence with effective-time certificate revocation
Design and operate a PKI that distinguishes between valid historical signatures and post-compromise suspect data using CRL and OCSP with effective-time semantics.
Secure your audit trail against key compromise
This page is for CISOs, IT directors, and platform leads facing compliance pressure to ensure that a single security incident does not invalidate years of historical evidence. If you run internal TLS or PKI infrastructure, you must decide how to handle revocation without destroying your audit trail. This page explains how we design a PKI that meets that requirement; it ends with one next step.
Avoid the evidence-integrity gap
Most organizations implement naïve revocation: when a certificate is revoked, every signature ever produced by that certificate is treated as invalid. In a regulated environment, this is catastrophic. If a host signing key is compromised on day four of a seven-day window, a naive revocation policy treats the three days of legitimate, signed logs as untrustworthy. This effectively deletes your historical evidence.
The trade-off is concrete: treating every signature from a revoked certificate as invalid throws away legitimate evidence, while treating none as suspect ignores the compromise entirely.
We design and operate PKI systems that use effective-time revocation semantics. This ensures that signatures dated before the effective time of revocation remain valid, while those dated after are treated as suspect. This distinction allows you to maintain a continuous, verifiable audit trail even after a security incident.
Secure your revocation infrastructure
Revocation mechanisms like OCSP (Online Certificate Status Protocol) and CRLs (Certificate Revocation Lists) are high-value targets. If the revocation responder itself is compromised, the entire trust model is at risk.
To mitigate this, we implement a bounded blast radius. The OCSP responder signs with a dedicated responder certificate that is kept strictly separate from the CA root. This architectural separation ensures that a compromise of the responder does not grant an attacker control over the root of trust. By isolating the responder’s authority, we ensure that the infrastructure used to signal compromise does not become the primary vector for a total system collapse.
Align PKI with NIS2 and CRA requirements
Modern regulatory frameworks demand more than just encryption; they demand technical resilience and verifiable integrity. Under the NIS2 Directive (EU) 2022/2555, Article 21 requires robust risk-management measures, including incident handling and supply-chain security. Similarly, the Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) mandates effective vulnerability handling and coordinated disclosure for products with digital elements.
A PKI that cannot distinguish between valid historical data and compromised data fails to meet the technical standards for vulnerability handling and incident reporting required by these regulations. We design PKI architectures that provide the granular, time-aware revocation necessary to satisfy these EU-wide mandates.
By implementing effective-time semantics and isolated responder roles, your organization moves from a reactive security posture to a defensible, audit-ready state.