Chapter 5 · 1999

The keys to the kingdom

Not all accounts are equal. Some can change the system itself — and the industry finally admitted those secrets need different treatment.

Before the story splits, it needs one idea the rules era never grasped: not all accounts are equal, and pretending they are is its own vulnerability. This is the chapter where the thesis stops being about the password and becomes explicitly about the governance around it — which is, not incidentally, the business a whole industry was built on.

Think about the accounts on any real system. Most are ordinary users doing ordinary things — reading mail, filing reports — and most of the time their blast radius is small. But some accounts can change the system itself: the administrator who can create other accounts, the root user who owns the machine, the service account that quietly holds the database credentials. Compromise a normal user and you have a problem. Compromise a privileged account and you have the whole kingdom. Attackers know this precisely; it’s why the first thing a breach does is hunt for privilege to escalate to.

And the picture is subtler than two tiers, which the interactive below lets you feel. Even ordinary users aren’t uniformly low-risk. A user doing nothing dangerous most of the time may occasionally need to do something sensitive — pull a payroll report, touch production once a quarter. Risk isn’t a property of the account; it’s a property of the account in a moment. The mature answer isn’t “lock everyone down” or “trust everyone.” It’s to match the governance to the risk of what’s being done, right now — tighter proof, tighter approval, tighter logging, exactly when the stakes rise, and out of the way when they don’t.

In 1999 a company built itself on saying this out loud. CyberArk’s founding premise was that privileged secrets deserve fundamentally different treatment from user passwords — and the treatment is a catalog of everything this site means by “management of the secret.” Put the powerful credentials in a vault, not on a config file. Rotate them automatically, so a leaked secret is stale in hours. Require check-out with approval, so using the keys leaves a request and a record. Record the session, so there’s video of what the keys did. Keep a break-glass account for the day everything else is down — powerful, sealed, alarmed. None of that changes the password. All of it changes what the password is worth to steal.

That’s privileged access management, and notice it’s the same move as hashing and salting, one turn of the spiral higher. Chapter 2 protected the stored secret from a thief. Chapter 5 protects the powerful secret from misuse — by its holder, by an attacker who steals it, by accident. Least privilege, just-in-time access, the principle that you get exactly the power you need for exactly as long as you need it: these are the room divider grown all the way up into an operating discipline. The secret is still down there. The entire apparatus exists to govern it.

This is also the hinge of the whole map. Everything before this chapter is about the secret and its storage — a single machine’s problem. Everything after is about access at a distance: proving it’s really you when “you” could be anywhere on Earth, and managing that trust across systems that don’t belong to the same company. The network broke the old assumption that being at the terminal meant being authorized. From here the story runs on two rails at once.

One rail asks: how do we prove the person? Tokens, one-time codes, hardware keys, passkeys — chapters 7 and 8, the “proving the person” branch. The other asks: how do we manage the access? Tickets, VPNs, single sign-on, federation, zero trust, machine identity — chapters 6, 9, 10, 11, the “managing the access” branch. Pick a branch on the map. They braid back together at the end, where identity becomes the whole perimeter and the machines start logging in for themselves.