Records that must verify for a decade
Contracts, filings, clinical records, audit packages. The retention period is longer than the lifetime of any single signature algorithm on the standards timeline.
ANKASecure© produces digital signatures whose algorithm is selected by the tenant’s policy rather than by the application — classical, post-quantum (ML-DSA, SLH-DSA, FALCON) or composite signatures requiring both components to verify — and timestamps them against any RFC 3161 authority under a per-tenant usage policy (required, optional or disabled) beneath a deployment ceiling. The timestamp token is embedded in the signature as a JAdES B-T profile (ETSI TS 119 182-1) in JWS JSON Serialization, and verification checks signature and timestamp together. When policy retires an algorithm, the RESIGN operation re-signs the existing signature under the new one and records the lineage in a signed, tamper-evident audit chain. ANKATech is not a qualified trust service provider, and the platform evidences records without archiving them.
A signature is only as old as its algorithm. Make it outlive it.
A contract signed today has to verify in 2036, and the algorithm that signed it may not be acceptable by then. ANKASecure© signs under policy — classical, post-quantum or both — timestamps the signature against the authority you trust, and re-signs it when the policy says the algorithm has aged. Every step is in the chain.
Head of legal operationsCompliance officerCISO
Is this you
Three ways this lands on your desk
A signature algorithm on a deprecation clock
RSA and ECDSA signatures have a date on them now. Everything signed with them has to be re-anchored before that date, or explained to an auditor after it.
An auditor asks for proof of when, not only who
A signature proves identity. It does not prove the moment. Without an independent timestamp, “this was signed before the key was compromised” is an assertion, not evidence.
Who signs this: A head of legal operations or a compliance officer who owns records with a long retention, and a CISO who owns the algorithms those records depend on. If the answer to “will this still verify in ten years?” is “probably”, this is the conversation.
How it works
Four moves, none of them a rewrite
The application asks for a signature. Policy chooses the algorithm, the timestamp authority and the profile; the application never learns which.
Sign under policy
The algorithm comes from the tenant’s policy, not from the application: ML-DSA, SLH-DSA, FALCON, the classical families, or a composite signature that pairs a classical and a post-quantum component and requires both to verify. Changing the algorithm is a policy update.
- ML-DSA
- SLH-DSA
- composite signatures
- policy-selected
Timestamp against the authority you trust
Any RFC 3161 timestamping authority — commercial, national or your own. Whether a timestamp is required, optional or disabled is a policy per tenant under a deployment ceiling, so a regulated tenant cannot sign without one.
- RFC 3161
- REQUIRED / OPTIONAL / DISABLED
- per-tenant policy
Carry the timestamp in the signature
The timestamp token is embedded in the signature itself as a JAdES B-T profile (ETSI TS 119 182-1), in JWS JSON Serialization, so the proof of when travels with the proof of who. Verification checks both.
- JAdES B-T
- ETSI TS 119 182-1
- JWS JSON
Re-sign when the algorithm ages
When policy retires an algorithm, ANKASecure© re-signs the existing signature under the new one — the RESIGN operation — and records the lineage in the audit chain, so the new signature is verifiably the successor of the old one.
- RESIGN
- signed audit trail
- hash chain
Fifteen minutes
What you will actually watch
Live, on a real deployment, against a timestamping authority you name. Nothing in this list is a mock-up or a roadmap item.
A document is signed. The application asked for a signature; policy chose ML-DSA.
The signature is timestamped against your RFC 3161 authority. The token is inside the signature, JAdES B-T.
Verification: signature and timestamp, both checked, one verdict.
The policy tightens to a composite signature. The document is re-signed; old and new both verify, and the chain links them.
The audit trail: sign, timestamp, re-sign — signed, tamper-evident, with the policy decision beside each.
Your record, checked on the deployment rather than on a slide.
What it rests on
The capabilities underneath, with their state
Shipping
Signing and verification under policy
Classical, post-quantum (ML-DSA, SLH-DSA, FALCON) and composite signature pairings, compact and streaming.
Shipping
RFC 3161 timestamping
Any timestamping authority, exercised live; per-tenant usage policy — required, optional or disabled — under a deployment ceiling.
Shipping
JAdES B-T profile
The timestamp token embedded in the signature (ETSI TS 119 182-1) in JWS JSON Serialization, and JAdES-aware verification.
Shipping
Re-signing without plaintext exposure
RESIGN migrates an existing signature to a policy-approved algorithm, compact or streaming.
Shipping
Signed audit trail
Every sign, timestamp and re-sign recorded in a tamper-evident chain, queryable per tenant, forwardable to your SIEM with the signature preserved.
Shipping
120+ algorithms
The signature families this page names, alongside the encryption families, in one catalogue governed by one policy.
The framework
Where this sits in CAPA
The Cryptographic Control Plane reference architecture describes each pillar through the scenarios it must handle and one practical test. A signature that must outlive its algorithm is the modernization pillar’s long-lived-key scenario, applied to evidence.
03
Primary pillar
Frictionless Modernization
Scenario realised
Correcting long-lived key dependencies
Practical test
“Can the protection of data encrypted years ago be changed today, without the originating application and without plaintext at rest?”
04
Primary pillar
Cryptographic Governance & Compliance
Scenario realised
Enforcing a new enterprise security requirement
Practical test
“Can the organization prove, by querying the control plane, which policy applied to a given operation, and change that policy centrally?”
01
Supporting pillar
Crypto-Agility
Scenario realised
Responding to an algorithm vulnerability
Practical test
“Can the cryptographic strategy change without requiring an application change or release?”
L2L4
Maturity move
From signatures whose algorithm is a property of the application to signatures whose algorithm is a policy, timestamped, and re-anchored by policy when it ages. That re-anchoring without a release is what the reference architecture calls cryptographic agility.
What this does not do
It does not make ANKATech a qualified trust service provider. A signature is as legally qualified as the certificate and the timestamping authority you bring to it; ANKASecure© governs and evidences, it does not accredit.
It does not archive your documents. The signature, the timestamp and the chain are evidence about the record; the record itself stays in your system of record.
It does not certify you. ANKASecure© maps its controls to NIST CSWP 39, the GSA PQC Buyer’s Guide and OWASP and hands you the evidence; the determination is still your auditor’s.
After this
The same installation already does these
No new deployment, no second contract for the platform. The policy that governs signatures governs encryption, and the chain that evidences one evidences both.
Bring the record that must still verify in 2036.
A contract, a filing, a clinical record. Fifteen minutes on a live deployment to sign it, timestamp it against your authority and re-sign it under a stricter policy.
Book the demo