I took over my team about a year ago, and it's been quite a challenge. We use Okta for user accounts, and that part is fine. However, the real issue lies with the service accounts. These accounts were created directly by developers at the infrastructure level, bypassing any proper provisioning process, so Okta is completely unaware of them. I began a manual audit last quarter to clean things up, and I've discovered around 40-50 accounts I can trace to some purpose—like old proofs of concept or integration jobs that are no longer active. But there are still about 30-40 accounts where I have no record of their purpose or ownership. Many of these accounts are old and have excessive access rights because the creators just selected roles that worked at the time without considering the specific needs. I'm looking for a scalable process to manage this issue because new accounts keep getting created as the team continues to develop. Is anyone using a method that works well, or is everyone stuck doing the same manual audits?
6 Answers
If you have an InfoSec team, just give them the list of those service accounts, grab a coffee, and watch them sort it out! Seriously though, it's a significant task, but they can help you trace and track down what's really off.
This kind of confusion is super common in older setups. Honestly, your approach of manual auditing is where it usually starts. We mapped everything to see where each service account was in action—tasks, app pools, etc.—and categorized them into ones we knew, the unknowns, and the probably dead accounts. For unknown accounts, we disabled them and monitored for any breakage before deciding to remove them. For accounts with too much access, we rotated their credentials and tightened the access per system individually instead of using those broad 'god' accounts. The key is establishing a process with proper ownership and regular reviews.
Is the service account issue also related to other systems like AD or AWS? You could leverage Okta's capability—albeit it's not great—to extract accounts from your infrastructure solutions and clean up those that weren't created via Okta. If you're inclined to DIY, pull accounts programmatically at intervals. Disable any accounts that aren't in your Identity Provider. Your developers really shouldn't have the ability to create these service accounts on their own in the first place!
For those 30-40 unknown accounts, we usually check the authentication logs and see when they last authenticated. If anything hasn’t logged in for 90 days or more, disable it right away. For accounts still in use, we trace back the source IP in the logs to see what’s actually calling them. Often it just boils down to a handful of real integrations while most others are just lingering without purpose. If something breaks, someone will definitely let you know soon enough, and you’ll have clarity on what that account was being used for.
We turned chaos into a controlled environment by ensuring all accounts are managed. I’m not an expert on Okta, but I imagine it can handle service account management. Start a project to oversee all accounts—if no one claims responsibility for an account, disable it. Implement a lifecycle management process where owners confirm the accounts' necessity periodically. And don't forget to get support from management to avoid pushback.
We had to take a serious approach by disabling unknown service accounts initially. We traced their usage through logs and then mandated that all new accounts go through a structured process with an owner tagged. Otherwise, they'd just keep multiplying!

Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures