Privileged accounts are the single largest attack surface in a typical organization. This is confirmed by data from the Verizon Data Breach Investigations Report 2024 — in over 74% of documented data breaches, attackers exploited stolen credentials or excessive privileges. Yet many organizations still treat privileged access management as a topic for Linux administrators rather than a strategic security program spanning the entire organization.
Privileged Access Management (PAM) is not a product you buy and forget. It is a process — a set of policies, tools, and procedures that together control who can access critical systems, when, for what reason, and exactly what they do during that access. A good PAM program answers the question of why a domain service account has local administrator rights on 400 servers, and what to do about it — without interrupting production.
In this article I walk through all the key components of PAM step by step: from account inventory, through password vault implementation, just-in-time access, session recording, all the way to cloud access management and regulatory compliance. At the end you will find a concrete implementation roadmap and answers to the most common questions I hear from CISOs and IT teams.
What is PAM and why are privileged accounts the primary target for attackers?
Privileged Access Management is a set of technologies and processes for identifying, protecting, monitoring, and auditing accounts with elevated privileges within an organization’s IT infrastructure. Privileged accounts are those that can perform operations unavailable to regular users: install software, modify system configurations, manage other users’ accounts, access data without standard control mechanisms, or disable security mechanisms.
Attackers target these accounts for a simple reason: once a domain administrator account is compromised, it grants access to virtually the entire infrastructure. There is no need to search for additional vulnerabilities — a single stolen password is enough. The CrowdStrike Global Threat Report 2025 indicates that the time from initial access to gaining control of an Active Directory domain has shortened to an average of 62 minutes. This means that 62 minutes after a phishing attack succeeds against one of your administrators, the attacker may have full control of the environment.
The problem is compounded by so-called privilege sprawl — the gradual expansion of privileges without regular review. An employee receives local administrator rights to solve a specific problem, and a month later no one remembers to revoke them. A service account is created with domain privileges because “it was easier that way,” and it stays that way for years. Gartner research from 2024 estimates that the average organization with 1,000 employees has over 3,000 active privileged accounts — of which the owner or intended use of at least 30% is unknown.
📌 The core PAM principle: Any privileged account that is not actively managed, monitored, and regularly reviewed should be treated as potentially compromised. The question is not “whether someone will attack our privileged accounts,” but “when they will do so and how quickly we will detect it.”
A PAM program addresses this problem through a combination of four elements: centralized storage and rotation of passwords (password vault), control of the time and scope of access (just-in-time access), recording and analysis of sessions (session recording), and continuous audit and alerting. Each of these elements is discussed in detail in the following sections.
📚 Read the complete guide: IAM / Zero Trust: Zarządzanie tożsamością i dostępem - od podstaw do Zero Trust
What types of privileged accounts exist in an organization?
Before you start implementing PAM, you need to know what you are protecting. Most organizations are surprised by the scope of the inventory — the number of privileged accounts is typically 3–5 times higher than estimated before the audit.
The first category is administrative user accounts — personal accounts of IT managers, system administrators, and helpdesk specialists with elevated privileges. These are accounts tied to specific individuals, which facilitates auditing, but their security depends on the user’s password hygiene and vigilance.
The second category is shared and generic accounts — root on Linux servers, Administrator on Windows, sa in SQL Server, enable on Cisco routers. These accounts are often known to dozens of people, no one knows who last logged in, and changing the password requires coordinating the entire team. They are the most common target for attackers, because their compromise is the hardest to detect.
The third category is service accounts — accounts used by applications, scripts, and system services for communication between components. They often have static passwords (changing a service account password requires updating the application configuration), broad privileges, and are never monitored because “that is not a real user.” In reality, service accounts are responsible for a significant portion of breaches — an attacker compromises a service account with domain rights and gains unrestricted access without generating suspicious user activity.
The fourth category is emergency accounts (break-glass) — accounts created for failure scenarios when normal authentication mechanisms are unavailable. They are necessary but often have unlimited privileges and minimal control mechanisms.
The fifth category, increasingly important, is secrets embedded in code — API keys, OAuth tokens, SSH keys, certificates, and passwords in configuration files and scripts. GitGuardian research from 2024 found that for every employee in a typical organization there are an average of 13.8 secrets stored in code repositories, often in public ones.
📌 How to conduct an inventory: Start with automated discovery tools — CyberArk DNA, BeyondTrust Discovery and Audit, or Microsoft Defender for Identity. Supplement this with a review of Active Directory (Domain Admins, Schema Admins, Enterprise Admins groups), local Administrators groups on servers, service accounts in Service Control Manager and Task Scheduler, application configurations, and code repositories.
The result of the inventory is often shocking to management, but it is the only reliable foundation for planning a PAM program. Without knowing what exists, nothing can be effectively protected.
How to implement a password vault for privileged accounts?
A password vault is the central component of PAM — a secure repository that stores credentials for privileged accounts, makes them available to users on demand, and automatically rotates them after each use. Think of it as a bank vault with a teller window: you can borrow what you need, but everything is recorded and the keys return automatically.
Implementing a password vault starts with choosing a platform. Several solutions dominate the market: CyberArk Privilege Cloud and Enterprise Password Vault (market leader, greatest capabilities, highest price), Delinea Secret Server (formerly Thycotic, good capability-to-price ratio, popular in Poland), BeyondTrust Password Safe, Senhasegura, and HashiCorp Vault (particularly popular in DevOps and cloud environments). The choice depends on the organization’s scale, technology environment, and budget — each of these solutions offers core password vault functionality, with differences in integration details and advanced features.
After choosing a platform, you proceed with implementation in stages. Stage one — account onboarding. Start with the most critical accounts: Domain Admins, accounts managing network infrastructure, accounts with access to production databases. You add them to the vault, the vault takes over password management, and from that point on users do not know the password — they request access, the vault verifies permissions, and provides a session or password for a specified time.
Stage two — automatic password rotation. The vault should change account passwords after each use or at a specified interval (for accounts not used regularly, typically 24–72 hours). Rotation must be intelligent — the vault must know the dependencies between accounts (a service account used by 5 Windows services must be changed in all of them simultaneously) and handle the specifics of different platforms (Linux, Windows, databases, network devices, cloud).
Stage three — workflow integration. Access to privileged accounts should require a stated reason or even formal approval by a supervisor. A good password vault integrates with ticketing systems (ServiceNow, Jira) — the user provides a ticket number and access is automatically verified and granted only if the ticket exists and is active.
📌 The most common mistake when implementing a vault: Trying to onboard all accounts at once. Start with 20–30 accounts of the highest risk, learn the process on those before you begin scaling. Onboarding a service account without knowing its dependencies can bring down a production service in the middle of the night.
Key maturity metrics for a password vault are: the percentage of privileged accounts managed by the vault (target: 100%), time from access request to access granted (target: below 5 minutes for standard requests), the percentage of accounts with active password rotation (target: 100%), and the number of exceptions to policy (target: close to zero, with each exception documented and approved).
How to implement just-in-time access and least privilege?
Just-in-time (JIT) access is a model in which privileged accounts have no standing permissions — permissions are granted on demand, for a strictly defined period of time, and automatically revoked after that period expires. This is a fundamental change from the traditional approach, where an administrator has standing domain rights around the clock, 365 days a year, regardless of whether they are performing administrative tasks or reading email.
Least privilege goes one step further — it not only limits the duration of access but also its scope. An administrator needs rights to restart a specific service on a specific server? They receive exactly that — not local administrator rights on that server, not rights over all services, just that one restart. After the task is completed, those privileges disappear.
In practice, JIT and least privilege are implemented through several mechanisms. The first is elevation and approval workflow — the user submits an access request (to which system, what operation, for how long, why), the PAM system verifies the right to submit such a request, optionally escalates for supervisor approval, and then grants access for a defined time. After the time expires, access is revoked automatically, without any action required from the user.
The second mechanism is restricted shadow/jump accounts — instead of giving direct access to production systems, the user logs into an intermediate session (jump host, bastion host) that has precisely limited capabilities. They cannot export data, they cannot install software — they can only perform a specific administrative operation.
The third mechanism is Endpoint Privilege Management (EPM) — instead of giving users local administrator rights on workstations, you install an EPM agent (e.g., BeyondTrust Endpoint Privilege Management, CyberArk EPM), which allows running specific applications with elevated privileges without granting full administrator rights. The user can install only approved software — without contacting the helpdesk and without being a local administrator.
📌 JIT metrics: Track the percentage of administrative sessions carried out through JIT (target: 80%+ for critical systems), the average duration of requested access (warning signal: users regularly requesting the maximum time), and the number of manual access extensions (high numbers indicate that access windows are too short or processes are too complicated).
Implementing JIT requires a change in administrator work culture — this is the greatest challenge, not a technical one. Administrators accustomed to standing privileges initially experience this as a hindrance. The key to success is automating the request process (it must take seconds, not minutes), integrating with the tools they already use (IDEs, terminals, management consoles), and communicating that these restrictions protect them personally — if an account is compromised, the scope of damage is limited to what JIT permitted at that moment.
How to record and audit privileged sessions?
Privileged session recording is one of those mechanisms that simultaneously serves as a detection tool, forensic evidence, and a compliance element. Every administrative session is recorded — not just metadata (who, when, to what), but full activity: commands typed in the terminal, operations performed in the GUI, files opened and modified.
The session recording architecture in modern PAM systems is based on a proxy — the user’s session does not go directly to the target server but through the PAM proxy server, which records all traffic. From the user’s perspective the connection looks identical, but every second of the session is archived. In the event of an incident you can replay exactly what the administrator did at 3:14 a.m. on the production server.
Effective session recording requires solving several technical challenges. The first is support for different protocols — SSH, RDP, Telnet, HTTPS (for web consoles), SQL, X11. Good PAM tools handle all of them in a unified way. The second is encryption — recordings contain sensitive data (passwords typed manually, customer data displayed on screen) and must be encrypted both in transit and at rest. The third is retention — regulations often require storing recordings for 12–36 months, which at intensive usage generates significant data volumes.
Recording alone is not enough — you need tools for analysis. Modern PAM systems offer searching recordings by commands (you can search all sessions in which the command “rm -rf” or “DROP TABLE” was executed), automatic anomaly detection (a session at 3:00 a.m. from a system from which that user has never previously logged in), and SIEM integration for event correlation.
📌 The legal question of session recording: In Poland, recording employees’ screens requires informing them of this fact. Clauses regarding privileged session recording should be included in the work regulations or employment contract and formally communicated to all administrators. The absence of this communication may invalidate recordings as evidence in proceedings.
Real-time alerting is another key element. The PAM system should automatically detect and alert on suspicious patterns: an attempt to access systems outside the normal schedule, execution of dangerous commands (modification of security policies, access to password backups, export of large datasets), sessions significantly longer than usual, or sessions from unknown network locations. Response time to such an alert should be short — hence integration with SOC systems and incident response procedures is essential.
Regular review of recordings — not only reactively after incidents, but proactively as part of audits — helps catch problematic practices before they become incidents. An administrator who regularly bypasses security policies “because it is faster,” or who has access to systems unrelated to their duties, will appear in recordings before they cause actual damage.
How to manage privileged access in cloud environments (CIEM)?
The cloud created a new class of privileged permissions that did not exist in the on-premises world. In AWS, Azure, and GCP every resource has assigned IAM policies, every service has a service role, every CI/CD pipeline has access keys. Managing this at scale is fundamentally more difficult than managing Active Directory — roles and permissions are thousands of times more granular, change dynamically, and form complex dependency chains.
Cloud Infrastructure Entitlement Management (CIEM) is a category of tools created specifically to address this problem. CIEM monitors and analyzes permissions in cloud environments, identifies excessive privileges (e.g., an IAM role with access to all S3 resources when it actually only needs read access to one specific bucket), and helps reduce them to the minimum necessary scope.
In practice, CIEM integrates with the APIs of managed cloud platforms and creates a complete graph of relationships between identities, permissions, and resources. You can see that a Lambda function has access to a production database through a chain of three roles, even though it should not — and exactly how that permission was granted. Popular CIEM tools include Wiz CIEM, Orca Security, and Microsoft Entra Permissions Management.
Key practices for managing privileged access in the cloud are: eliminating static access keys in favor of roles and temporary tokens, enforcing MFA for management console operations, applying the least privilege principle to IAM roles (the IAM Access Analyzer tool in AWS or Azure Policy helps identify excessive permissions), separate accounts/subscriptions for production environments with restricted developer rights, and enforcing approval before operations in production environments.
📌 Typical cloud permission problems: Tenable research from 2024 found that 84% of organizations have cloud identities with “Administrator” or equivalent permissions, while only a fraction actually need them. 72% of organizations have access keys that have not been used for more than 90 days but have not been deactivated. This is classic privilege sprawl migrated to the cloud.
Hybrid environments (on-premises + cloud) are the most difficult to manage. A domain administrator in Active Directory may also have an Owner role in an Azure subscription through synchronization via Azure AD Connect — and this doubled privilege often escapes standard reviews. Good PAM tools handle hybrid environments as a single unified management space, not two separate silos.
Pay particular attention to permissions in CI/CD pipelines. GitHub Actions, GitLab CI, Azure DevOps — all need privileges for deployment to production environments. These tokens and secrets are often stored in repositories or environment variables without adequate controls. The solution is integrating CI/CD pipelines with the PAM system — instead of static secrets, the pipeline retrieves temporary credentials from the password vault for the duration of each run.
What regulations (NIS2, PCI DSS, ISO 27001) require PAM controls?
Privileged access control appears as a specific requirement in every significant security regulation and standard. Knowing these requirements is important not only for compliance — it also helps justify the PAM investment to management and secure a budget.
The NIS2 Directive (implemented in Poland through the amendment of the Cybersecurity Act) requires essential and important entities to apply “appropriate technical measures” in the area of access management. Article 21 of the directive lists, among other things, management of access to networks and systems and control of privileged accounts as elements that must be addressed in security policies. Supervisory authorities (CERT Polska, UODO, sector-specific regulatory authorities) have the right to audit access management practices and impose penalties for their absence.
PCI DSS v4.0 (mandatory since March 2024) is very specific regarding privileged accounts. Requirement 7 (Restrict Access to System Components and Cardholder Data by Business Need to Know) and Requirement 8 (Identify Users and Authenticate Access to System Components) together create detailed requirements: unique identifiers for every administrator, strong password cryptography, MFA for all access to the cardholder data environment, prohibition of account sharing, regular reviews of privileged accounts and their permissions, deactivation of inactive accounts after 90 days. Privileged session recording, while not explicitly required, is recognized by QSA auditors as a best practice confirming compliance with requirements 7 and 8.
ISO/IEC 27001:2022 addresses privileged access management in control A.8.2 (Privileged Access Rights). The control requires: a formal process for granting and revoking privileged permissions, regular reviews of granted permissions, a policy restricting the use of privileged accounts to cases where it is necessary, and logging of privileged user activity. Organizations that are certified or pursuing ISO 27001 certification must demonstrate evidence of implementing this control.
📌 SOC 2 and PAM: If your organization is undergoing a SOC 2 audit (particularly relevant for SaaS companies operating in English-speaking markets), controls CC6.1, CC6.2, and CC6.3 relating to access management are assessed. SOC 2 auditors increasingly ask about specific PAM mechanisms, not just the existence of an access management policy.
GDPR itself does not mention PAM by name, but the requirement for “appropriate technical and organizational measures” to protect personal data (Article 32) is interpreted by supervisory authorities as requiring privileged access controls for systems processing personal data. UODO guidelines indicate that the absence of records of persons with access to personal data and the absence of mechanisms for controlling that access constitutes a violation of Article 32.
A practical tip for CISOs: prepare a matrix mapping PAM mechanisms to the regulatory requirements that apply to your organization. Most mature PAM solutions deliver ready-made compliance reports for PCI DSS, ISO 27001, and NIS2 — make sure you configure and regularly review them.
How to protect service accounts and API keys?
Service accounts and API keys are the “dark matter” of privileged access management. They are everywhere, have broad permissions, never generate helpdesk tickets or security requests, and are often completely undocumented. For years they fell outside the scope of most security programs — because “that is not a real user.”
Managing service accounts begins with discovering them. Automated discovery tools will find service accounts in Active Directory (accounts with “Password never expires” set, accounts in the Service Accounts group or similar), Windows services (Service Control Manager), scheduled tasks (Task Scheduler), application configuration files, and databases (stored procedures using specific accounts). After discovery, every service account should have documentation: what application it serves, who is the owner, what permissions are needed and why, and when it was last reviewed.
The next step is limiting service account permissions to the minimum. A web application’s service account needs access to its own database — not to all databases, not to Active Directory, not to file systems outside its own directory. In Windows, the environment for managing these permissions is Managed Service Accounts (MSA) and Group Managed Service Accounts (gMSA) — they automatically manage service account passwords without the need for manual rotation. On Linux, service accounts should have interactive login disabled (shell /usr/sbin/nologin) and operate in isolated environments.
API keys, OAuth tokens, SSH keys, and other machine credentials require a separate approach. The main problem is their storage — they end up in environment variables.env files, scripts, code repositories, and “temporary” text documents, from which they are never removed. The solution is centralized secrets management through a dedicated system: HashiCorp Vault (most popular in DevOps), AWS Secrets Manager, Azure Key Vault, or the native capabilities of PAM platforms.
📌 Secrets leaking into repositories: Tools such as GitGuardian, Trufflehog, or GitHub Advanced Security Secret Scanning automatically scan code repositories for secrets. If you are not yet using any of them, start now — GitGuardian research from 2024 found that 1 in 10 commits in corporate repositories contains at least one secret.
Rotating API keys and tokens is more difficult than rotating user passwords, because it requires updating the configuration in every place where the key is used. That is why the secrets storage architecture should assume that applications never “know” the current key — instead, they retrieve it from the secrets management system at startup. Changing the key is then transparent to the application and requires neither a deployment nor a configuration change.
Service accounts and API keys should also be subject to regular reviews: is the account/key still in use? By what? Are the permissions appropriate for current needs? Accounts unused for 90 days should be deactivated — with no exceptions.
What does the PAM implementation roadmap look like?
PAM implementation is a multi-year program, not a project with a completion date. Below I present a practical roadmap divided into stages, with specific objectives and metrics for each.
| Stage | Timeline | Objective | Key Actions | Success Metrics |
|---|---|---|---|---|
| Foundation | 0–3 months | Visibility and control over critical accounts | Inventory of privileged accounts; selection and deployment of PAM platform; onboarding of Domain Admin and network infrastructure accounts into the vault; activation of automatic password rotation | 100% of DA accounts in the vault; password rotation active; 0 shared passwords to critical systems |
| Expansion | 3–9 months | Broadened scope and first JIT | Onboarding of service accounts into the vault; deployment of session recording for critical systems; initial JIT implementation for selected administrator groups; SIEM integration | 70% of privileged accounts in the vault; session recording active for all Tier 1 systems; JIT for at least 1 admin group |
| Maturity | 9–18 months | Full control and automation | JIT for all administrators; Endpoint Privilege Management on workstations; API key and secrets management; CIEM for cloud environments; automatic compliance reports | 90%+ admin sessions through JIT; EPM on 100% of workstations; CIEM active; 0 static API keys outside secrets management system |
| Optimization | 18+ months | Continuous improvement and Zero Trust | PAM integration with Zero Trust Network Access; behavioral anomaly analysis; automatic discovery and onboarding of new accounts; mature permission review processes; full regulatory coverage | Time to anomaly detection < 5 min; automatic onboarding of new privileged accounts; PAM maturity score > 80% |
The success of a PAM program depends on several organizational factors that are more important than the choice of technology. The first is executive sponsorship — without a clear mandate from the top, every change will meet resistance from administrators and system owners. The second is cross-functional engagement — a PAM program touches IT, security, HR (employee changes), and legal (regulations), and requires representatives from all of these areas. The third is change management — administrators must understand that PAM protects them personally, not just the organization.
📌 Typical implementation pitfalls: Trying to do everything at once (this will end in chaos and resistance), failing to test service account onboarding in a non-production environment before production (service outages are the most common reason a PAM program is rolled back), and the absence of a success metric — without KPIs you do not know whether the program is working.
The PAM implementation budget includes software licenses (typically 100–400 USD per protected account per year for enterprise solutions), infrastructure (servers or SaaS subscription), implementation services (50–200 consulting days depending on scale), and internal costs (time administrators spend on onboarding and maintenance). ROI is measurable — every security incident resulting from privilege abuse costs an organization an average of 4.45 million USD (IBM Cost of a Data Breach Report 2024). The cost of implementing PAM is typically a fraction of that amount.
How does nFlo help organizations implement privileged access control?
nFlo has for years specialized in designing and implementing PAM programs for organizations in the financial, energy, industrial, and public sectors. Across a portfolio of over 500 projects delivered to more than 200 clients, privileged access management consistently emerges as one of the most important elements of mature security strategies.
nFlo’s approach to PAM starts with an assessment of the current state, not with selling a specific product. We conduct a detailed audit of privileged accounts — discovery in Active Directory, analysis of system configurations, inventory of service accounts, review of API keys and secrets in code repositories. The result is a complete picture of the attack surface: how many privileged accounts exist, how many have unknown owners, how many passwords have not been changed in over a year, and where the biggest regulatory gaps are.
Based on the audit, we design a target architecture tailored to the client’s technology environment and regulatory requirements. If the organization operates in a mixed on-premises and cloud environment, we design a unified management platform covering both environments. If the primary requirement is PCI DSS compliance, we focus on mechanisms that directly address audit requirements. There is no single correct approach — there is the optimal approach for a specific client.
Implementation is carried out in phases, starting with the elements of highest risk and fastest return on investment. We work with CyberArk, Delinea, BeyondTrust, and HashiCorp Vault platforms — depending on the client’s needs, we recommend the best-matched solution, not the one that happens to be in our partner portfolio. Our experience also covers specific environments: OT/SCADA (where PAM requires particular care — downtime in industry is not the same as downtime of a web server), cloud environments on AWS, Azure, and GCP, and hybrid multi-cloud environments.
98% of our clients continue the relationship after the implementation project is complete — because PAM is not a project that ends. It is a program that requires continuous adaptation to a changing infrastructure, new threats, and evolving regulations. We offer operational support, regular PAM program maturity reviews, and updates in response to new regulatory requirements (which is particularly relevant in the context of the NIS2 directive being implemented in Poland).
Response time for operational requests related to PAM — for example, unavailability of the password vault or a problem with account onboarding — is set per request priority and written into the contract. We know that access problems with critical systems cannot wait. That is why the nFlo team is available around the clock, 365 days a year.
Related concepts
Explore key terms related to this article in our cybersecurity glossary:
- Privileged Access Management — PAM is a set of strategies and technologies for managing, monitoring, and auditing access by privileged accounts.
- Access Management — Access management is the process of controlling access to IT resources through identity and permissions policies.
- Identity Management — IAM refers to the processes and technologies that define and manage user roles and access rights.
- Zero Trust — A security model assuming that no user or system is trusted by default — every access requires verification.
- Cybersecurity — Cybersecurity is the set of techniques, processes, and practices for protecting IT systems from attacks and unauthorized access.
Learn more
Explore related articles in our knowledge base:
- What is PAM (Privileged Access Management) and how does it work?
- Comprehensive PAM solution — Delinea Secret Server (formerly Thycotic)
- Identity and Access Management (IAM) — from basics to Zero Trust
- Why granular Identity and Access Management (IAM) is the foundation of security in AWS?
- How to conduct a KSC NIS2 readiness audit?
Check our services
Do you need support in the area of privileged access management? See:
- Security audits — comprehensive assessment of security posture, including privileged account inventory
- PAM implementations — design and implementation of a PAM program tailored to your environment
- SOC as a Service — round-the-clock security monitoring with alerting for privileged sessions
FAQ — Frequently asked questions about PAM
Do small organizations also need PAM?
Yes, though the scope of implementation will be smaller. Privileged accounts are a threat regardless of organization size — attackers do not bypass small companies. For small and medium-sized businesses the solution is typically a simplified SaaS PAM platform (e.g., Delinea Cloud or BeyondTrust Cloud), which provides basic password vault and session recording capabilities without the need to maintain your own infrastructure. The entry cost for an organization with 20–50 privileged accounts is a few hundred dollars per month — significantly less than the cost of even a single security incident.
How long does PAM implementation take?
The first visible results — a password vault containing critical accounts and active password rotation — can be achieved within 4–8 weeks of the decision to implement. Full implementation covering JIT, session recording, EPM, and CIEM takes 12–24 months depending on the organization’s scale and the complexity of the environment. The key is adopting a phased approach — do not try to do everything at once.
Does PAM replace VPN and other remote access tools?
It does not replace them, but it complements them and in many scenarios reduces the dependence on VPN. PAM with a jump host or bastion access function can serve as an access point to internal systems without requiring full VPN access to the network. This approach is closer to the Zero Trust model than traditional VPN — instead of “letting someone into the network,” you grant access to a specific system for a specific period of time. In mature organizations, PAM and ZTNA (Zero Trust Network Access) are deployed together as complementary elements of the security architecture.
What happens if the PAM system goes down? Will we lose access to critical systems?
This is one of the first questions that comes up when planning a PAM implementation — and rightly so. A good PAM implementation anticipates failure scenarios at several levels. First, PAM platforms are deployed in high availability (HA) — no single point of failure. Second, every PAM platform has an emergency access mechanism (break-glass): special procedures enabling access to critical passwords in the event of complete system unavailability, with a requirement to document the use and immediately notify the security team. Third, a PAM system failure does not change passwords on target systems — existing passwords remain valid; only their management is temporarily unavailable.
How does PAM integrate with Active Directory and Azure AD (Entra ID)?
PAM integrates deeply with Active Directory and Entra ID. At the basic level it synchronizes the list of accounts and groups to know what to manage. At the advanced level it can dynamically add accounts to privileged groups for the duration of a JIT session and remove them after it ends — this is the “on-demand privilege elevation” mechanism available in most PAM platforms. In the case of Entra ID, the integration also includes management of Privileged Identity Management (PIM) roles, which is Microsoft’s native implementation of JIT for Azure environments. Many organizations implement Entra ID PIM as a first step toward JIT before moving to a full PAM platform.
Sources and references
- Verizon, Data Breach Investigations Report 2024, verizon.com/business/resources/reports/dbir
- CrowdStrike, Global Threat Report 2025, crowdstrike.com/global-threat-report
- IBM Security, Cost of a Data Breach Report 2024, ibm.com/security/data-breach
- Gartner, Market Guide for Privileged Access Management, 2024
- GitGuardian, State of Secrets Sprawl 2024, gitguardian.com/state-of-secrets-sprawl
- Tenable, Cloud Security Report 2024, tenable.com/cloud-security
- NIST SP 800-53 Rev. 5, Control AC-6 (Least Privilege) and AU-14 (Session Audit)
- NIS2 Directive (EU) 2022/2555, Article 21 — cybersecurity risk management measures
- PCI Security Standards Council, PCI DSS v4.0, pcisecuritystandards.org
- ISO/IEC 27001:2022, Control A.8.2 — Privileged Access Rights
Explore Our Products
Solutions mentioned in this article that can help protect your organization:
- Delinea Secret Server — Delinea
