Blog
They wrote access was removed. The bastion still had his key.
At 02:57 Priya deactivates Leo Hart's Okta account after a lost-device flag. Bastion host ops-jump-01 still accepts an SSH key issued to him in March. The scribe writes access was removed.
At 02:57 on 31 October 2026, Priya S (on-call, platform) deactivates the Okta account for Leo Hart, a contractor whose statement of work ended two days earlier. The inject started at 02:52: ticket IT-5518 says Hart's laptop was reported missing from a locked car in Austin on 30 October, and HR wants an out-of-cycle access review before the offboarding ticket closes. Marcus T (incident commander) reads the plan. It says: on a contractor offboarding with a lost-device flag, deactivate the Okta account, confirm every active SSO session is revoked, and inventory every host where that person holds a credential issued outside Okta, a direct SSH key, a local account, an API key typed in by hand, before anyone writes that access was removed. Priya deactivates the account and opens the Okta System Log. Two session.end events appear for sessions that were active that morning. She tells Marcus the account is dead and both sessions are gone. She does not open the host inventory. Deepa R (infrastructure, owns that inventory) is not on the call. Bastion host ops-jump-01 has a line in /home/deploy/.ssh/authorized_keys added on 12 March 2026 for a one-off migration project, commented leo-hart-temp-migration. Okta deactivation does not touch that file. At 03:04 Priya tells Marcus that Leo Hart's access is removed. The inject's next line is an auth.log entry from ops-jump-01 at 03:09: Accepted publickey for deploy from 203.0.113.44 port 51322 ssh2, ED25519, key fingerprint ending 9f2a1c, comment leo-hart-temp-migration. At 03:14 the scribe writes that Leo Hart's access was removed and ticket IT-5518 is closed.
A weak record of those twenty-two minutes reads:
Leo Hart's access removed. Ticket IT-5518 closed.
A strong one reads:
31 October 2026, 02:52 to 03:14. Incident-response tabletop. Seats: Marcus T (incident commander), Priya S (on-call, platform). Deepa R (infrastructure, owns the bastion host inventory) was not on the call. Inject at 02:52: ticket IT-5518, contractor Leo Hart's statement of work ended two days earlier, laptop reported missing from a locked car in Austin on 30 October. Plan: on a contractor offboarding with a lost-device flag, deactivate the Okta account, confirm every active SSO session is revoked, and inventory every host where that person holds a credential issued outside Okta, before anyone writes that access was removed. At 02:57 Priya deactivates the Okta account and confirms two session.end events in the System Log. She does not open the bastion host inventory. Host ops-jump-01, /home/deploy/.ssh/authorized_keys, line added 12 March 2026, commented leo-hart-temp-migration. At 03:04 Priya tells Marcus the access is removed. At 03:09 the inject's auth.log on ops-jump-01 shows Accepted publickey for deploy, key fingerprint ending 9f2a1c, comment leo-hart-temp-migration. At 03:14 the scribe writes that access was removed. Facilitator stops the sitting before anyone deletes the line from authorized_keys, before anyone checks a second host for the same comment, and before the ticket closes. Nothing was deleted. The 03:09 line is the inject's line. Follow-up: Deepa removes the key from ops-jump-01 and searches every host Hart touched for the same comment, or writes why that line is still required, by 14 November 2026.
Both notes say access was removed. Only the second shows that Okta's two session.end events are an identity-provider record, and that a line added in March sits in a file Okta never reads. The first costs you the bastion. On the night this is real, deploy@ops-jump-01 keeps accepting that key after the account is dead, and a reader in March thinks the access ended at 02:57.
Okta is one control plane. The box is another.
Priya looked at the identity provider. The account is deactivated there, and the two sessions it issued are gone. ops-jump-01 does not ask Okta anything when a key in authorized_keys presents itself. SSH checks that file and nothing else. A reader who only runs the Okta System Log can honestly say the account was deactivated and still miss a key that was never provisioned through Okta in the first place.
A role session that still carries a printed expiry is a different record, in the group-edit post. That session dies on its own clock once it expires, even if nobody touches it again. This line has no clock. It sits in the file until someone opens it and deletes it. An application permission that survives a password reset is a different object again, in the Mail.Read post. That grant authenticates as an app registered inside the tenant. This key was never registered anywhere Okta can see.
A one-off key outlives the project it was cut for
Nobody added that line to hide anything. A migration project in March needed one contractor on one box for one week, and adding a key to authorized_keys was faster than routing him through the SSO-based path the rest of the team used. The plan already said what has to happen before anyone writes that access was removed: inventory every host where that person holds a credential issued outside Okta. If your plan's offboarding step names the identity provider and does not name hosts with direct keys, local accounts, or hand-issued API keys, run the free plan self-check before the next sitting. It asks whether the last test produced findings with owners, and whether they were closed. Deepa's search across every host Hart touched is that finding.
What the packet records
Write both control planes in the free evidence template: the plan sentence, ticket IT-5518, the lost-device flag, the Okta account and its two session.end events, host ops-jump-01, the authorized_keys line added 12 March 2026 and its comment, the 03:09 auth.log entry, that Priya and Marcus treated the Okta record as enough, that Deepa was absent, and her follow-up with a date. Hang the inject on the insider and third-party access family in the scenario library. That family walks a departing employee's access review, a vendor's shared credential, and a contractor offboarding checklist. It does not have a minute where an identity provider shows every session revoked and a bastion host still accepts a key that provider never issued. Add this minute, and do not fold it into a line that says access was removed. Put the file in the evidence index on the row for that exercise, with the date and the owner, so the next questionnaire finds the host nobody searched. The evidence template sits with the other record formats in the template library.
The record shows that these named people deactivated an Okta account at 02:57 and wrote that access was removed. It does not show that Leo Hart used that key for anything, or that deleting the line would have stopped a real intrusion already in progress. Searching every host he touched for the same comment is Deepa's follow-up, outside this file.
Bottom line: write the host and the file next to the identity provider. Removed is the smoothed version. The packet has to show which control plane you checked, and which one you didn't.