He quit in March. His access ran until August. How does that happen?
Someone leaves the company in March. By August, their credentials still open the door.
No one broke in. No one was careless in any obvious way. HR processed the termination. IT wasn't hiding anything. The system was running. And yet — five months of open access, to whatever that person had access to when they were still an employee.
This is not a story about a villain. It's a story about a gap that nobody closed because nobody noticed it was open.
Why the access didn't get revoked automatically
The platform checks HR status once a day. When it detects a status change, it asks one question. Four buttons. Eight seconds of a human's time.
But auto-revoke — the obvious fix, the thing that sounds like it should just happen — was deliberately left off the table. The reason is specific: HR exports sometimes glitch. When they do, they can mark dozens of people as terminated at once. Forty people, in one bad export, all flagged as gone.
If the system acted on every status change automatically, a single data error could lock out forty employees in one shot. That's a different kind of problem — loud, immediate, and very hard to explain to the people who suddenly can't do their jobs.
So the design choice was made: when a status change looks anomalous, the agent flags it as a probable data error and waits. It doesn't act. It waits for a human signal.
Silence isn't a yes
That's the exact phrase worth sitting with: silence isn't a yes.
The system flagged the situation. It did its part. But flagging something and resolving something are not the same thing. If nobody responds to the flag — if the queue gets ignored, or the alert lands in the wrong inbox, or the person who was supposed to click never clicked — the access stays open.
The system was built to not make assumptions. That's correct behavior. The problem is that "waiting for a human" only works if a human eventually shows up.
In this case, nobody asked. Not in March, not in April, not at any point through August.
What this actually looks like in practice
There's no dramatic moment here. The former employee probably didn't even use the access. Or maybe they did — the post doesn't say, and that's almost beside the point.
The point is that the window was open for five months and nobody on the inside knew it. The system knew — it had flagged the status change. But a flag sitting in a queue that nobody checks is functionally the same as no flag at all.
This is what orphaned access looks like in organizations that actually have processes. Not a missing process. A process that reached the human step and stopped there.
What the design gets right — and where it depends on you
The one-question, four-button, eight-second check is a real design: low friction, hard to skip, built for the normal case. The anomaly detection — holding back on bulk terminations that look like data errors — is also a real design choice, not an oversight.
Both of those decisions are defensible. Neither of them closes the loop automatically.
The loop closes when someone responds to the flag. That means someone has to own the queue. Someone has to notice when a flag has been sitting there for longer than it should. The system can wait indefinitely — humans have to decide that indefinitely isn't acceptable.
Five months is the answer to the question: what happens when the human step gets skipped? Not skipped on purpose. Just skipped because nobody remembered to ask.