What’s Lurking in the Shadows? Inactive Accounts

Recently we talked about Shadow IT. Today’s topic is related: inactive accounts.

Let’s think about those shadow IT applications and services, including those that you brought in from the cold (once you discovered them). The person who first tried them out will have set themselves up with an account; perhaps the whole department had accounts. When you tested the program or service, to see whether it was suitable, you probably set up an account for yourself.

Perhaps these test accounts were shared, so that various people could explore the software or service, to help you make the decision whether to keep it or not. Once testing is complete, and the decision made, did you remember to delete all those accounts?

Sometimes, access details are shared with third parties, either for collaborative work, or so that the third party can solve a problem. On the other hand, an individual user may have multiple accounts, for different purposes (as a buyer perhaps, an admin, or a user), but doesn’t use one or more of them.

Occasionally, someone leaves the company, changes department and no longer needs their account—but nobody closes it down.

Sometimes you are still being charged for these unused accounts (if, for instance, a cloud service is charging you per user). These stale, inactive accounts are a security risk, because a malicious intruder could use one without being noticed. Depending on the access given to the original holder of the now-stale account, the intruder could have wide-ranging access to your IT network and systems, and to your data. This can give them the chance to steal sensitive information, whether this is company confidential, or customer information.

How will the intruder know that there might be a stale account within your company? Social media (LinkedIn, for example), can be a useful source of information about who has recently left your employment.

This is related to shadow IT because if you don’t know that an employee was using a particular application or cloud service before they left, then you won’t know that you need to secure the account, and retrieve any data that is stored in there.


What to do about inactive accounts?

The key here is to control access permissions, only assigning permission when needed, and removing access permissions as soon as they are no longer needed. Plus, of course, checking that there are no stray accounts ‘left over’ from testing, or other such activities:

  • Review all access permissions regularly.
  • Don’t give end users access to more than they need to do their jobs.
  • Identify stale accounts by looking for ‘last log-in’ date, if you can—any that have been inactive for over 30 days should be investigated, to find out if the account owner no longer needs them.
  • If you can’t identify ‘last log-in’ dates, you could ask each employee what applications/services they are using, perhaps quarterly and as they leave your company.
  • Disable accounts as part of the offboarding process, and any stale but enabled accounts that you find (often disabling is a preliminary stage to deleting, in case information held in that account is still needed by the organisation).
  • Shut down disabled accounts after a set period, having made sure that you’ve transferred out any information that is still needed.
  • If you don’t have one, create a ‘joiners, movers and leavers’ policy (JML policy) to put structure around access permissions.
  • If you must share access with an external group, put tight controls around that access—and remember to remove it as soon as it’s no longer needed.


Looking for more information and advice on this, or any other cyber security issue? Contact the Click and Protect team on 0113 733 6230, or contact us via our contact form.