Articles: algorithm integrity in FS | Risk Insights Blog

Reviewing service and generic accounts

Written by Yusuf Moolla | 05 Aug 2026
TL;DR
• User access reviews typically focus on human users.
• Service and generic accounts are sometimes ignored or missed.
• They tend to hang around, often with more access than they need.

 

This recent article was about access that gets left behind when someone leaves. That's about people. But there's another set of accounts that we need to manage.

Service accounts run the connections between systems: a model pulling features from a warehouse, or a scoring engine writing back to a decisioning platform.

Generic accounts are shared logins, like "modelops", where several people might use the same credentials.

These accounts matter: when a customer questions a decision, or when we need to show how a model came to be set up the way it is, the underlying process can very easily involve these types of accounts.

When I first started auditing ~20 years ago, we didn’t touch these much. They have become both more important, and more risky, over the last decade or so. That’s why system audits usually include them nowadays.

 

There are at least three problems with these types of accounts:

1. They linger

Offboarding is triggered by a person leaving, which has no effect on these accounts. Regular access reviews often miss them, or ignore them.

So old accounts, like those set up for a project that has since finished, can still be there. Nobody removes them because nobody's sure what will break. A fair concern, but it's also an argument for checking what they’re used for, not for leaving them alone.

2. They can be powerful

It's easier to grant broad access than to work out the minimum.

A service account that only needs access to one table might have write access across a database. For example, access was thought to be the source of an error, so we granted more. We then found the real coding error, but forgot to take that extra access away.

A generic account set up for testing might also be able to change model settings. It needed to at the time we were testing. The architecture has now changed, but the access remained.

3. They can’t always be tied to a person

Generic account credentials get shared, written down, and passed on. When someone leaves, the password often doesn't change.

Because activity shows the account name rather than a person, a change made through one of these accounts can't be traced back to anyone. If a model threshold changes and the log says "modelops", we can't tell who did it or whether it was approved. You might be able to trace the IP or link the login to a known laptop, but this doesn’t always work.

 

Where to start

List the service and generic accounts that the decision system uses, then:

  • make sure each one has a named owner
  • check what they can do, and remove access they don’t need (carefully, since something may depend on it)
  • check when the credentials were last changed (change if it’s been a while, then plan for how to do that going forward)
  • start monitoring their use, or at least when they’re accessed.

 

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.