TL;DR: ILM now performs signing and RFC 3161 timestamping itself, with signing profiles, per-operation records, and authenticated timestamping endpoints. That means one inventory, one authorization model, and one audit trail across certificates, keys, secrets, signatures, and timestamps.
Signing and timestamping are usually somebody else’s system. That is why nobody can answer, in one query, which cryptographic operations an organisation performed last month.
Ask a security team where their certificates live and you usually get a clear answer. Ask where their signing keys are, who used them last week, and which timestamp authority stamped the result, and the answer arrives in fragments. Certificates sit in one platform. Signing runs somewhere else. Timestamping is a URL somebody configured years ago.
None of those systems is wrong on its own. However, the seams between them are where governance quietly fails. Each system has its own identity model, its own log format, and its own idea of what an operator is allowed to do.
ILM has been closing those seams for several releases. Certificates came first, then cryptographic keys, then secrets, then cryptographic bills of materials. Signing and timestamping are the latest, and they are the ones that most often live outside the platform.
Signing profiles define how, signing records prove what
Signing in ILM starts with a signing profile. The profile is where the configuration lives: which key, under which token profile, with which constraints. Because the profile is a managed object, it inherits the platform’s authorization model rather than defining a private one.
Then comes the part that makes it operable. Every signing operation produces a signing record. Each signing profile exposes an endpoint listing its records, and the platform dashboard reports signing statistics next to the certificate and key figures already there.
Consequently, “who signed what, when, with which key” is a query rather than an investigation. That distinction matters during an audit, and it matters more during an incident. In practice, a signing capability that cannot produce its own history is a capability you cannot defend.
ILM also implements the Cloud Signature Consortium API as a separate component, so remote signing clients that speak CSC have a standard way in.
Timestamping that speaks the standard your tools already speak
A signature without a trusted time is weaker than it looks. Once the signing certificate expires, verifying that the signature existed while the certificate was valid becomes difficult. Therefore timestamping is not an optional companion to signing; it is part of making a signature durable.
ILM handles timestamping through TSP profiles and a managed timestamping engine. The engine performs the operation, and callable RFC 3161 endpoints expose it. Because those endpoints follow the standard, existing clients and build tooling work without modification.
Access is controlled properly rather than by network position. TSP profiles carry authentication methods and Basic credentials, and a dedicated authentication filter sits in front of the timestamping endpoints. Also, a TSP profile cache keeps the profile lookup off the request path, which matters when a pipeline stamps thousands of artefacts.
What consolidation actually buys you
Platform consolidation is easy to claim and easy to oversell. So here is the concrete version, stated as differences rather than adjectives.
| Concern | Separate systems | One platform |
|---|---|---|
| Inventory | Certificates here, signing keys there, timestamp config elsewhere | One inventory covering certificates, keys, secrets, signatures, and timestamps |
| Authorization | Each system has its own roles and its own idea of an operator | One authorization model, including a read-only auditor role |
| Audit trail | Several log formats, correlated by hand after the fact | Signing records and event history in the same place as certificate history |
| Key custody | Keys duplicated or exported to reach the signing service | Keys stay under their token profile; signing references them |
| Reporting | Partial answers per system | Dashboard statistics across operations |
The key custody row is the one worth pausing on. Whenever a signing service lives outside the system that manages keys, something has to cross the boundary. Usually that something is the key, or a copy of it. Keeping signing next to key management removes the need for that trip.
Where the honest limits are
Consolidation is not the same as replacement, and we would rather be precise about that.
ILM does not replace a hardware security module. Keys still live where your policy says they live, and ILM references them through a token profile. Similarly, ILM does not decide your signing policy or your cryptographic algorithm choices. It gives those decisions one place to be configured and one record of being applied.
Nor does moving signing into the platform remove the need for qualified trust services where regulation demands them. If a use case requires a qualified timestamp from a qualified provider, that requirement does not change because your platform can also stamp times.
An umbrella is useful because it covers everything at once, not because it replaces the sky.
Getting started
If you already run ILM, both capabilities are configuration rather than deployment. Create a signing profile against an existing token profile, and create a TSP profile with an authentication method. Then point a client at the RFC 3161 endpoint and check that a signing record appears.
If you are evaluating ILM, signing and timestamping are a reasonable place to start precisely because they are usually separate. Configure them alongside a handful of certificates, and watch whether a single dashboard can answer questions that previously needed three systems.
Key Takeaways
- Signing profiles hold the configuration; signing records hold the evidence, listable per profile and summarised on the dashboard.
- Timestamping runs on a managed engine behind callable RFC 3161 endpoints, so existing tooling works unchanged.
- TSP profiles carry authentication methods and Basic credentials, with an authentication filter in front of the endpoints.
- Keeping signing next to key management removes the need to move keys to reach a signing service.
- ILM does not replace an HSM, set your cryptographic policy, or remove regulatory requirements for qualified trust services.
Signing and timestamping arrived across the 2.18.0 and 2.19.0 releases — see what else 2.19.0 changed. For the wider picture of what the platform covers, read 10 things you can build with ILM and why trust lifecycle management must include secrets. To talk through a signing or timestamping deployment, get in touch.
