The credential lifecycle registry

The credential lifecycle registry is your account’s own list of the credentials, keys, licences, certificates and short-lived tokens that keep a backup or a recovery working, tracked so an expiring or spent one surfaces before it lapses and quietly breaks something. This page is for a self-hoster who wants to keep credential hygiene honestly, without the engine ever holding a secret to do it.

The registry is a watch list, not a vault. It stores a description, a date and a few classifications, so it can tell you a certificate is ninety days out or that a one-shot token still needs deleting. It never stores the credential itself. The vendor reads nothing from it, and most of what it tracks you enter by hand, with a small set of dates the engine can read off artefacts it already legitimately holds.

For the wider access model this sits inside, read identity and access.

What the registry is

Each item in the registry is a dated row of redaction-safe metadata. It carries a label you choose, a kind, a lifecycle class, an optional expiry date, a source, an optional purpose, an optional permission summary, and a link to what the credential powers. From the expiry date the engine computes a whole-day count remaining and a coarse state, so a row can read as ok, approaching, expired or no-expiry.

The kind groups an item and selects how early its first alert fires. The expiry drives both the at-a-glance state and the alert ladder. The usage link is always a stable entity id that is already non-secret elsewhere, such as a destination id or an IdP connection id, so the console can show what a credential powers and deep-link to it; it is never a credential value, and the registry can never act on it.

The state deserves one careful note. An item with no expiry date is a real, honest state of its own, not a healthy green one. Some functional credentials simply do not expire, and a token can be created with no expiry. The registry shows that as no-expiry, rendered neutral, rather than implying the credential is in good standing for a year. An expired item never reads green either.

No custody, by construction

The defining property of the registry is that an item has nowhere to put a secret. The item type has no field for a credential value, a key, a password, or even a fingerprint, hash or prefix of one. It stores a label, a kind, a class, a date and a purpose, and that is all the shape allows.

That is not a convention you could accidentally break by typing a secret into the wrong box. The schema itself carries no secret-bearing field, every free-text field is bounds-checked and control-character screened at the engine boundary, and the console renders every server-supplied string as plain text rather than markup. The closest thing to an identifier the registry holds for a Cloudflare token is its public token id descriptor, which is the account-owned public id, never the token value, and the registry cannot use it to act on Cloudflare.

The console’s add-or-edit form has one field that behaves in a way worth calling out, the optional Note. You can write a Note when you record or edit an item, but the registry never reads it back. The list the console renders (GET /admin/expiry) returns the computed status without the note, so editing an item starts with a blank Note box and a saved Note is never shown again; leaving the box blank on an edit keeps whatever was stored rather than clearing it. Because the Note is write-and-forget from the registry’s point of view, do not put anything there you will need to read back later, such as a renewal runbook link; keep that in your own runbook. What you want to see on the item itself belongs in the Purpose field, which the registry does return and show on the row and its detail.

Tiered proactive alerts

The registry nudges you before a credential lapses, on a ladder that depends on the kind. Long-lead items, meaning certificates and licences, get an earlier first rung so a coordinated rollover has a full extra month of warning. Short-lived items, meaning credentials, keys and tokens, start their warnings closer in.

An alert fires once per newly crossed rung, not on every check. The engine records the lowest rung an item has reached, so descending to a lower rung re-alerts and sitting at the same rung stays quiet. If a credential’s expiry is later pushed out so it is no longer approaching, the recorded rung is cleared, so a future descent alerts again from the top of the ladder.

Two things stay decoupled on purpose. The earlier 60-day rung for certificates and licences is only a notification rung; it does not make the item read “approaching” at a glance, and it does not fail the posture credential-expiry check. The coarse approaching boundary stays at 30 days for every kind, so an early courtesy alert never inflates the at-a-glance band or the posture score for a credential that is still comfortably in date.

What auto-observes, and what you enter by hand

Most items are entered by hand. A small set the engine can fill in for you, by reading the expiry off an artefact it already legitimately holds, such as a certificate’s own validity or a token’s reported window. An observed item is the only kind the engine writes itself; everything else is yours to track.

The items the engine auto-observes are the assurance licence, a SAML signing certificate, a minted bearer credential, and a confidential OIDC or OAuth2 client secret with a declared expiry. The assurance licence row is observed from the licence token’s own validity when you activate or clear a licence, and dropped when the licence falls back to community. A SAML signing certificate row is observed from the connection’s pinned public certificates when you create a SAML connection, tracking the latest validity across rollover certificates so the row reflects how long sign-in keeps working. A minted bearer credential, such as the audit-feed or diagnostics ingest bearer, is observed from the grant’s own expiry at the moment it is minted. An IdP client secret row is observed when you create a confidential OIDC or OAuth2 connection, meaning not a PKCE-public one, and you declare the secret’s own expiry on that connection: the engine holds the secret value write-only and cannot read an expiry off it, so it copies the date you declared into the observed row the moment the connection is created, keyed to the connection so the console shows what sign-in it powers.

The spent Cloudflare attach token is a related but distinct case. When you attach a source, the one-shot Cloudflare token you supplied is recorded as a pending-cleanup row, so you are reminded to delete it in Cloudflare once the attach is confirmed. The engine records only the token’s public id, its reported expiry, a permission summary and the names of the sources attached. It never receives or stores the token value.

Everything else you enter by hand. That includes your R2 or S3 destination access keys, the discovery token, a PKCE-public OIDC or OAuth2 connection’s secret, and any confidential client secret for which you did not declare an expiry when creating the connection. For those, the console’s per-provider hints tell you what the vendor’s defaults usually are and ask you to enter the date you actually chose, rather than fabricating one.

For the deploy and attach token itself, and the evidence that at runtime the engine holds no Cloudflare API token at all, see Cloudflare API token scopes.

The spent-ephemeral cleanup is an attestation

The cleanup flow is where the no-custody posture shows most plainly. An ephemeral token is one meant to be deleted after use, the prime example being the one-shot Cloudflare token you used to attach a source. The registry records it as pending cleanup so you do not forget it.

When you confirm in the console that you deleted the spent token in Cloudflare, the registry flips the row to attested-deleted. That is your attestation, your word that you did it. It is not a Cloudflare-side check. The engine holds no Cloudflare API token at rest, so it cannot read Cloudflare to confirm the token is gone, and there is no in-portal revoke. The two honest states are therefore pending and attested-deleted, and the copy never reads “verified deleted”.

A spent ephemeral token that is still pending is treated as a hygiene reminder, not a backup-breaking expiry. It surfaces in the console’s needs-attention tier and is exempt from the high-severity posture credential-expiry check, which still fails for an expiring functional credential, certificate or licence.

Two honesty caveats

Two limits are worth knowing before you lean on the registry, both stated honestly rather than papered over.

The auto-observe path for a source attach is coded but not yet proven in production. It depends on several in-flight assumptions about what Cloudflare reports during an attach, and those are awaiting a supervised first live attach to confirm. Until that has happened, treat the auto-recorded attach-token row as a best-effort reminder, and check that the pending-cleanup row appears as you expect.

An observed date can also go stale by design. The engine reads a date once, from the artefact it holds at that moment. If a SAML signing certificate is rolled server-side at your identity provider without the connection being recreated, the observed row keeps its old expiry, because there is no live re-read. So a proactive certificate alert is a useful prompt, not an authoritative statement of the current server-side validity. When you roll a certificate, recreate the connection so the registry re-observes the new date.

Where this fits

The registry is one face of the broader access and governance model in identity and access. The deploy and attach token it reminds you to clean up, and why the engine carries no Cloudflare API token at runtime, are covered in Cloudflare API token scopes. The expiring-credential signal also feeds the security centre’s credential-expiry check, described under the posture score, and the reminders are delivered through the same channels as the rest of your alerts, set up under notifications.

Last updated 3 July 2026.