By Yair Knijn · August 5, 2025

The IT manager who offboarded the admin's email but not his standing exception to the web filter

The senior admin left on a Friday, and by Monday the offboarding playbook had run end to end. Mailbox converted to shared, SSO sessions revoked, VPN cert pulled, laptop wiped, MFA tokens deregistered. The Entra access review came back clean a week later. By every measure the identity team tracks, the person was gone.

One thing went untouched: the filter policy. Over two years the departing admin had built a personal set of overrides in the web filter, and they do not live in any directory. They are not an account, so no IAM review flags them. They keep enforcing, on the authority of someone who left the org chart.

Why exceptions outlive the people who made them

Offboarding is built around identity. Disable an account and everything chained to it collapses with it. A filter exception is chained to nothing. It is a standing rule that allows a domain for a group, and it runs long after its author is gone. The OWASP Non-Human Identities Top 10 ranks improper offboarding as NHI1:2025, its top risk: an admin leaves, and nobody revokes the standing access they configured. Teams read that as forgotten service accounts and API keys. A leftover allow rule is the same failure with a different label, legitimate enough that no SOC will question it.

The "temporary" allow-list that became permanent

You can usually reconstruct how an old exception got there. The admin needed to test against a domain the malware category was blocking, added a temporary allow, and never pulled it. A second domain followed. Then a vendor tool the filter kept flagging. Six months on there are nine entries, none with an expiry, and no ticket for why three exist.

The admin leaves; the allow-list stays. If one of those domains is later re-registered by an attacker, or was a lookalike from the start, the filter passes the traffic straight through. The control you bought to stop command-and-control callbacks is now the one path watching nobody.

Tying exception ownership to identity lifecycle

Every exception needs a named owner who is a current employee, and ownership has to be a field the system enforces, not a line in a wiki. The moment an owner is offboarded, their exceptions should surface as orphaned and queue for review. This is the hygiene OWASP asks for with service accounts: no machine identity, and no policy override, should outlive its sponsor without a handoff.

• Stamp each exception with its creator, a business justification, and an expiry date at creation.
• On any departure, pull every exception that person authored and force a re-justification by someone current.
• Treat an exception with no living owner as a finding, the way you treat an enabled account with no manager.

Auto-expiring overrides and mandatory re-justification

The most durable fix is to make permanence impossible by default. Give every override a time-to-live. A test allow gets a week. A vendor exception gets a quarter, then a renewal prompt that demands a reason. When the clock runs out the rule lapses and the requester argues for it again, so stale entries retire themselves. This also feeds NIS2, which expects documented procedures across the security lifecycle, offboarding included. A renewal log of who re-justified what, and when, is the evidence an audit asks for.

Auditing standing exceptions during offboarding

Add one line to the offboarding checklist, beside "revoke VPN" and "disable account": list and reassign every filter exception this person created. That is a query, not a project, if your filter can report exceptions by author. If it cannot, that is the gap, because you are trusting that nobody made an undocumented standing change.

ClearScreen ties every override to its policy group and to its creator, with expiry and justification as required fields. When that person is offboarded, their orphaned exceptions surface for review instead of enforcing forever. See how ownership and expiry work on the features page.