GitLab does expose useful metadata. Self-Managed and Dedicated administrators can call GET /deploy_tokens for an instance-wide list. Project and group endpoints cover narrower permissions. The API returns fields including expires_at, scopes, and status. GitLab's API documentation is the right starting point for a homegrown audit.

Turn the list into a reviewable inventory

Keep the token name, project, expiry, and scopes together. Add an owner and a review date to each undated record. A scan only covers resources the GitLab account is permitted to read, so record that scope alongside the results.

What to do with Never expires

An undated deploy token should have a named owner and a review date even if the token must remain active. Check whether the consumer still exists and whether its scopes remain appropriate. GitLab documents setting expiry at creation, so replacing an existing undated token is the practical route when it needs an enforced expiry date.

Rotate in a safe order: create a replacement, update consumers, test the pipeline or registry operation with the new credential, and only then revoke the old token. For a group token named gitlab-deploy-token, GitLab populates CI_DEPLOY_USER and CI_DEPLOY_PASSWORD only in immediate child projects. Nested subgroups need separate attention.

A repeatable audit

1. List accessible GitLab deploy tokens and preserve their metadata.

2. Review records marked Never expires and assign owners.

3. Record review dates where GitLab provides no expiry.

4. Replace unused or overprivileged tokens after testing consumers.

5. Repeat the inventory scan and compare it with the previous list.

TokenTimer can preview a GitLab scan and import accessible metadata in one action without retrieving token values. Cloud scans are manual. Self-hosted installations can schedule GitLab re-scans. Access permissions still define the inventory's scope.

The goal is not an arbitrary expiry on every token. It is knowing which credentials still exist, who is responsible for them, and when someone will review them again.

Originally published on TokenTimer.

The credential still has an identity, a permission set, unknown copies, and possibly live dependencies. Removing that authentication path requires revocation, while legitimate consumers need a working identity and the exposure needs an activity review.

Research from Truffle Security illustrates this gap. The company tested 10,616 complete AWS key pairs again after they had appeared publicly between August 2022 and August 2026. On August 10, 2026, 9,308 of them, or 88%, still authenticated.

The findings raise two distinct questions: how much access did the keys retain, and what would make those authentication paths stop working?

The research measured persistence, not just exposure

Truffle Security's scanners had historically verified 64,024 unique AWS key pairs across 431,875 public findings. Those findings included Git history, Hugging Face datasets, Docker images, package registries, and CI logs.

Researchers retained complete credentials for 10,616 of the unique pairs and tested that population again. The result was not a list of strings that merely looked like AWS keys. It was a set of credentials checked for successful authentication, with 9,308 still active.

That difference is important. Removing a key from its original repository does not disable it in AWS. Exposure exists wherever a copy can be found; validity is controlled by the identity provider. A response process has to connect the two.

Persistent AWS access keys have no automatic ending

Traditional IAM access keys are persistent credentials. Unlike temporary credentials issued through IAM roles or AWS STS, they do not reach the end of a short session and stop working. AWS documents that IAM user access keys remain valid until they are manually revoked and recommends temporary credentials wherever possible.

This creates a particular kind of infrastructure drift. An application can be retired, a developer can leave, a migration can finish, and a sandbox account can be forgotten. None of those events changes the state of the key.

The surrounding reason disappears. The authentication path remains.

For 2,903 active credentials that permitted iam:ListAccessKeys, the researchers could retrieve exact creation dates. The median key was 1,831 days old, a little over five years. Only 25 had been created in the previous 30 days. Just 13.7% had a newer access key associated with the same user, suggesting that rotation was uncommon within this population.

That median measures age since creation, not time since exposure. It applies to these 2,903 keys, not specifically to the corporate admin keys examined below.

A forgotten certificate eventually reaches its expiration time. A forgotten persistent AWS key does not have that automatic boundary.

Hundreds retained authority across an entire account

Age becomes more serious when combined with privilege.

Truffle Security classified 817 active keys as linked to businesses. Of those:

1. 526 were root access keys.

2. Another 242 belonged to IAM users with AdministratorAccess.

3. The two groups did not overlap.

Together, 768 credentials provided full control of a company AWS account. The research also identified 130 active root keys belonging to AWS Organizations management accounts.

AWS strongly recommends not creating access keys for the root user. The root user has full access to the account, so existing root access keys should be removed.

Least privilege is not an abstract improvement in this scenario. It determines whether one copied secret grants a narrow workload capability or control over an account.

A quarantine signal is not the same as revocation

One of the most revealing findings involved credentials AWS had already detected as exposed.

The researchers found 929 active IAM users with the AWSCompromisedKeyQuarantine policy attached. AWS had restricted those users, yet their credentials still authenticated. Among them, 112 carried the original policy version that AWS stopped applying in 2023, indicating that they had been flagged at least three years earlier.

Quarantine can reduce immediate capability, but a human or automated workflow still has to resolve ownership and dependencies. If a team cannot tell which production job uses a key, disabling it can create an outage. If nobody accepts that risk and no migration is scheduled, the compromised identity can remain indefinitely.

The completion condition for an alert from secret scanning should therefore be stronger than “finding acknowledged” or “policy attached.” It should include evidence that the exposed credential has been revoked and that any legitimate consumer now uses an approved replacement.

Public copies spread beyond source repositories

The propagation path has also widened.

Truffle Security reported 8,482 unique live AWS keys across 3,394 public Hugging Face datasets. Training datasets can include snapshots of source code collected elsewhere. A key committed once can be copied into datasets, images, archives, forks, caches, and downstream projects.

Deleting the original file cannot recall those copies. It also cannot make a credential secret again. Once a credential has been public, assume it has been copied and revoke it.

This gives secret scanning and credential lifecycle management distinct responsibilities:

1. Scanning asks where a secret has appeared.

2. Lifecycle control asks whether it is still valid, who owns it, what depends on it, what it can access, and when it will be removed.

An organization needs both. Neither is a substitute for the other.

Why a policy based on 90 days is incomplete

The AWS Config access-keys-rotated control uses 90 days as its default maximum age. That can be a useful backstop, but key age answers only one governance question.

It does not tell you:

1. Whether the identity still has a valid purpose.

2. Who is accountable for it.

3. Which applications will fail if it is disabled.

4. Whether its permissions are still appropriate.

5. Where copies may exist.

6. Whether the replacement reached every consumer.

7. Whether the old credential was actually deleted.

Routine rotation can leave two active keys if the replacement is created but the original is never removed. Disabling the old key without accounting for its consumers can instead create an outage.

Treat routine rotation as a dependency migration, not a timestamp update. An exposed key requires a more urgent response.

An incident runbook for an exposed key

When a persistent access key becomes public, treat it as compromised. The responsibilities below need observable outcomes, but they are not a rigid migration order: revocation must not automatically wait for every consumer to move.

1. Identify the credential and its authority

Resolve the AWS account, IAM user or root identity, attached permissions, expected use, recent activity, owner, and known consumers. Root credentials and credentials with administrator access have the broadest blast radius.

2. Contain and revoke

Prioritize restricting access and disabling or deleting the exposed key. Coordinate the availability impact with the workload owner. A quarantine policy or a deleted public copy is not evidence that the AWS key has been revoked.

3. Decide whether a replacement is necessary

If the workload can use an IAM role, workload identity, federation, or AWS STS, migrate toward temporary credentials. If a persistent key remains unavoidable, create a replacement with the permissions the workload actually needs.

4. Migrate every dependency

Update each known consumer and verify it operates with the intended identity. Ownership and dependency records help reduce the risk of a security response becoming an availability incident.

5. Review activity and verify the result

Review the exposed key's activity and permissions, confirm the intended identity is in use, and verify that the old key no longer authenticates. Revocation removes this authentication path; it does not by itself establish that the wider incident is resolved.

Build a lifecycle that removes obsolete paths

The durable controls are straightforward to state, even when migration work is not:

1. Prefer temporary credentials for people and workloads.

2. Remove root access keys from all accounts, including development, sandbox, and Organizations management accounts.

3. Inventory every persistent key that remains.

4. Assign a responsible person or team and an explicit review or rotation deadline.

5. Apply least privilege so one workload does not administer an entire account.

6. Scan repositories, CI/CD systems, images, registries, and datasets independently of the lifecycle inventory.

7. Treat rotation as complete only after dependencies use the replacement and the old key is disabled or deleted.

AWS's broader IAM security best practices also emphasize temporary credentials, least privilege, and regular removal of unused identities, policies, and credentials.

Where inventory tooling fits

TokenTimer tracks inventory, ownership, and lifecycle status through metadata, not public secret scanning. Its AWS integration can discover IAM access key metadata alongside Secrets Manager secrets and ACM certificates without retrieving or storing secret access key values.

Because AWS supplies no expiration date for IAM keys, they import as nonexpiring assets by default. Teams can assign an internal review or rotation date. That is an operational deadline, not automatic expiry of the AWS key.

The operational lesson

The 768 credentials with full control show the potential blast radius. Separately, the age measurements show how long persistent credentials can remain valid.

Applications change. Teams reorganize. Experiments end. Copies spread. A persistent credential can remain stable through all of it because AWS does not infer that its purpose has disappeared.

When a persistent key is unavoidable, give it a named owner, constrained authority, a review deadline, a tested replacement path, and a removal condition. Detection produces a finding. Revocation removes the exposed authentication path, while activity and permission review remain part of the response.

Originally published on TokenTimer.

The credential does not know that a migration finished or a pipeline was replaced. Unless someone explicitly deactivates or deletes it, the authentication path remains available. That makes long-lived access keys a lifecycle problem before they become a rotation problem.

A calendar can tell you when a key should change. It cannot tell you whether the key should still exist.

Long-term and temporary credentials have different failure modes

AWS guidance on securing access keys distinguishes long-term IAM user credentials from temporary credentials. An IAM user access key has no automatic expiration. Credentials issued through IAM roles and AWS Security Token Service have defined lifetimes and stop working when their sessions expire.

Workload identity, roles, and OIDC federation let applications and CI/CD systems obtain temporary access without storing a permanent AWS secret. That architectural choice changes the operating burden.

A persistent key has to be protected everywhere it is copied, inventoried for as long as it exists, monitored for unexpected use, rotated without breaking consumers, and eventually removed. Temporary credentials do not solve authorization by themselves, but they remove indefinite lifetime from the default design. AWS makes the same preference explicit in its guidance on temporary credentials.

The practical order is therefore:

1. Eliminate the persistent key where possible.

2. Use temporary identity for people and workloads.

3. Treat every remaining long-lived key as an owned exception with an end condition.

Evidence from real exposure campaigns

The danger is not theoretical, and the exposure window is not measured in quarterly review cycles.

A 2024 experiment summarized by Help Net Security planted AWS credentials across public platforms. Keys on GitHub and Docker Hub were found and used within minutes, while other platforms took hours or days. The exact timing varies, but the defensive conclusion does not: a manual response process cannot assume that a public credential will remain unused while a human investigates.

Palo Alto Networks Unit 42 documented an automated cryptojacking campaign called EleKtra-Leak. The actor continuously scanned public GitHub repositories for AWS IAM credentials. In controlled leaks, Unit 42 saw a plaintext key detected and used within five minutes, followed by attempts to create EC2 capacity for cryptocurrency mining.

Between August 30 and October 6, 2023, the researchers observed 474 distinct miners that appeared to run on actor-controlled EC2 instances. They found that the campaign had been active since at least 2020. This was repeatable infrastructure designed to turn an exposed authentication path into compute, not a one-off attacker stumbling across a secret.

The .env campaign shows how exposure becomes cloud compromise

A separate Unit 42 cloud-extortion investigation followed a campaign that searched public web applications for exposed .env files.

The actor scanned more than 230 million unique targets, reached at least 110,000 domains, and collected more than 90,000 unique environment variables. Thousands of those variables were associated with cloud services.

Valid cloud credentials allowed the actor to enumerate identity and storage resources, exfiltrate data, leave ransom notes, and use compromised infrastructure to search for more victims. This campaign connects two parts of the lifecycle that teams sometimes review separately: where a credential is stored and whether the authentication path behind that copy is still valid.

A young key in a public .env file can be immediately dangerous. An old, dormant key remains a standing risk until it is revoked. Rotation age alone does not describe either situation.

An exception needs enough context to be governed

Some legacy applications and integrations still require IAM user access keys. Calling those keys “exceptions” is useful only if the exception has a concrete record.

For each persistent key, document:

• the named owner;

• the workload and purpose;

• why temporary credentials are not yet suitable;

• the permissions the workload requires;

• creation and last-use information;

• expected behavior;

• known storage locations;

• the approved lifetime and review date;

• the replacement strategy;

• the condition that will retire the exception.

The final item prevents a temporary workaround from quietly becoming permanent infrastructure. If the team cannot explain what will make a key disappear, a rotation schedule may keep refreshing the credential without reducing the number of persistent authentication paths.

Storage review and lifecycle review belong together

Removing a secret from current application configuration does not remove all of its copies. Long-lived keys can survive in source repositories, Git history, container layers, CI/CD variables, backups, environment files, and old deployment configuration.

Secret discovery identifies places where credentials may have escaped. Lifecycle review answers a different set of questions: Is the key still valid? Who owns it? What can it access? Is its use expected? Can it be disabled now?

Both matter because deleting a line from a file does not revoke the credential. The response path needs to lead from detection to deactivation, investigation, replacement where required, and removal of the old authentication path.

Rotation should prove that the old path is gone

For a persistent key that cannot yet be eliminated, treat rotation as a migration:

Create → Deploy → Verify → Deactivate → Monitor → Delete

Creating a replacement key is only the first state. Every consumer must receive it, the workload must be verified, and use of the old key must stop before that old path can be safely disabled and deleted.

If the old key remains active, rotation may simply leave two working credentials. If it is disabled too early, a dependency that never received the replacement can fail. The meaningful outcome is evidence that the old authentication path is no longer required.

Practical takeaways

• Prefer temporary credentials over permanent secrets.

• Make every unavoidable long-lived key visible as an exception.

• Track ownership, purpose, age, last use, permissions, storage, and replacement.

• Prepare a fast deactivation path before exposure occurs.

• Treat rotation as complete only when the old key is removed.

Do AWS IAM access keys expire automatically?

No. Long-term access keys for IAM users remain valid until they are manually deactivated or deleted. Temporary credentials issued through roles and STS expire after a defined period.

Should a team rotate long-lived keys or eliminate them?

Eliminate them where roles, workload identity, or OIDC federation can provide temporary credentials. Govern unavoidable exceptions with least privilege, a named owner, age and last-use review, and a tested replacement process.

What should the next access-key review ask?

Keep asking when the key was last rotated, but add the question that exposes lifecycle debt:

Why does this persistent credential still exist, and what will make it disappear?

Originally published on TokenTimer.