Privileged Access Management (PAM): Keeping Admin Accounts Under Control

Why privileged accounts deserve special attention

Not all user accounts are equal. A normal employee account has access to emails, documents and the line-of-business applications needed for daily work. If this account is compromised, the damage is limited. A domain admin account, however, has access to the entire Active Directory, can create and delete users, change group policies and access every server on the network. If this account is compromised, the attacker has complete control over the entire IT infrastructure.

This asymmetry makes privileged accounts the preferred target of attackers. The typical attack progression begins with a compromised standard account, perhaps via phishing or stolen credentials. From there, the attacker moves laterally through the network, specifically seeking privileged credentials. Techniques such as Pass-the-Hash, Kerberoasting or extracting credentials from memory (Mimikatz) enable the attacker to gain admin rights -- a typical scenario described in detail in the article on compromised admin accounts -- without knowing the actual password. Once the attacker has domain admin rights, they can install backdoors, exfiltrate data and deploy ransomware.

According to the Verizon Data Breach Investigations Report, over 80 per cent of all security incidents in which an attacker gains deep access involve compromised privileged credentials. CrowdStrike reports that the average breakout time -- the time from initial access to lateral movement -- is under 80 minutes. Within this short window, the attacker must be detected and stopped before they gain privileged rights.

What are privileged accounts?

Before you can implement PAM, you must understand which accounts in your company are considered privileged. The list is often longer than expected.

Domain administrators have full control over Active Directory and thus over the entire Windows infrastructure. This includes members of the Domain Admins, Enterprise Admins and Schema Admins groups as well as the built-in Administrator account.

Local administrators have full control over a single server or workstation. The built-in local administrator account exists on every Windows system and often has the same password across many systems, making it a particularly attractive target.

Root accounts on Linux and Unix systems have unrestricted rights on the respective system. This includes both direct root login and accounts with unrestricted sudo rights.

Database administrators have access to the databases and thus to the most sensitive data in the company: customer data, financial data, personnel data. A compromised DBA account enables the exfiltration of entire databases.

Cloud administrators manage the cloud infrastructure in Azure, AWS or Google Cloud. A compromised cloud admin account can create virtual machines, copy data or delete the entire cloud environment.

Network administrators configure firewalls, switches and routers. With these rights, an attacker can modify firewall rules, redirect traffic or merge network segments.

Application administrators manage business-critical applications such as ERP systems, CRM platforms or HR software. These accounts often have extensive rights within the application, including access to all records.

Service accounts are technical accounts used by applications and services to authenticate against other systems. They often have privileged rights, run around the clock and are rarely reviewed.

The four pillars of PAM

Privileged Access Management is not a single tool but a concept that combines several measures. The four pillars together form comprehensive protection for privileged access.

Password vaulting

The first pillar is the secure storage of privileged credentials in a central, encrypted vault. Instead of storing passwords in spreadsheets, text files or sticky notes, they are placed in a system that provides access controls, encryption and audit logging.

The principle is simple: no administrator knows the actual password of a privileged account. When they need access, they check the password out of the vault, use it for the task and check it back in. The vault logs who checked out which password when and how long it was used.

In its simplest form, a password manager like KeePass (local) or Bitwarden (central) can serve as a vault. For smaller companies, this is an acceptable starting point. Enterprise PAM solutions additionally offer automated checkout/check-in workflows, approval workflows for access and integration with the ticketing system.

Automatic password rotation

The second pillar is the regular, automatic changing of privileged passwords. Manual password changes are in practice forgotten, postponed or carried out with predictable patterns. Automatic rotation eliminates these human weaknesses.

A PAM solution changes a privileged account's password on a defined schedule or after each use. The password is automatically generated (long, complex, random), stored in the vault and changed on the target system. The administrator needs to do nothing because they do not know the password anyway -- they check it out of the vault when needed.

For local administrator accounts on Windows systems, Microsoft offers LAPS (Local Administrator Password Solution) as a free solution requiring no separate PAM software. LAPS generates a unique, random password for the local administrator on each system and stores it in Active Directory (or in Entra ID with the newer version). The password is regularly rotated automatically, and access to stored passwords is controlled via AD permissions.

Session recording

The third pillar is the complete recording of privileged sessions. When an administrator performs a task on a critical system, the entire session is recorded: keystrokes, screen content and executed commands. These recordings serve multiple purposes.

First, they enable forensic analysis during security incidents. If a system is compromised, you can use the session recordings to trace which actions were performed and whether they originated from a legitimate administrator or an attacker.

Second, they create accountability. When administrators know their actions are being recorded, they act more carefully and adhere to defined procedures. This is not mistrust but a protective mechanism that also protects the administrator: if something goes wrong, the recording can prove they acted correctly.

Third, they support compliance. ISO 27001 requires in Annex A.8.15 (Logging) the logging of security-relevant events. Session recording for privileged access is one of the most effective implementations of this requirement.

For companies that cannot deploy a full session recording solution, logging on the target systems is an alternative. PowerShell Transcription and Script Block Logging on Windows, auditd on Linux and the native audit functions of databases and cloud platforms at least capture the executed commands.

Just-in-time access

The fourth pillar is time-limited access. Instead of granting permanent admin rights that are active around the clock, rights are granted only on demand and for a defined time period.

The workflow is as follows: the administrator requests access via a self-service portal or ticketing system. The request is approved automatically or manually. Privileged rights are activated for the requested duration. When the time expires, rights are automatically revoked.

In Entra ID, this function is called Privileged Identity Management (PIM). PIM enables the time-limited activation of Entra ID roles (e.g. Global Administrator) and Azure resource roles. Activation can require an MFA challenge, a justification and approval by a second administrator.

For on-premises environments, a similar concept can be implemented with temporary group memberships in Active Directory. The administrator is added to the admin group for the duration of the task and automatically removed after expiry. PowerShell scripts or PAM solutions can automate this process.

Least privilege: the foundation

All four PAM pillars build on the principle of least privilege. This principle states that every user, every process and every system should receive only the minimum rights required for the respective task.

In practice, this means a fundamental change: administrators work by default with a standard user account and switch to a separate admin account only when needed. This admin account has only the rights required for the specific task, not the master-key rights of a domain admin.

Implementing least privilege begins with inventory. Who has which privileged rights? Which of these rights are actually needed? Experience shows that this analysis regularly reveals surprises: accounts with domain admin rights that have not been used for years, employees with admin rights who changed departments long ago, and service accounts with extensive rights whose purpose nobody remembers.

Tiered administration in Active Directory

For companies with Active Directory infrastructure, the tiered administration model (also known as Red Forest or Enhanced Security Administrative Environment) is a proven approach for structuring privileged access. The model divides the infrastructure into three tiers.

Tier 0 comprises the identity systems: domain controllers, Entra Connect, PKI servers, PAM servers. Only Tier 0 administrators may access these systems, and they must never use their Tier 0 credentials on a system in Tier 1 or 2.

Tier 1 comprises the server infrastructure: file servers, database servers, application servers. Tier 1 administrators manage these systems but have no access to Tier 0 systems.

Tier 2 comprises the endpoints: workstations, laptops, printers. Local IT support manages these devices but has no access to servers or domain controllers.

The strict separation prevents an attacker who compromises an endpoint (Tier 2) from directly accessing a domain controller (Tier 0). Instead, they must work through each tier individually, which lengthens the attack chain and provides more opportunities for detection.

The practical implementation requires separate admin accounts for each tier. An administrator who manages both servers and endpoints has three accounts: a normal user account for daily work, a Tier 1 account for server management and a Tier 2 account for endpoint support. The tier separation is enforced by Group Policies that prevent a Tier 0 account from logging in to a Tier 2 system and vice versa.

PAM without an enterprise solution: the pragmatic starting point

Not every company can or wants to deploy an enterprise PAM solution like CyberArk, BeyondTrust or Delinea. These solutions cost six-figure sums and require dedicated staff to operate. For a mid-market company with 50 to 500 employees, there is a pragmatic starting point that implements the most important PAM principles without requiring a large budget.

Separate admin accounts: Every administrator receives a separate admin account used only for administrative tasks. The normal user account is used for emails, browsing and daily work. This separation prevents a phishing attack on the user account from directly compromising admin rights.

LAPS for local administrators: Microsoft LAPS ensures each system has a unique, regularly rotated password for the local administrator. Setup is straightforward and free.

MFA for all privileged access: Every access to a privileged system requires a second factor. This includes Remote Desktop connections to servers, access to the Azure/Entra portal, logins to network devices and access to database management tools.

Privileged Access Workstations (PAWs): For Tier 0 administrators, a dedicated workstation should be set up that is used exclusively for administrative tasks. No email client, no browser, no internet access. At minimum, this can be a hardened virtual machine accessible only via a jump server.

Central logging: All sign-ins to privileged systems are centrally logged and regularly reviewed. Windows Event Forwarding can send the relevant events from all servers to a central collector.

Documented break-glass procedures: For emergencies, sealed envelopes with the credentials for the most critical accounts exist. The envelopes are stored securely, and every opening is logged and followed up.

Recertification of privileged rights

Privileged rights tend to accumulate over time. An employee receives admin rights for a project, the project ends, but the rights remain. Another employee changes departments and keeps their old rights in addition to the new ones. After a few years, significantly more people have privileged access than necessary.

Recertification is the process by which all privileged rights are regularly reviewed and either confirmed or revoked. ISO 27001 requires in Annex A.5.18 a regular review of access rights, and for privileged rights this review should occur at shorter intervals than for normal rights.

A pragmatic cadence is quarterly recertification of privileged rights. The process begins with exporting all members of privileged groups from Active Directory. For each member, the following is checked: Is the employee still with the company? Do they still need the rights for their current role? Is the tier correct? The responsible manager confirms or revokes the rights.

Automation significantly eases this process. Scripts can export group memberships, highlight changes since the last recertification and document the results. In ISMS Lite, the recertification process can be mapped as a recurring task with an assigned owner, deadline and evidence, so the results are ready for the next audit.

PAM in cloud environments

Cloud environments bring their own challenges for PAM. Privileged accounts are no longer in the local Active Directory but in the cloud platform. Access rights are more fine-grained and complex, and the attack surface is larger because access is possible from anywhere.

In Azure/Entra ID, Privileged Identity Management (PIM) provides native PAM capabilities. PIM enables time-limited role activation, requires MFA and justification for activation, sends notifications to reviewers and creates audit logs of all activations. PIM is included in Entra ID P2 and should be activated for every Azure environment.

In AWS, the Identity and Access Management (IAM) service offers similar concepts. AWS Organizations and Service Control Policies limit the maximum possible rights, IAM Roles enable temporary assumption of rights (AssumeRole), and CloudTrail logs all API calls. AWS recommends securing the root account of the AWS organisation with MFA and never using it for day-to-day operations.

In Google Cloud, IAM Conditions enable time-limiting rights, and Cloud Audit Logs log all access. Google recommends using service accounts with minimal rights and avoiding service account keys in favour of Workload Identity Federation.

Regardless of the cloud platform, the same core principles apply: least privilege, separate admin accounts, MFA for all privileged access, regular recertification and complete logging.

PAM and incident response

In the event of a security incident, privileged accounts play a central role -- both as potential attack vectors and as tools for containment and recovery.

Your incident response plan should include specific procedures for the compromise of privileged accounts. If there is suspicion that a privileged account has been compromised, the first action is the immediate lockout of the account and rotation of all passwords that the account had access to. Simultaneously, the session logs and audit trails of the account must be analysed to determine the scope of the compromise.

Kerberos tickets in Active Directory present a particular challenge. Even if you change the password of a compromised account, existing Kerberos tickets can remain valid until their expiry (by default ten hours). In a severe incident, it may be necessary to double-rotate the Kerberos Ticket-Granting Ticket (krbtgt) to invalidate all existing tickets.

Break-glass procedures become particularly important in an incident response scenario. If the identity provider is compromised or normal access is unavailable, you need an alternative path to reach critical systems. Break-glass accounts must be regularly tested to ensure they work when needed.

Creating a PAM policy

A PAM policy documents the binding rules for handling privileged accounts in your company. It is a central component of your ISMS and forms the basis for audits and compliance evidence.

The policy should cover the following points: which accounts are considered privileged? How are privileged accounts requested, approved and set up? Which authentication methods are required for privileged access? How often are passwords rotated? How does recertification work and at what intervals? Which logging and monitoring requirements apply? How are break-glass accounts managed? What happens in case of a policy violation?

The policy must be approved by management and communicated to all relevant employees. It is regularly reviewed and adapted to changing requirements.

Regulatory requirements

PAM is not optional best practice but a regulatory requirement under several frameworks.

ISO 27001 addresses privileged access in Annex A.8.2 (privileged access rights): the assignment and use of privileged access rights must be restricted and managed. Annex A.5.18 (access rights) requires regular review, and Annex A.8.5 (secure authentication) demands strong authentication for privileged systems.

NIS2 requires in Article 21 access management measures that explicitly cover the handling of privileged access credentials. Companies must demonstrate that they have identified, protected and monitored privileged accounts.

The BSI IT-Grundschutz covers the topic in several modules: ORP.4 (Identity and Permission Management), SYS.1.1 (General Server) and APP.2.1 (General Directory Service). Requirements include the use of separate admin accounts, limiting the number of privileged users and logging administrative activities.

Implementation roadmap

PAM implementation is a process that should be carried out step by step. A realistic roadmap for a mid-market company looks as follows.

In the first four weeks, you inventory all privileged accounts, introduce separate admin accounts and activate LAPS for local administrators. In weeks five to eight, you implement MFA for all privileged access and set up central logging. In weeks nine to twelve, you create the PAM policy, define the recertification process and conduct the first recertification. From week 13, you evaluate whether a PAM solution is worthwhile and plan the implementation of the tiered administration model.

Each step is valuable in itself. You do not have to implement everything simultaneously, but you must start. The first step -- inventorying your privileged accounts -- costs nothing but time and yields insights that are indispensable for all subsequent measures.

Further reading

• Creating an authorisation concept: from role models to recertification
• Securing Active Directory: hardening, tiering and monitoring
• Implementing multi-factor authentication (MFA): strategy, rollout and adoption
• User lifecycle management: onboarding, role changes, offboarding
• Logging and monitoring: strategy, tools and implementation for mid-market companies