Orphaned access: what removal leaves behind

Granting access to an application often takes more than one step. That's true for modelling systems, and just as true for the systems we rely on every day: loan application systems, fraud management platforms, claims workbenches and pricing engines.

Removing access should take the same number of steps. It often doesn’t, and this creates risk.

We've written before about deprovisioning user access. This is one specific gap worth checking even where a deprovisioning process already exists.

More incentive to follow up when requesting than when removing

If an onboarding step is missed, the user can't do their job, and they'll follow it up.

Offboarding doesn't have that same pressure. Unless offboarding is automated (well), removal is often at one of the layers, not everything that was done to grant access. So someone might remove access inside the app; the rest remains, unnoticed, because it’s not immediately affecting anyone.

Two examples

App provisioning vs. app access

Some systems require an application to be installed before a user can access it. This could be through a company portal. Getting a new starter working then takes more than one action: provision the app through the portal, then grant them access inside it.

When the user leaves or changes roles, we need to remove both the access within the app, and access to the app in the portal.

App access vs. network-level access

Many modern systems use single sign-on (SSO). Access is enabled by adding the user to a network group, separate to access within the app itself. If the app only allows SSO, there’s no access without this step.

Again, when the user leaves or changes roles, we need to remove both the access within the app, and the network group membership.

The dormant risks

I see each of these often (probably too often) when reviewing access controls:

1. Returning users

Mature organisations don't reissue a leaver's ID to a different person, and that's the right control. But rehires and re-engaged contractors can get their old identity back. Any previously leftover access may then be re-activated. This can happen without a new approval, and without anyone realising it was there.

2. Clutter, or obfuscation

Regular reviews of system access are hard enough. When the list is filled with these orphaned records that don’t map to current users, it’s easy to ignore them because there’s no immediate risk. We have other priorities.

Bith risks matter more here than for ordinary office tools, because these systems decide things about customers. Someone with leftover access to a lending system might see or touch applications they no longer have any business reason to.

What to check

If we don’t have automated cross-system deprovisioning, we should map provisioning properly: list every system and layer touched when someone gets access, not just the main request. Then:

• Every step in provisioning should have a matching removal step.
• Don't assume your periodic user access review catches this. They’re often done per application, against the app's own user list. Network groups and portals are sometimes, but not always, included.
• Take a sample of departed or rehired users and check against the various access lists, including network groups (for SSO).

Disclaimer: The info in this article is not legal advice. It may not be relevant to your circumstances. It was written for specific contexts within banks and insurers, may not apply to other contexts, and may not be relevant to other types of organisations.