Documentation

Audit.

Every operation against a key writes an audit record. Not a sample, not the interesting ones, not the ones you enabled. There is no setting to turn auditing on because there is no path that skips it.

What is recorded

Each record carries the same shape, which is what makes the trail queryable rather than merely present:

• Actor. Who did it. A console user, a federated identity, or the API key that authenticated the call.
• Action. What was attempted: a signature, a decryption, a key creation, a permission change, a certificate issuance, a revocation.
• Resource. Which key, certificate or object the action names.
• Outcome. Whether it succeeded, failed, errored, or was denied.
• Time and identity. A UTC timestamp and a unique event identifier, so records can be correlated and deduplicated downstream.
• Context. Action-specific metadata, such as the algorithm used for a signature or the reason code on a revocation.

Failures are recorded too

A record is written on both the success and the failure branch of every operation. This is the part that matters during an investigation: a log that only contains successes tells you what happened, while one that contains denials tells you what someone tried. A run of DENIED signature attempts against a production signing key is the signal you want to find, and it only exists because the denial path writes too.

How the trail stays intact

Audit records are append-only, and three separate things hold that rather than one. The API exposes no operation that edits or deletes a record: no update route, no delete route, and no administrative override that reaches them. The account’s own permissions refuse it as well, so it is not merely that no route was written: updating, deleting or batch-writing any row in the audit partition is denied in IAM to every role that runs the service and to the deployment role we use to change the service, which means it is denied to us and not only to you. And the write itself is conditioned on the record not already existing, so creating a record is the only outcome a write can have and an overwrite is refused at the database. Records are written, never revised, and a correction is a new record rather than a change to an old one.

Writing the record never blocks the operation it describes, and it also never fails silently into nothing: when a record fails to write, the write path emits a failure metric counting it, so a fault in audit writing surfaces as a signal rather than as an absence.

The strongest guarantee available to you is not ours to give, though, and it is worth saying plainly: a trail that lives only in the system being audited is a trail whose operator is trusted. If your threat model includes us, stream the records into storage you control and compare. That is the point of the export channel below, and it is the reason it exists as a first-class feature rather than a reporting afterthought.

Streaming it out

Audit records publish to a notification topic in your own account as they are written. You subscribe a destination to that topic and the records arrive continuously, without polling and without an export job. From there they land wherever your evidence already goes: an object store, a log platform, a security information and event management system.

Subscribing and unsubscribing are administrative actions, so they require an administrative permission tier, and like everything else they are themselves audited. Changing where your audit trail is delivered is exactly the kind of act that should leave a mark.

Retention

Audit records live in your account for as long as your subscription does. They are not rolled up, sampled or aged out into a summary while you are a customer.

If you need evidence with a retention duty measured in years, which is common for device and firmware signing, do not rely on our storage for it. Stream the records into your own retention regime from day one. The obligation to hold that evidence is yours, the record is exportable from the first operation, and the export is the mechanism that lets you meet it on your own terms.

What conveys to you if you stop being a customer is set out in Escrow and Keyout, and the audit trail is part of it.

What is deliberately not in the log

The record names the operation, not its contents. Payloads, plaintexts, ciphertexts, signatures and secret values are not written to the audit trail, and neither are the request bodies that carried them.

This occasionally disappoints. It is the right trade: an audit log that captured plaintexts would become the most sensitive store in the account, and a log you must protect as tightly as the key material defeats the purpose of separating them. You get proof that an operation occurred, by whom, against what, and when. You do not get a copy of the data, and neither does anyone who reaches the log.