Why your PAM works like an expensive password manager: three pitfalls everyone forgets about
Content
In distribution, when a large company acquires CyberArk solutions, we regularly observe a classic scenario. Everyone is happy, the CISO has checked the “PAM” box in the budget, the integrator has sold the licenses, and we have implemented the software. Then, six months later, the BAKOTECH team arrives for a health check, and we see… nothing. Actually, we see that the licenses are activated and the system is working, but it is being used like a costly Excel file to store the three administrators' passwords.
Trap #1: “Why'd you have to go and make things so complicated?”
Administrators are used to direct, fast access to systems; they hate changes. They use familiar clients (RDP, PuTTY), while implementing PAM frequently adds new, mandatory steps (web portals, multi-step logins) that users perceive as an unnecessary complication of the workflow. This creates strong internal dissatisfaction, which can lead to active bypass of security policy.
For the administrator, it's not about security but about an extra 2 minutes for each operation.
Case: A retail company implemented PAM and closed direct access to servers with a firewall. A week later, the CISO called our team to complain: “CyberArk slows down our work processes, and administrators don't have enough time to close all the tickets.”
When we started investigating, we found that the lead administrator, to avoid messing with the web portal, had opened a “back door” on the firewall and continued connecting directly. When asked “Why?”, he honestly said, “It's inconvenient for me.”
As a result, the company worked for a month, having the illusion of protection and a security hole the size of a gate.Recommendation: Don't break people's usual flow. CyberArk has a Native Experience. Configure the proxy so that the admin can continue to use his favorite RDP manager, PuTTY or WinSCP. He won't even notice that the session is going through PSM and being recorded. Security should be invisible; otherwise, it will be bypassed—this is the law.
Trap #2: Syndrome “All at Once" (The Big Bang)
The manager's disease is the desire to get “all at once”: to bring 5,000 target systems, from Windows to network equipment, into scope within two months. Unfortunately, effective implementation doesn't work that way. The team burns out, policies get confused, and failures block business operations.
Case: A transport company decided to do everything “correctly” and immediately bring 5,000 target systems into the project scope in two months. The three-person implementation team was simply overwhelmed. Chaos ensued: first, problems with policies; then access disappeared; then access requests were pending for three days.
How did it end?
The business started complaining that IT was blocking their work. The project was frozen for half a year. The investment failed to pay off, and the reputation of IT security suffered.Recommendation: Forget about perfectionism—do not bite off more than you can chew. Start with Domain Admins. Only a few dozen accounts, but they are the true keys to the kingdom. Then, move to critical $*nix$ root accounts; this will cover 80% of real breach risks. Printers and accountant workstations can wait until next year. It's better to have solid, functional control over the core than to let chaos reign at the perimeter.
Trap #3: Blind password rotation
Administrators' favorite mistake is to enable automatic password change (CPM) without knowing where those passwords are actually used.
Case: Classic story. It’s Friday evening, the customer decides to enable password autorotation for the svc_backup service account. CyberArk successfully changes the password in Active Directory; nothing foreshadows trouble. At 3 am, a critical database crashed because the backup failed, and the transaction logs clogged the disk.
It turned out that this account was used not only for the backup service but also “hardcoded” (i.e., written in text) in some old script from 2018, which the current admins didn't even know about. The script used the old password; AD blocked the account, and production stopped.Recommendation: Never enable forced rotation until you have found all dependencies. Discovery first—always. Do not enable Enforcement until the scanners (like DNA or EPM) show you a complete map of dependencies. We eliminate “technical debt” and clean the hardcode first; only then do we turn on the rotation. And never, we mean it, never do it on a Friday night.
In the end…
Buying a box with licenses is the easiest part of the quest. As a distributor, we have a certain “helicopter view” and see how these problems are eliminated (or not eliminated) in different companies. The customer is often left alone with the system after the integrator leaves, and the project stalls.
My advice: if you feel like your CyberArk has turned into a “white elephant” or see how admins draw posters saying, “Get rid of PAM”, we're here to help. Typically, the issue is solved not by purchasing new modules but by the right change in architecture and approach.
Technology should work for you, not the other way around.
For consultation, please click the button below or e-mail us at: moc.hcetokab%40krarebyc