You revoked the key. What about the sessions it already created?

A useful finish line is more precise than “the secret is gone”

GitHub announced new public-monitoring triage, validity, API and webhook controls on October 23. Our morning explanation examined the alert-to-owner handoff. This guide asks a different question: what would persuade an incident owner that the relevant access paths are contained?

The answer cannot be a universal green tick. A developer may remove a string from a repository, an administrator may retire its credential and an application may continue operating under a different identity. Those observations need not contradict one another. The response must identify exactly which claim each observation supports, and which claims remain open.

Our contribution is a comparison method and a no-secret worksheet, not a breach investigation or a product test. Work only on systems you are authorized to administer, with the responsible incident team and current provider instructions. Do not paste a real key into this page, an AI chat, a third-party checker or a public issue. Nothing here connects to a provider or validates a credential.

Source notes: 1, 10. Original editorial interpretation and hypothetical examples are identified in the text.

Map four objects before selecting a control

For this guide, separate the credential, the identity it represents, any credentials or sessions it can issue, and the permissions checked when resources are used. This four-part map is our explanatory model, not a claim that every provider implements the same authentication chain. Some keys are presented directly on requests; others participate in obtaining another credential.

Draw only relationships your own configuration establishes. A build workflow might use one identity to obtain temporary deployment access, while its artifact store has a different authorization boundary. A GitHub token is not automatically an AWS role session. Similar-looking strings and similarly named “revoke” buttons do not establish that the controls have the same scope.

For each arrow, ask who operates the issuer, who can stop new issuance, who can deny existing access and where evidence of that action would appear. Unknown is a useful answer if it receives an owner. Guessing that one administrator controls the whole chain can turn a completed local action into an unfinished incident elsewhere.

Source notes: 2, 3, 5. Original editorial interpretation and hypothetical examples are identified in the text.

Compare the boundary, not the button label

The following comparison is deliberately narrow. It summarizes documented effects of particular controls, not all authentication methods offered by each company. It is not a ranking, a guarantee of immediate enforcement or a sequence of instructions to execute on a production account.

Read across a row before acting. A control can be appropriate for the original credential yet insufficient for a different object in the map. Conversely, a wider identity-level restriction may have substantial consequences for legitimate users and applications. Match the decision to the exposure you are investigating, not the desire to make every dashboard look resolved.

Documented scope, not a cross-provider security score or a production runbook. Source notes accompany this section. Read all four columns by scrolling horizontally.

Source notes: 2, 4, 5, 6. Original editorial interpretation and hypothetical examples are identified in the text.

AWS: a session cutoff needs an issuance boundary too

AWS documents role-session revocation through a time-conditioned deny policy. Sessions issued after the cutoff are not covered by that condition. Its temporary-credential guidance also says permissions are evaluated on requests and policy updates can take minutes to propagate. These are permission-enforcement controls, not removal of token copies from someone else’s computer.

Our practical reading is to investigate two separate paths: existing sessions and the ability to obtain another session. If an unauthorized actor can still satisfy the role’s trust conditions, a cutoff alone does not establish a durable end to access. The incident owner must identify the compromised entry path and authorize the appropriate restriction there as well.

Do not interpret a documented timing example as a stopwatch guarantee for your deployment. Record the policy, its scope, the time it was applied and the provider-specific caveats. AWS also distinguishes service-linked roles and IAM Identity Center sessions from this ordinary role procedure. Consult the matching guidance rather than copying one role’s response across an entire organization.

Source notes: 3, 4. Original editorial interpretation and hypothetical examples are identified in the text.

Google Cloud: deleting a service-account key is not the whole chain

Google Cloud explicitly says deleting a service-account key does not revoke short-lived credentials already issued using it. Its key-management reference identifies disabling or deleting the represented service account as a broader way to revoke compromised short-lived access, while warning that workloads using that account lose access. That is a materially wider decision than deleting one key. Token validity and the represented identity’s permission to access resources are separate layers; denying access does not erase already-issued token copies.

The distinction is not an instruction to delete a shared production identity reflexively. First identify the account, its dependent workloads, the authority for an emergency restriction and the restoration plan. A change that is appropriate during a serious compromise may also interrupt an unrelated deployment or scheduled job using the same identity.

Google’s token reference describes a default one-hour service-account access-token lifetime, with configurable exceptions. Do not convert that default into your incident’s deadline. Establish the actual token type, issuance configuration and applicable access controls. If those cannot be established, write “remaining access window unknown” rather than subtracting an hour from the alert timestamp.

Source notes: 5, 8. Original editorial interpretation and hypothetical examples are identified in the text.

GitHub: distinguish token invalidation from enterprise authorization

GitHub says a revoked or expired token cannot authenticate Git and API requests. Separately, its enterprise guidance distinguishes removing access to SSO-protected organization resources from deleting the credential: other enterprise-level or non-SSO permissions can remain. The actions answer different questions.

Enterprise managed-user credential deletion is broader but not universal either. GitHub documents asynchronous processing and exclusions, including GitHub App installation tokens and GITHUB_TOKEN. Check the exact account type and credential family before treating an account-wide action as proof that every automation credential was removed.

For our worksheet, the useful statement is therefore bounded: identify the credential and the affected resource boundary, then reference the authorized action and its observed result. Avoid “all GitHub access is gone” when the evidence concerns only one token, one SSO authorization or one enterprise. Also investigate any access already exercised; later token invalidation does not answer that historical question.

Source notes: 2, 6. Original editorial interpretation and hypothetical examples are identified in the text.

A fictional clock shows why alert time is the wrong expiry anchor

Consider a deliberately invented service, not an AWS, Google or GitHub timing specification. Assume it issues sessions with a strictly enforced maximum lifetime of 40 minutes, permits no refresh and has no alternate issuer. A key is exposed at 09:00. The owner sees an alert at 09:05 and establishes that new issuance stopped at 09:10. A session could have been issued just before that last time.

Under those assumptions only, the expiry-based upper bound would be 09:50, not 09:45. The arithmetic is 09:10 plus 40 minutes. It describes a bound in the invented model, not an observation that an attacker obtained a session or a recommendation to wait while harmful access remains possible. An authorized immediate-denial option may change the response entirely.

Now remove one assumption. If another issuer can create sessions, refresh is allowed, the lifetime is uncertain or the issuance stop is not established, the 09:50 claim no longer follows. That is the point of the example. A believable calculation with an unverified starting condition remains an unverified conclusion. Keep the missing condition visible and assign investigation rather than displaying a countdown to safety.

Source notes: 3, 8. Original editorial interpretation and hypothetical examples are identified in the text.

Ask what each piece of evidence can actually establish

Our proposed evidence register has a claim, a scope, an observation time, a restricted evidence reference, an owner and an unresolved question. For example, a provider operation record can support that a particular administrative action occurred. It does not, by itself, describe every dependent application, every previously issued session or every action during the exposure.

A denied request is also a scoped observation. Before interpreting it, an authorized responder must know which identity, resource, action and time it concerns, and whether the expected authentication path was actually exercised. Do not send requests using a discovered stranger’s credential. This guide performed no such checks and offers no public token-validation endpoint.

For activity review, ask whether the retained logs cover the relevant identities, resources, actions and time interval. Check the collection and retention configuration before reading silence as reassurance. OWASP recommends useful secret-lifecycle and access records while keeping the secret itself out of logs. The absence of an event in the records you inspected is not proof that no misuse occurred outside their coverage.

Source notes: 2, 3, 10. Original editorial interpretation and hypothetical examples are identified in the text.

Separate restoring the service from containing unauthorized access

Two response plans can look identical in a deployment ticket yet have different safety properties. In a continuity-first plan, legitimate applications receive replacement access before the original is withdrawn. In an emergency restriction, the owner may accept an interruption to reduce exposure first. These are contrasting decision patterns we propose for discussion, not universal runbooks.

The responsible team must decide using the actual severity, affected service and authorized emergency process. Creating a replacement does not establish that the original access was withdrawn. Disabling a shared identity does not establish that legitimate jobs recovered. Record containment evidence and recovery evidence separately so that success on one axis does not conceal a failure on the other.

Recovery should include the workloads that run infrequently, not just the request visible in a browser. Ask which scheduled exports, build runners or backup processes depend on the identity and who can verify their next authorized execution. These are questions for the service inventory, not a claim that Lumacta found failures in any reader’s environment.

Source notes: 4, 5, 10. Original editorial interpretation and hypothetical examples are identified in the text.

A six-question worksheet with no credential field

Use a restricted incident record, not a public comment thread. Start with a non-secret identifier for the affected credential or identity and the response owner. Then answer these six questions in plain language. The worksheet is an original editorial aid, not a compliance checklist, a provider approval or a substitute for incident-response expertise.

One: what access boundary is affected? Two: what authorized action stops the original credential or issuance path? Three: what happens to already-issued access, with which provider-specific exceptions? Four: what observation supports each containment claim, at what time? Five: which legitimate workloads were checked after the change? Six: what historical activity or remaining uncertainty still needs investigation?

For every answer, attach a restricted reference to evidence rather than the secret value. Name the person who can resolve any unknown. A short entry such as “existing session coverage not yet established; identity owner investigating” is more useful than a broad “fixed” status whose meaning changes depending on who reads it.

The fictional case above should fail this worksheet if somebody supplies only “key removed at 09:10.” It still needs the actual meaning of removal, the issuance boundary, session assumptions and the recovery and investigation decisions. Completing the arithmetic does not complete those tasks. A tabletop exercise should test whether the team notices the gaps, not reward the fastest ticket closure.

Source notes: 3, 5, 10. Original editorial interpretation and hypothetical examples are identified in the text.

Repository cleanup has a different job

GitHub’s sensitive-data guidance puts revocation or rotation before considering a history rewrite. It warns that rewriting history changes commit identifiers, requires coordination and can reintroduce the material from old clones. Removing public copies and disabling access are distinct tasks.

Our recommendation is to give cleanup its own accountable scope after urgent containment decisions. Preserve necessary incident evidence in restricted storage while coordinating source-history and derivative cleanup. Do not turn a broadly shared remediation ticket into another secret repository, and do not assume a cleaned branch establishes that external copies disappeared.

This also prevents an expensive distraction. A team can spend hours polishing repository history while nobody owns the authorization boundary. Conversely, a properly revoked credential does not make every other kind of sensitive information in the file harmless. Assess what else the exposure contained rather than treating the entire document as equivalent to one key.

Source notes: 9, 10. Original editorial interpretation and hypothetical examples are identified in the text.

Federated workflow identity changes the tradeoff, not the need for trust

GitHub’s OIDC reference describes a workflow obtaining short-lived cloud access through a configured trust relationship instead of duplicating a long-lived cloud credential into repository secrets. The trust relationship identifies which workflow can request which role. This is an architectural alternative for supported integrations, not evidence that a particular deployment is secure.

Our assessment is that reducing stored long-lived credentials can remove a recurring rotation burden, but it moves attention toward the identity allowed to request fresh access. Ask which repository, workflow, branch or environment is trusted, what authorization it receives and who can change those conditions. “Uses OIDC” is not a complete answer to “who can deploy?”.

Do not migrate authentication during an uncontrolled incident merely to modernize the diagram. Stabilize the authorized response, then evaluate federation with a bounded non-production plan and service owners. Measure whether the new process eliminates the old long-lived credential rather than leaving a forgotten fallback alongside the new path. We performed no migration or comparative benchmark.

Source notes: 7. Original editorial interpretation and hypothetical examples are identified in the text.

Close the right claim, and leave the remaining work visible

The strongest closure record is not the longest one. It states what was exposed, which access paths were addressed, what evidence supports those actions and which questions remain assigned. Containment, service recovery and investigation can progress at different speeds. Keeping separate statuses is more honest than forcing them into one reassuring label.

The provider comparison explains why. Invalidating one GitHub token, applying an AWS role-session cutoff and deleting a Google service-account key address different objects and boundaries. The right comparison is not which button is fastest to press, but which documented effect matches the claim your team needs to make.

For readers, the practical next step is small: take one non-sensitive tabletop scenario and try the six questions with the people who own deployment identity. If they cannot identify the issuer or explain existing-session behavior, that is a specific gap to investigate before a real exposure. The archive workshop photograph is community context only; none of the pictured people is associated here with a leak or a security test.

Source notes: 2, 4, 5. Original editorial interpretation and hypothetical examples are identified in the text.