Why does old access outlive the job?

Old access persists beyond its intended purpose and most organizations never monitor it. New access rights arrive within a day of a request. Old rights get revoked, if they get revoked at all, only upon prompting someone. Tools that assist employees in confirming, rotating and vaulting their service accounts have taught me again and again that removing access has to be as thoughtful as granting access. Security professionals can bridge this chasm with simple changes to their policies for role moves and access reviews. This happens all the time. An employee moves from one team to another. The new manager approves the access needed for the new role within a day, and the person is productive by lunch. The access from the old role stays. After months, access review has one query only: “Do you still need it?” The reviewer sees the name next to the entitlement, but nothing on the dashboard shows whether it has been used since the move. It is hard to click no, because something might get broken. They have never been bothered to click yes. Thus, they click yes, and it’s fine by them. Why is granting access easy but removing it hard? Granting has an owner and a deadline. A manager submits a request, an approver clicks yes and the process is completed in just a few hours since someone is involved in it. Removal does not have any of the two. Nobody opens a ticket when permission becomes unnecessary, as the only person who notices will not submit the ticket for lack of reason to do it. The cost of maintaining the permission is high, but it is not visible and it comes in the future. The incentives work the same way. Nobody evaluates how low an access level their team maintains, while a permission that was mistakenly removed and became necessary results in an irate support ticket submitted the same day. And this is something that has to be done via reviews, but, in my opinion, is not done like this. And, at least in all attestation and recertification activities I was involved in, there is simply a basic question for the reviewer: is access still valid? Saying “yes” is not really difficult — access was granted, there were no actions following and reviewing several hundred takes less time than investigating one particular access. This is not what will appear on your screen. When reviewing account names, you do not know whether they were used last week or last year. Role-based access control helps here, but the problem is that, when a user changes his role, his role gets updated, but not the direct access, groups and folders he acquired during the time. What does leftover access actually cost? I have to be quite careful here, as this metric does not reflect the access that remains. The 2026 Verizon Data Breach Investigations Report demonstrated that exploitation of vulnerabilities was the most frequently used method of the breach, making up 31% of all breaches, while the previous leader — abuse of credentials — was reduced to 13%. However, I want to emphasize that this particular report is unrelated to the issue of obsolete permissions. Yet, what the intruder could do after penetrating the system depends on the permissions of the breached account, which in turn depends on the number of permissions acquired. In practice, it looks like findings of audit and investigation, which go on forever, because nobody knows whom exactly to permit to access the corporate data. However, there is information proving the case of the leavers, although quite meager. Thus, according to the PasswordManager.com survey carried out in March 2023, among 1,000 American workers, 58% of the workers who responded that they had used the passwords of their previous employers admitted that they had never updated their passwords after leaving the company. It is an opinion survey carried out online, and that is why it is an indicator. Indeed, I noticed this too: The departures have to go through the HR offboarding checklists, but not the permissions and certificates created by hundreds of people over many years. Transfers are even more of an issue and there are fewer studies regarding them. In the case of a leaver, at least something happens — the offboarding process is triggered. Nothing triggers in case of a transfer. And thus I think that transfers should be equally important as terminations, because the standards require exactly that. NIST SP 800-53 Rev. 5 — security and privacy control catalog used throughout organizations — contains AC-2 and AC-6 account management and least privilege controls requiring review of accounts, processing of transfers and terminations, and granting only privileges required by the role of the individual. 3 fixes that make leftover access hard to ignore And here is how I will make sure that the changes will be adopted. There is no need for any new technology to be implemented. Just the decision regarding the ownership of the deletion process. 1. Every change in position will be regarded as an event of deletion Start from the HR record of the system. After the change takes place, generate a task for the outgoing and incoming manager where there will be only one question for the manager to answer — what will the individual no longer need? Provide them with the access list and 10 minutes to answer the question. All the access the individual had created during this period needs to have an owner. If you only do one of these three, do this one. 2. Each permission must have its own unique owner and expiration date Permissions or access to the project folders, special permissions or access to the production system must expire on a particular date, which could be either the date the project expires or, by default, three months after its issuance, unless renewed by the owner, who must be a named person, not an e-mail address. I think of the account, the owner and the applications it accesses as a graph, because if there is any change in accounts, then with one query, it can determine what he/she owns and his/her dependencies. Renewal must be a one-click option, but in the event of that person’s no longer being available, it should be done through his/her manager so that it does not get lost in the cracks. It is a default setting. In the current scenario, if you do nothing, it is your permission; hence, laziness is the dangerous path. Do not make the default action renewing the permission. 3. Present last-used information on all reviews, and allow people to act on it Pull last login and last activity timestamps from your identity provider and application logs and present them along with each entitlement. Order the list such that the least used access appears at the top, select it for removal and ask the reviewer to explain why they need to keep it. From experience, I have found that people are happy to confirm when “this entitlement hasn’t been used in seven months” shows up on the screen. Then allow them to take action based on what they think is best. If attestation takes place using one tool and rotation/vaulting takes place using another tool, then you would find people confirming the question and skipping the action. That’s why I’ve started to keep attestation, rotation, vaulting and retirement of access in one process. Remember, however, there are limitations to this approach. Not all applications maintain usage logs, and sometimes there is legitimate access that is rarely used. Take the case of quarterly close accounts and break glass accounts, for example. They should be assigned an owner and a note. While employees will be able to identify what they don’t need anymore, this is effective only when there is a system in place which allows them to do so safely and easily, and this is yet another reason why we need to implement the three above fixes. In this quarter, start with a single system where sensitive data is stored and run a last-used report on that system. Begin with the users who have been moved to a different role within the past year, since no one has reviewed their access rights since then. Send a list of all those users who haven’t used that system in the past six months to the system owner, and ask them one simple question — Do they still require this? The findings will be enough to make the case for the rest stronger than any framework.