Privileged access managementArchitecture and deployment options, explained

Most organisations hold a small set of accounts that can do almost anything inside their systems: the accounts with administrator rights. Because those accounts are so powerful, they are the first target in a serious breach. Privileged access management, usually shortened to PAM, is the discipline of controlling them.

This article explains how a PAM system is put together and the main ways it can be deployed. It is written for readers who need the shape of the thing rather than a product manual.

What privileged access management does

A PAM system places a controlled layer between people and the powerful accounts they need to use. Instead of handing out a password, it lets a person borrow the access for a short time, watches what they do, and records it. Three promises follow: secrets are hidden from the user, sessions are auditable, and access can be granted or withdrawn on demand.

Regulators and frameworks treat this as an expected control. Useful references include the NIST Computer Security Resource Center, guidance published by the US Cybersecurity and Infrastructure Security Agency, and the community standards at OWASP. For depth, see the NIST catalogue entry for security and privacy controls and the OWASP Cheat Sheet Series.

Core components

Although products differ, most PAM platforms are assembled from a recognisable set of parts.

• A secrets vault. The encrypted store that holds credentials, keys and certificates, and the engine that rotates them on a schedule.
• A policy manager. The component that decides who may reach which system, for how long, and under what conditions.
• A session manager. The brokered gateway that opens the connection, often without ever revealing the underlying credential, and records the session for review.
• Application identity services. Tools that let software, not just people, obtain secrets securely, so passwords are not hard coded into scripts and programs.
• Reporting and analytics. The layer that turns session logs into evidence: who used which account, when, and whether anything looks unusual.

Deployment choices

A PAM platform can be run in several ways. The right choice usually follows from how much control an organisation wants and how much it wants to operate itself.

• On premises. The organisation runs every component in its own data centre. This gives the most control and suits strict data residency rules, at the cost of buying and maintaining the hardware and keeping it patched.
• Cloud hosted. The platform runs in a cloud environment. This reduces the upfront build, scales with demand, and shifts routine maintenance to the provider.
• Hybrid. Some components stay on premises while others run in the cloud, which can balance control over sensitive systems with the flexibility of cloud services.
• Managed service. A specialist provider operates the platform on the organisation's behalf. This suits teams without the staff to run PAM themselves, and adds outside expertise and oversight.
• Virtual appliance. The components are bundled into a single virtual machine. This keeps deployment quick and is often chosen by smaller teams that want the capability without a long project.

Whatever the choice, the objective is the same: keep powerful accounts under control, make every use of them visible, and be able to prove it. That combination is what turns privileged access from a hidden risk into a managed one.

Related reading

Developers who work across enterprise platforms may also want the Workday Studio Developer Bootcamp guide, which explains how integration training is structured.