Revocation has a start time, and it only moves backwards

Business Challenge

“AWS Signer is a fully managed code-signing service to ensure the trust and integrity of your code.” The reason to care about it is the moment it is designed for, which the revocation page names without flinching: “Revocation of a signature becomes necessary when the signing certificate is compromised in some way, for example, if the secret key is publicly disclosed.”

That is the day this post is about. Your signing key is public, every artifact signed with it is suspect, and you need to know precisely which operation stops which thing from running.

1Two revocation operations, and only one has a documented effect on verification

Revoke a signature and the documentation tells you the outcome, per platform:

“Revoking the signature of an AWS Lambda deployment package invalidates it, causing it to fail Lambda signature checks in all Regions of the same partition.”

“Revoking the signature of a container image causes validation to fail if you attempt to deploy the image.”

Revoke a profile and you get one sentence about reach: “Once revoked, a signing profile can no longer be used for creating new signing jobs.”

That is a forward-looking statement. It says nothing about the artifacts the profile already signed — and on the day your key is disclosed, those artifacts are the entire problem.

Fix

If the requirement is "this artifact must stop passing verification", use RevokeSignature, because that is the operation whose effect on verification AWS actually documents. Revoking the profile is how you stop the next signature, not how you stop the last one. Treat them as two steps of one response rather than alternatives.

2Profile revocation is a timestamp, it must be in the past, and it only ever moves earlier

This is the mechanism worth understanding before you need it, because every property of it is a constraint on how you respond.

“Revocation for a signing profile requires an effective start time in the past. The start time cannot be in the future.”

“The effective start time can be changed to an earlier date and time by repeating the revocation, but cannot be revised to a later date and time.”

Three consequences. You cannot schedule a revocation — there is no "stop trusting this profile from Friday". You cannot narrow one once made, only widen it. And widening is the only correction available, which means the safe direction when you are unsure is to revoke from later and walk it back, because the reverse is not a move you can make.

Combined with the blunt warning on the same page — “Revocation is an irreversible action and is recommended only for critical scenarios” — this is a one-way ratchet into the past.

Fix

Decide the effective time from evidence, not from caution. The instinct under pressure is to pick a time safely early, and that instinct is the one you cannot undo. Establish when the key was actually exposed, revoke from there, and accept that you may need to repeat the call with an earlier time once you know more — which the API permits, and is the reason it permits it.

3The default signature validity is 11 years and 6 months

“Specify the Signature validity period in months, days, or years. The default value is 135 months (11 years and 6 months).”

135 / 12 is 11.25 — which is how AWS gets to eleven years and six months, and it is a long time for a cryptographic assertion made by a key you will rotate, a team that will change and a platform that will move on.

The default is defensible: a signature that expires while the artifact is still deployed fails verification, and “Expired signatures will fail on expiry checks instead” of revocation checks, so a short validity trades one failure mode for another. But it is a default rather than a decision, and almost nobody chooses it deliberately.

It also sets the clock on everything else. The retention page: the retention period for a canceled or revoked profile is its signature validity period “plus 6 months”, so with the default “canceled or revoked profiles are deleted after 141 months”. And “Should you configure a shorter validity period, they will be deleted sooner.”

Fix

Set the validity period from how long your artifacts actually live. A Lambda package redeployed monthly does not need a signature valid into 2038. Shortening it bounds how long a compromised profile remains relevant, and the documentation says so directly — the retention follows the validity you choose.

Architecture

A profile that defines the publisher, jobs that produce signatures, and two revocation paths with different documented reach.

One operation's effect on verification is documented. The other's is a timestamp.

What the profile holds, and who holds the keys

“A signing profile is unique AWS Signer resource that you can use to perform signing jobs… Each signing profile designates the signing platform to sign for, a platform ID, and other platform-specific information.”

Key custody is split by workflow, and this is the first thing to establish about your own setup: “Signer manages the code signing certificate and keys associated for only AWS Lambda and Container images workflows. For Internet of Things (IoT) workflows, you can import your own code signing certificate into AWS Certificate Manager.”

So "the signing key was disclosed" means two different incidents depending on the platform. For Lambda and containers the key is AWS's to manage; for IoT it is yours, in ACM, and so is the disclosure.

The two revocation paths, side by side

	Revoke a signature	Revoke a profile
Operation	`RevokeSignature`, or “selecting a signing job in the AWS Signer console”	`RevokeSigningProfile`, or selecting the profile in the console
Documented effect on verification	Lambda: “fail Lambda signature checks in all Regions of the same partition”. Containers: “validation to fail if you attempt to deploy the image”	Not stated
Documented effect on signing	Not stated	“can no longer be used for creating new signing jobs”
Carries a time	No time documented	Yes — “an effective start time in the past”
Correctable	“Revocation is an irreversible action”	Earlier only — “cannot be revised to a later date and time”

The retention rule is the clearest statement of the relationship, and it is on a page about deletion

“When a signing profile is canceled or revoked, we retain the profile for an additional period of time to ensure that any existing signatures created with that profile have expired before it is deleted.”

Read that carefully. The retention period is the profile's signature validity period “plus 6 months” — by default 135 + 6, so 141 months — and AWS keeps the profile that long because the signatures it produced have not expired. The retention policy is evidence that signatures outlive the revocation of the profile that made them.

What the guide does not say anywhere is how one of those signatures verifies during that interval. That is the gap, and it is the thing to establish with AWS for your own platform rather than assume in either direction.

The timers worth having in one place

Timer	Default	Notes
Signature validity period	135 months (11 years 6 months)	Settable “in months, days, or years”
Profile retention after cancel or revoke	141 months	Validity “plus 6 months”; shorter validity means “deleted sooner”
Signing job retention	6 months after signature expiry	Independent of the profile
Revocation check window	6 months beyond signature expiry	After which “Expired signatures will fail on expiry checks instead”
IoT Device Management: profile retention	20 months	Overrides the validity-plus-six rule
IoT Device Management: job retention	20 months	Same override

The revocation check window is the subtle one. “Revocation checks are valid for six months beyond the expiry of a signature. Expired signatures will fail on expiry checks instead.” So a revocation does not need to outlive the signature by much — expiry takes over as the reason verification fails. That is a sensible bound on how long revocation state must be carried, and it means the long default validity is what keeps revocation state alive for a decade, not the revocation itself.

Why This Architecture Holds Up

Making the effective time move only backwards is the right asymmetry

It would be easy to let an operator adjust a revocation window in both directions, and it would be wrong. Narrowing a revocation means re-trusting artifacts you had declared untrusted, which is a decision that should require issuing something new rather than editing something old. A ratchet that only widens cannot quietly restore trust.

The same reasoning explains why the start time “cannot be in the future”. A scheduled revocation is a window in which a profile is both trusted and known-bad, and the service refuses to represent that state at all.

Revocation is addressed by profile version, not just by name

Revocation operates on a profile version rather than a profile name — RevokeSigningProfile takes both a profile name and a profile version, and GetRevocationStatus takes a profile version ARN alongside the job ARN and the signature's timestamp. Those are the inputs the service evaluates a status against; what it does with them is not documented, but the parameter list tells you the version and the signature's time are both part of the question.

It also tells you what to keep: the mapping from artifact to profile version. Without it, a response cannot determine which artifacts a given revocation covers.

And this is why the inventory matters more than the mechanism

On the day a key is disclosed, the question is not "how do I revoke" but "what did this profile version sign, and where is it running". Signer answers the first. The second is your inventory’s job, and it is the one that decides how long the incident lasts.

“Integration with AWS CloudTrail helps you track who is generating code signatures and to meet your compliance requirements.” That gives you the signing events. Mapping them to currently deployed artifacts is your side of the line, and it is the part that decides how long the incident lasts.

Splitting key custody by workflow is honest about what is managed

A fully managed service that quietly managed keys for some platforms and not others would be a problem. Signer states the split plainly — AWS holds the keys for Lambda and container workflows, you import your own into ACM for IoT — which means the answer to "who can disclose the key" is knowable from the platform alone.

Key Architecture Decisions

Decision	Choice	Reasoning
Stopping a specific artifact	`RevokeSignature`	It is the operation whose effect on verification is documented.
Stopping future signing	`RevokeSigningProfile`	“can no longer be used for creating new signing jobs”.
Choosing the effective time	From evidence, then widen if needed	It “cannot be revised to a later date and time”.
Scheduling a revocation	Not possible — plan around it	The start time “cannot be in the future”.
Signature validity period	Set it; do not inherit 135 months	Retention follows validity, so a shorter period bounds everything downstream.
Artifact-to-profile-version inventory	Keep one, outside Signer	Revocation is pinned to a profile version; nothing in Signer maps versions to deployments.
Key custody assumptions	Establish per workflow	AWS manages keys “for only AWS Lambda and Container images workflows”.
IoT timers	Treat as a separate regime	20 months for both profile and job retention, not validity-plus-six.
Access control on profiles	Tag them and use tag-based policies	Up to 50 tags, and “you can use tag-based resource policies to manage access to the profile”.
Audit trail	CloudTrail, read before the incident	It tracks “who is generating code signatures”.

The rehearsal worth running

Pick a profile version and answer, on paper: which artifacts did it sign, which of those are deployed right now, and what would happen to each if I revoked the profile from a time six months ago. If the first question takes more than a few minutes, that is the finding — the revocation call is quick and the inventory is what makes it actionable.

Then check the validity period on every profile you own. Any still carrying 135 months is holding a cryptographic assertion open into the late 2030s for a reason nobody chose.

Closing Thought

The sharp edge here is a documentation asymmetry rather than a design flaw. Signer tells you exactly what revoking a signature does to a Lambda package and to a container image, in both cases naming the verification that fails. For a profile it tells you that signing stops, hands you a timestamp that can only move earlier, and stops there.

The retention rules are where the relationship becomes visible, and they are on a page about deletion: a revoked profile is kept for up to 141 months precisely because the signatures it made have not expired. That is AWS saying, in the course of explaining something else, that signatures outlive the revocation of the profile that produced them.

Which makes the practical advice simple even though the mechanism is not. If an artifact must stop verifying, revoke its signature. Revoking the profile is how you stop the next one. #85 was about limits that bind hardest on the worst day; this is about knowing, before that day, which of two similarly named operations does the thing you will need.

Next in this series

Security & Identity — AWS CloudHSM: why AWS cannot decrypt your cluster backups and what that means when you need one, what you must do before a cluster can be deleted, and where backups are stored relative to the cluster they came from.

AWS Architecture Series #86 — Revocation has a start time, and it only moves backwards