A developer leaves and their code-signing certificate is revoked. What happens to scripts they signed earlier, and why?

Scripts signed and timestamped before the revocation time keep working, because the signature was valid when it was made; signatures created after the revocation are rejected.

Revoking a code-signing certificate is not like revoking a TLS client certificate. Code lives on long after it was signed: thousands of installed programs and deployed scripts would break if every signature failed the moment a developer left. So Authenticode checks the timestamp: if it shows the signature was made before the certificate's revocation date (and within its validity period), the signature still counts as valid. This is the same reason Windows keeps long-expired Microsoft root certificates in its store: old signed code that was timestamped while they were valid must still verify.

So after revocation:

• Old, timestamped scripts still run, as they should: the developer signed them in good faith while employed.
• A script signed again after the revocation carries a timestamp after the revocation date, so its signature is rejected, for that user and for any other user on the machine. A departed developer cannot sign new code with the old key.

Consequence for incident response: if the key was stolen, the CA should set the revocation date back to before the earliest misuse, so that malicious signatures made with the stolen key are invalidated too. Timestamping is what makes this fine-grained decision possible.

* The timestamp decides which side of the revocation date a signature falls on. *

Go deeper:

• Wikipedia: Code signing — timestamping and why signatures outlive the certificate.
• Wikipedia: Trusted timestamping — the timestamp authority's role.