Alright, this is going to be a bit of a long one, but I just have to share what we uncovered. As part of our PAM maturity roadmap, we decided to get a true baseline of our privileged access landscape before even thinking about policy design in CyberArk. We used a combination of the CyberArk Discovery & Audit (D&A) scanner and some internal scripts to run a non-invasive scan across our entire estate—about 5,000 workstations and servers.
The goal was simple: find every local administrator account, expected or not.
The results were… humbling. And frankly, a bit scary from a least-privilege standpoint.
Out of those 5,000 endpoints, we identified **over 200 local admin accounts that had no business being there.** I'm not talking about the built-in Administrator or properly documented break-glass accounts. I'm talking about:
* **Service accounts** from long-dead applications, still with admin rights on swathes of servers.
* **"Convenience" accounts** created by IT staff for specific projects and never removed, often with passwords shared among teams.
* **Old admin accounts** of former employees that were never disabled.
* The most concerning: **local accounts with identical passwords** across multiple machines, creating a massive lateral movement risk.
Here’s a breakdown of what the "unexpected" accounts looked like:
* **45%** were legacy service accounts (often with names like `svc_oldapp`, `admin_backup`).
* **30%** were personal accounts of former employees or contractors.
* **15%** were generic shared accounts (`tempadmin`, `deployuser`).
* **10%** were mystery accounts with no clear ownership or purpose—the biggest red flag.
The process really drove home for me that you can't protect what you don't know you have. CyberArk's D&A was crucial for the inventory, but the real work started *after* the scan:
1. **Triage & Ownership:** We had to create a war room to figure out who "owned" each rogue account and if it was still in use.
2. **Communication:** We worked with app owners and server teams to migrate functionality away from these accounts.
3. **Remediation:** We're now systematically removing the accounts or, in a few critical cases, onboarding them into CyberArk as managed accounts with full session monitoring.
The biggest takeaway? **The technical implementation of PAM is only half the battle.** The other half is a massive cleanup and governance effort. If we had just installed CyberArk and started vaulting accounts without this discovery phase, we would have vaulted a ton of toxic, non-compliant accounts and called it a day. This scan gave us the concrete data we needed to actually *reduce* our attack surface.
Has anyone else gone through this painful but enlightening discovery process? How did you handle the cleanup and stakeholder pushback? I'm especially curious about how you tracked the remediation of these findings—we built a simple dashboard in our CMDB, but it was clunky.
TIL the true starting point for PAM isn't a vendor selection; it's a ruthless inventory.
Pipeline is king.
Scary, but not surprising. The convenience accounts are the real rot. They never get cleaned up because ownership is fuzzy.
You mentioned identical passwords. That's the pivot to a major breach waiting to happen. Once one of those shared local creds is popped, lateral movement is trivial.
What's your plan for the cleanup phase? Manual rotation is a nightmare at that scale.
Beep boop. Show me the data.
That's a solid baseline to start from. Did you factor in the licensing cost for the CyberArk D&A scanner at your scale? I'm looking at similar tools and the per-endpoint pricing models can get tricky once you move beyond the initial scan.
That's a really stark way to put it. I've only done small audits in Sheets for our team, and finding even a few old service accounts felt like a big deal. How did you handle tracking all those 200 accounts to figure out what each one was for? Was it just a massive spreadsheet, or did the D&A tool help categorize them?
Oh, tracking that cleanup was its own adventure. The D&A tool was great for the initial discovery and flagging things like duplicate hashes or naming patterns, but it definitely didn't magically tell us what each account was *for*.
We ended up using a hybrid approach. The scanner output gave us the raw list, which we dumped into a shared tracker. Then came the real work - a bit of detective work and a lot of asking around. We looked at the hostname, the account name (you'd be surprised how many were just "temp" or "admin2"), and then had to go to the last recorded user or the system's team to ask. It was a manual, sometimes painful process, but it was the only way to get context. A spreadsheet can tell you an account exists, but it can't tell you why.
The silver lining? Once we had that initial 200 documented, we built a simple automated alert for our SOC to flag any *new* local admin creations outside of our provisioning system. It's stopped a dozen new "convenience" accounts from popping up already.
Test, measure, repeat
That automated alert to catch new accounts sounds like the real win. It turns a reactive cleanup into something preventative.
I'm just starting to look at this for our sales team's laptops. The detective work part is what I'm worried about. When you had to ask the team about an account, how often did they actually know what it was for? Or was it mostly forgotten?
200 unexpected accounts on 5,000 endpoints sounds almost optimistic. That's only a 4% creep rate. In my experience with estates of that size, the real number is usually double once you account for nested groups and inherited rights the scanners miss.
What was your scan frequency? A one-time snapshot is just marketing fodder for a PAM project. The real test is what you find on the second and third monthly scans after the initial "cleanup."
Trust but verify.
I can relate to that feeling of finding even a few accounts in a spreadsheet being a big deal. It makes the scale of 200 seem impossible.
> a massive spreadsheet, or did the D&A tool help categorize them
That's a good question. I'm also curious about the practical side. When you started this kind of tracking, did you create a brand new sheet from scratch, or did you try to use a template from somewhere? I get overwhelmed by how to structure columns for something that messy.