If a trusted timestamp was applied at signing time, verification can still succeed after the certificate expires or is revoked, because the system can prove the signature was valid when it was created. Without that timestamp, the same signed object may fail validation and trigger warning messages that the recipient should not trust the document or code.
What changes when verification happens after expiry or revocation?
A signature does not exist in a vacuum, it is validated against the certificate state at the moment the verifier checks it. If the verifier can prove the signature was created while the certificate was still valid, for example by using a trusted timestamp, the expired or revoked status does not necessarily invalidate the signed object. Without that proof, validation often fails and the recipient should treat the object as untrusted.
What changes is the evidentiary question: the verifier is no longer just asking whether the certificate is currently trusted, but whether the signature can be tied to a point in time when the signer was still authorised to sign. That distinction is central to signed code, signed documents, and any workflow that depends on long-lived trust in a now-changed certificate chain.
This is why expiry and revocation are handled differently from simple verification of a hash. Expiry says the certificate should no longer be used going forward. Revocation says the certificate should no longer be accepted because trust has been withdrawn. A valid timestamp can preserve the historical validity of a signature, but it does not repair a signature that was never valid or was created without an acceptable trust anchor.
Why timestamping is the control that preserves trust
Trusted timestamping gives the verifier a cryptographic record that the signature existed at a specific time, and that time can be checked against the certificate’s validity period and any revocation information available then. In practice, this is what allows signed software packages, signed binaries, and signed legal or policy documents to remain verifiable after the signer’s certificate has aged out.
The important operational distinction is that timestamping preserves proof of past validity, not future authorisation. A timestamped object may still be accepted by some verification tools after revocation or expiry, while a non-timestamped object often cannot be distinguished from one signed after trust was lost. That is why build and release pipelines often treat timestamping as part of the signing process, not as an optional add-on.
For code signing, timestamping also reduces unnecessary re-signing when certificates rotate on a normal schedule. For documents, it helps retain evidentiary value when the signer’s certificate lifecycle has ended. In both cases, the verifier still needs a trusted timestamp authority and a validation policy that understands how to evaluate the signature at signing time rather than only at verification time.
Why the result can still be rejected even with a certificate history
Verification can still fail if the timestamp is missing, untrusted, outside policy, or cannot be linked to the signature in a way the verifier accepts. The same is true if the revocation information indicates the certificate was already invalid at the signing time, or if the signing chain cannot be built reliably. In those cases, the warning message is not noise, it is a signal that the verifier cannot establish historical trust.
For recipients, the practical question is whether the warning reflects an expected lifecycle event or an actual trust break. A certificate expiring after signing is usually normal when timestamping is present. A certificate revoked before signing, a broken chain, or an unsigned timestamp counter-signature is a different condition entirely and should be treated as a higher-risk failure.
Risk and Threat Considerations
Expired or revoked certificates matter because attackers and defenders can both exploit ambiguity in signature validation. If a system fails open, ignores revocation status, or accepts weak timestamp evidence, it may continue to trust objects that should no longer be trusted. If it fails closed too aggressively, it can block legitimate software updates or records and create unnecessary operational disruption.
Failure mechanism: The verifier cannot prove when the signature was made, or cannot trust the timestamp and revocation evidence it relies on. That leaves room for either false acceptance of an untrusted object or false rejection of a legitimate one.
Impact: False acceptance can preserve malicious code, tampered documents, or stale trust relationships. False rejection can interrupt release pipelines, block document processing, and generate warning fatigue that causes users to ignore genuinely important validation failures.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | Certificate validity, expiration, and trusted timestamps depend on sound key and certificate lifecycle handling. |
| Recommendation — Align certificate and timestamp lifecycles so signed objects remain verifiable after planned rotation. | ||
| NIST SP 800-53 Rev 5 | SC-12 — Cryptographic Key Establishment and Management | Signature validity after expiry or revocation depends on managing signing keys and related trust evidence. |
| Recommendation — Manage signing keys and validation evidence so historical signature trust can be established. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Signed-document verification is governed by cryptographic controls and trusted validation practices. |
| Recommendation — Define cryptographic validation rules that preserve signature trust across certificate lifecycle events. | ||
| OWASP ASVS | V11 — Cryptography | Signed object verification and timestamp trust are cryptographic assurance concerns. |
| Recommendation — Verify that timestamping and signature checks are enforced consistently in validation logic. | ||
Practitioner Guidance
What to verify: Confirm that your signing workflow produces a trusted timestamp at signing time and that your verification tooling is configured to evaluate signatures in time context, not only against the current certificate state. For code, check how your platform handles timestamp countersignatures during certificate rollover; for documents, check whether the validation policy retains historical proof of validity.
Decision rule: If the object was timestamped with a trusted service and the certificate was valid when the signature was created, treat post-expiry verification differently from a live-authentication failure. If the timestamp is absent or cannot be trusted, treat the warning as a real trust problem and do not rely on the signed object without further review.
Practitioner takeaway: The key judgment is whether you can prove past validity, not whether the certificate is still current today. Timestamping and revocation handling should be designed together, because that is what separates safe certificate rollover from silent trust loss.
Related resources from NHI Mgmt Group
- What happens when a compromised certificate is not revoked quickly?
- What happens when a leaked secret is not revoked quickly after it is exposed in source code?
- What happens when a user’s access is revoked in the source application after a file has already been downloaded?
- What happens when authorization rules are mixed into application code instead of being centralized?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
