Expiry alone does not tell you whether the document was signed before the certificate lapsed, whether the certificate was revoked earlier, or whether the content was tampered with after signing. That creates false confidence and can lead teams to reject valid records or accept compromised ones. Proper verification needs signature validation, timestamp evidence, and revocation checking together.
Why This Matters for Security Teams
When teams rely on expiry alone, they confuse certificate validity with proof of trustworthy signing. A document can be signed before a certificate expires, remain valid if time-stamped correctly, or be compromised if revocation happened earlier and no one checked. That gap matters in legal, procurement, financial, and software supply chain workflows where a signature is treated as evidence. Current guidance suggests treating expiry as one signal, not the decision itself.
This is the same pattern that appears in broader NHI governance: static credential checks miss the real question of whether the identity was authorized at the moment of use. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, which shows how often identity assurance is assumed rather than verified in practice. Related risks are covered in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the Top 10 NHI Issues, both of which emphasise lifecycle control and verification over assumptions.
In practice, many security teams discover signature validation failures only after a record is disputed or a signed artifact has already been accepted downstream.
How It Works in Practice
A defensible verification flow checks three things together: the signature cryptographically matches the document, the signing certificate was valid at the signing time, and revocation status was acceptable when the signature was evaluated. That usually means combining signature validation, trusted timestamp evidence, and certificate status checking through OCSP or CRL, depending on the environment. The point is not to extend trust forever, but to anchor trust to a precise moment.
For software and document workflows, this is especially important where signed packages, signed PDFs, notarized records, or code-signing artifacts move across teams and time zones. The NIST SP 800-53 Rev 5 Security and Privacy Controls supports integrity and authenticity checks, while the OWASP Non-Human Identity Top 10 is a useful reference for understanding why cryptographic trust must be paired with lifecycle and revocation discipline.
- Validate the signature against the full document, not just its metadata.
- Confirm whether a trusted timestamp proves the signing event occurred before expiry.
- Check revocation state at the relevant time, not only at the time of opening the file.
- Preserve audit evidence so later reviewers can reproduce the decision.
Teams handling document archives should also connect this to NHI lifecycle thinking, because long-lived signing keys and stale trust roots behave like any other unmanaged identity. The operational lesson is mirrored in Ultimate Guide to NHIs — Static vs Dynamic Secrets and the NHI Lifecycle Management Guide, where the emphasis is on short-lived trust, rotation, and verifiable state. These controls tend to break down when timestamping is absent and revocation data is unavailable to the verifier.
Common Variations and Edge Cases
Tighter verification often increases operational overhead, requiring organisations to balance stronger assurance against archive performance, offline access, and retention obligations. That tradeoff becomes visible in legacy systems, air-gapped environments, and long-term records management, where online revocation checks may not be possible.
There is no universal standard for every document type. Some ecosystems rely on embedded timestamps and long-term validation formats, while others accept only live status checks. Best practice is evolving, but the consistent rule is that expiry alone should never be the deciding factor. For high-value records, maintain evidence of the signing time, signer trust chain, and revocation state so a future reviewer can reconstruct the trust decision.
Edge cases also matter when certificates are renewed under the same subject name, when signing services use delegated keys, or when a document is re-packaged after signing. In those cases, it is easy to misread a valid certificate as proof that the whole artifact is still trustworthy. The safest operational approach is to treat signature assurance as a chain of evidence, not a single date check, and to align that chain with documented identity governance practices in NHI-heavy environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 | Expired certificates still need revocation and integrity validation. |
| NIST CSF 2.0 | PR.DS-6 | Signed documents require integrity checks beyond simple expiry review. |
| NIST SP 800-63 | Digital identity assurance depends on proof at the asserted time. | |
| NIST AI RMF | Risk governance should account for stale or invalid trust signals. | |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Trust should be re-checked at decision time, not assumed from expiry. |
Use cryptographic validation and timestamp evidence before accepting signed records.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
