Registry Tokens

A registry token is a long-lived bearer credential Terraform presents to the compliance.tf registry. It is not the short-lived credential terraform login writes for you.
There are two kinds. A personal token belongs to one person. An organization token belongs to an organization and is managed by anyone holding the token-management permission there.
The token value is displayed once, at creation. It is never stored in a form anything can turn back into the token, and no surface will show it again — not the interface, not the API, not us.
Tokens do not expire. There is no way to mint one with a lifetime; a token stays usable until someone deactivates it.
Deactivating a token is what revokes it, and it takes effect on the next request. Deleting is bookkeeping that requires deactivation first.
Removing someone from an organization does not revoke any token — not the organization tokens they created, and not their own personal ones.

What a token is for

The registry answers a terraform init with a module built to the compliance posture your organization has bound to the environment you addressed. Before it can do that it has to know who is asking, because the answer differs by entitlement and by organization. A registry token is that identity in a form a pipeline can hold.

Two things it is not. It is not the credential terraform login stores — that one is short-lived and browser-issued, and it is the right choice for interactive use on your own machine. And it is not a platform API key: a registry token authenticates against the registry only, never against the platform surfaces that author and promote a posture.

The two kinds of token

	Personal token	Organization token
Owned by	One person	The organization
Managed from	Your own tokens page	The organization's tokens screen
Who can manage it	Only its owner	Any member with the token-management permission
Entitlement it carries	The owner's	The organization's plan
If its holder leaves the organization	Keeps working, but narrows to that person's own entitlement	Keeps working unchanged

Pick by what depends on the credential, not by convenience:

Personal for interactive work on a machine you control, and for experiments.
Organization-owned for anything a team depends on. A pipeline authenticated with one person's personal token has two ways to go wrong. It breaks when that person leaves, or it keeps working with their entitlement long after it should have stopped. Both are failures, and the second one is the worse of the two.

There is a third reason, and it surprises people: belonging to a paid organization does not by itself upgrade your personal token. A personal token resolves against its holder's own plan, so on a framework endpoint like soc2.compliance.tf a member with no plan of their own resolves to the free tier. It picks up the organization's plan only when the request addresses the organization's own hostname. An organization token carries the organization's plan on every hostname, which is one more reason to use one for shared automation.

The one-time reveal

Creating a token returns its value exactly once, in the response to the creation request and the panel that renders it. After you dismiss that panel the value is gone from every surface.

This is not a display choice that a support request can work around. The stored record is not the token and cannot be turned back into it, so nobody — including us — can recover the value for you. If you lose it, mint a replacement and revoke the one you lost.

Copy it straight into wherever you keep deployment secrets. Do not park it in a scratch file on the way.

Wiring a token into Terraform

Add a credentials block for the hostname your modules come from:

credentials "soc2.compliance.tf" {
  token = "ctf_YOUR_TOKEN_HERE"
}

Terraform matches credentials by hostname, and only by hostname. A block for one endpoint does nothing for another, so the hostname here has to be the same one that appears in your module source. Replace soc2 with the framework endpoint you use, or with your organization's own hostname if you address modules through it.

In a pipeline, prefer the TF_TOKEN_<hostname> environment variable over writing a file: a credentials file left behind on a shared build agent is a leaked token waiting to happen. The CI/CD integration guide covers the variable form, the .netrc alternative, and per-platform secret storage, and Get Started walks the whole first-run path.

Revoking a token

Revocation is two steps, and the first one is the one that matters.

Deactivate. The registry refuses the token from the next request onward. Anything holding it loses registry access immediately: a terraform init against a compliance.tf endpoint starts failing, so have the replacement in place before you revoke a credential something is using.

Delete. Removes the entry from the listing. It is refused on an active token — you have to deactivate first, and the interface only offers deletion once a token is inactive.

One property to plan around: deactivation is reversible. A deactivated token can be activated again, and the original value works when it comes back. That is useful when you are isolating a broken pipeline, and it is the wrong tool for a leak — if a token's value has escaped, delete it as well, so nobody can turn a known-compromised credential back on.

Handling tokens safely

A token is a bearer credential. Whoever holds the string can pull modules with the entitlement behind it. There is no second factor, and no restriction on where it is presented from.
Nothing lapses on your behalf. Because tokens do not expire, rotation is something you schedule rather than something the platform does. Mint the replacement, deploy it, confirm it works, then deactivate the old one — in that order, so you never have a window with no working credential.
Offboarding does not touch tokens. Removing a member leaves both their personal tokens and any organization tokens they created exactly as they were. Put a token review in your offboarding checklist; the platform will not do it for you.
One token per consumer, named for its consumer. The name is the only thing that tells you what a token is for later, and it cannot be changed after creation. A token you cannot attribute is a token you will hesitate to revoke.

Operating tokens

The rest of this page is the operator's half: the boundary that keeps personal and organization tokens out of each other's listings, exactly what an organization token's lifetime depends on, what each revocation step guarantees, and what a token can and cannot reach.

Organizations and members — organizations, aliases, membership, and what removal does
Access control — roles, permissions, and the full mapping
Plans and entitlements — what a token's entitlement decides
Projects and environments — how a request addresses a project environment

At a glance

On this page