If you are trying to understand Privileged Access Management (PAM), and can’t wrap you head around it, here’s an analogy that the BeyondTrust team came up with – inspiring me to write this blog.
Imagine you’re traveling for work, in a new city. You arrive to your hotel late at night. Earlier that day you checked into your hotel and were issued a plastic access card (room key) to enter the premise. Prior to travel, you made a reservation to the location, duration, room preferences, and time of arrival. These details are important and we will revisit them again later. So the scene is set, it is about 11pm local time…
You park your rental car in the visitor lot and proceed to the lobby. A quick pull on the door reveals that it is locked. A small sign on the door states, “After 11pm – Please Use Your Room Key to Enter”. You’re tired, reach into your wallet, and insert your key in the slot. The door open opens. For discussion sake, let’s call this step A. You have been granted privileges to access the hotel lobby.
Step B, now requires you to go to your room. You navigate the open floor plan of the hotel and have access to only basic necessities. This includes the check in desk, bathrooms, and the bell stand. You can’t get any luggage from them however unless you have a claim ticket. You could almost think of this as a certificate you would need to give them to gain access to your luggage and it matches the ticket stub on your stored.
So, you find the elevator, press the up arrow, and wait for it to arrive. The door opens, and like a text based video game, you enter. You attempt to press your floor number but the light does not illuminate. Just above the keypad is another note, “Please Insert Your Room Key and Press Your Floor to Access.” In compliance, you do just that and for discussion sake, we will call it Step C. As I mentioned it earlier, and you are very tired. You hit the wrong floor number and it does illuminate. You quickly notice your mistake and select the correct floor but now have two buttons illuminated. This is Step D, and you must wait until the door opens and closes on the wrong floor before you proceed.
Your floor now opens and you exit the elevator car. Did I mention, you are now really tired. You approach a room, insert the key, and the LED illuminates red. You try again with the same results. You look up, realize it is the wrong room, and hear someone walk towards the door. You may have tripped someone’s sixth sense interns of personal security. Your mistake, now Step E, you proceed down the hall to the correct room number and try again. This time, the door opens, Step F, and you enter the room. You place your bags down, return to the door and lock the dead bolt as Step G. You are safe in the room in the room until the morning. Needless to say, you still have to deal with the left over cigarette smell, residue on the bed frame, and other not-so fancy frills of your room. That wraps us up at Step H.
So how did this all start and how does it translate to privileged access management? First it starts with your hotel. You had a reservation with details about your stay. This process is akin to identity and access management (IAM). A room was provisioned under your name for the days you (or your travel agency) requested and you were granted access (via a key card) to access the hotel. The details about your activities, including all steps, and missteps you took in the hotel, including arriving later and trying the wrong room are the responsibility of privilege access management
So here are the steps and how they relate to privileged access management:
- Step A – Access to the hotel. This is the most basic step of PAM. Most people equate this to a password safe, vaulting, or storage technology. It is the initial step in gaining access to an asset but says nothing about the permissions and privileges you have once you have access. You could have accessed the hotel as a guest or the owner. The initial result is the same but what happens afterwards and what you can do later is the remainder of the PAM model.
- Step B – Hotel lobby navigation. This is the basis for aleast privileged model. A guest has visibility into basic operations of the lobby, including the elevator door but a true admin could access the service rooms, back desk, and even luggage room unrestricted. For a user, you only want to provide the privileges they need to get the job done regardless of operating system and application. Remember, the asset in this case is analogous to the hotel.
- Step C – Elevate floor access. This is analogous to the granularity given to permissions of a command or application. You need to specify what applications are available to a user and policies dictate how strict they can be down to a hash or more high-level to a vendor or directory. For the elevator, you have access to a floor but the privileges you are granted may have been too broad.
- Step D - Wrong floor select. The least privilege model was too loosely written. The user was given access to all floors verses the one specifically for their room key. What risk does this represent? Not much to the single individual user but to anyone tailgating the elevator ride. This is analogous to a hacker. They can press any floor after you and potentially jump into a party room or commit a crime.
- Step E – Wrong room attempted. This is a pure visibility and privileged access. The wrong room attempt should have sent an event to a log or in the IT world a SIEM. The privileges of your card only allow you access to your room and none others. A maintenance team, cleaning crew, or manager however may have a key that allows access to all rooms and represents root access.
- Step F – You enter your room. This is successful authentication based on your privileged access. Your room represents a command or application only that you have administrative privileges too. You can do anything you want in your room since you are the admin. If you break furniture, flood the room, or blast the TV you may get in trouble. Basically you abused your privileges as administrator in the room.
- Step G – Locking the door. This ensures concurrent session management is adhered too. You alone are the room unless you allow someone access to the room.
- Step H – Cleanliness of the room. Your room just like an application, was problem used (or installed) by someone else. If they had administrator access, they may have left a configuration, patch, or vulnerability mess. Having knowledge about the hotel and room is key to managing the application and especially the expectations.
This all translates to the actual flow for privileged access management. This analogy translates to all the basic requirements from secure access to an asset, privileged access to an application, a consolidated authentication store, and auditing of all actions and activity. An asset is the hotel, privileges is what the key card can do and access, the consolidated authentication store is the actual key card and back end system, and reporting is logging of any key card access and usage. All the pieces protect the hotel and ensure guests are safe, just like IT users and administrators.
BeyondTrust Privileged Access Management is designed to manage this complete lifecycle. We solve the following the use cases for PAM:
- Need secure access to an asset – Password Safe (the hotel)
- Manage privileges – Endpoint Privilege Management (Windows, Mac, Unix, Linux, etc.) (what the keycard can do)
- Document and mitigate risk – Vulnerability Management, BeyondInsight (Identifying the tailgate rider or that multiple floors can be accessed)
- Audit and report on activity and changes – Auditor (report on key access and changes)
- Centralize User Accounts – Active Directory Bridge (allow for any system, user, administrator, to use the same type of keycard)
If you’re in the process of building your own privileged access management strategy, download this whitepaper ‘7 Steps to Complete Privileged Access Management’. If you’re interested in integrating your IAM solution with PowerBroker, check out this technical brief. And as always, contact us for more information.

Morey J. Haber, Chief Security Officer, BeyondTrust
Morey J. Haber is the Chief Security Officer at BeyondTrust. He has more than 25 years of IT industry experience and has authored four books: Privileged Attack Vectors, Asset Attack Vectors, Identity Attack Vectors, and Cloud Attack Vectors. He is a founding member of the industry group Transparency in Cyber, and in 2020 was elected to the Identity Defined Security Alliance (IDSA) Executive Advisory Board. Morey currently oversees BeyondTrust security and governance for corporate and cloud based solutions and regularly consults for global periodicals and media. He originally joined BeyondTrust in 2012 as a part of the eEye Digital Security acquisition where he served as a Product Owner and Solutions Engineer since 2004. Prior to eEye, he was Beta Development Manager for Computer Associates, Inc. He began his career as Reliability and Maintainability Engineer for a government contractor building flight and training simulators. He earned a Bachelor of Science degree in Electrical Engineering from the State University of New York at Stony Brook.