# How Is a PAM Architecture Built? Vault, Session Management, JIT Access and Zero Standing Privilege

**URL:** https://securesys.com.tr/en/learning/identity-and-access-management/pam-architecture-vault-and-jit-access

![How Is a PAM Architecture Built? Vault, Session Management, JIT Access and Zero Standing Privilege](/images/bilgi-merkezi/covers/cover-pamiam-04.webp)

One of the most frequently made mistakes in a Privileged Access Management project is thinking that installing the PAM product is the same thing as creating a PAM architecture. Yet a corporate PAM structure does not consist only of a central Password Vault in which administrator passwords are stored. A real PAM architecture requires many security layers to work together such as identity verification, authority management, privileged credential security, session control, approval processes, Just-in-Time Access, service account management, monitoring, SIEM integration, high availability and disaster recovery.

Especially in large organizations privileged access does not take place on a single technology. A Windows administrator can carry out operations on Active Directory, a Linux administrator can connect to a server with SSH, a database administrator can use high authority on Oracle or PostgreSQL, a network administrator can change the firewall and switch configuration, and a cloud administrator can manage critical IAM permissions on Azure, AWS or Google Cloud. Alongside these there are the service accounts, API keys, secrets and automation identities used by applications.

For this reason the fundamental aim of a modern PAM architecture is not only to answer the question:

**"Where will we store the administrator passwords?"**

this question.

The essential question is this:

**"How will we discover, verify, limit, make temporary, monitor and where necessary terminate instantly all the privileged access inside the organization?"**

A successful PAM architecture should be able to answer this question end to end.

### How Does a Corporate PAM Architecture Work?

In a simplified traditional privileged access model the administrator connects directly to the target system:

**Administrator → Critical Server**

In this model the administrator knows the password of the target system. The credential can be used on the endpoint, credential artifacts can arise on the administrator's workstation and there can be direct network connectivity to the target system. If the same credential is known by more than one administrator an accountability problem also emerges.

The modern PAM architecture aims to change this direct relationship.

A more controlled model:

**Administrator → Identity Verification → MFA → PAM → Approval/JIT → Session Proxy → Target System**

can work in this way.

The administrator first carries out authentication with their own personal corporate identity. The PAM platform verifies the user's identity, if necessary applies phishing-resistant MFA and determines which privileged resource they want to access. The access policy or approval workflow is evaluated. If seen as appropriate PAM can use the privileged credential necessary for the target system without showing it to the user or can create a temporary privilege.

The session is passed over the PAM infrastructure and the necessary security policies are applied.

In this way privileged access is centrally taken into the lifecycle:

**Authenticate → Authorize → Elevate → Connect → Monitor → Revoke**

this lifecycle.

This is the foundation of a modern PAM architecture.

### Privileged Access Discovery Must Be Carried Out Before a PAM Architecture Is Built

Before the technical deployment stage of a PAM project the organization's privileged access landscape must be understood. Because an unknown administrator account, service account or privileged application identity cannot be protected by PAM.

Discovery is not only looking at the Domain Admin group inside Active Directory. Across the organization Windows local administrators, Linux root and sudo accounts, database administrator accounts, network device administrators, firewall administrators, virtualization administrators, backup administrators, application administrators, cloud privileged roles and service accounts must be examined.

Especially inside legacy systems there can be privileged accounts that have been used for years and whose owner is no longer known. Some accounts may not be actively tracked by anyone because they are used only by particular scheduled tasks or applications.

**For this reason a Privileged Identity Inventory should be created before PAM.**

For every identity at least:

account owner,

target system,

privilege level,

business purpose,

authentication method,

the credential rotation state,

interactive login authority,

criticality

information such as this must be determined.

As a result of this work PAM onboarding priorities can be created.

Instead of taking everything into PAM at the same time, starting with the highest-risk identities first generally provides a more controlled approach.

### How Is Risk-Based PAM Onboarding Carried Out?

If during a PAM implementation hundreds or thousands of privileged accounts are attempted to be onboarded at the same time operational problems can be experienced. Especially service accounts and legacy applications can stop working after credential rotation.

For this reason risk-based onboarding can be applied.

In the first wave:

Domain Admin,

Enterprise Admin,

Cloud Global Administrator,

Backup Administrator,

Security Administrator

identities that can create a high impact such as these can be taken.

At the second stage:

Database Administrators,

Network Administrators,

Virtualization Administrators,

Application Administrators

can be included in the scope.

In the following stages:

Service Accounts,

Local Administrators,

DevOps Secrets,

Machine Identities

and other privileged credentials can be added to the programme.

**This model turns a PAM project into a continuously expanding Privileged Access Security Program instead of a one-off deployment.**

### The Credential Vault Is One of the Fundamental Layers of a PAM Architecture

The Credential Vault is the component in which privileged credentials are stored centrally and safely. However, the aim of the Vault is not only to keep passwords inside an encrypted database.

In the ideal model the administrator does not know the target system password directly.

For example when a database administrator wants to connect to the production database they log in to the PAM platform with their own personal identity. After PAM applies the necessary policy controls it takes the target database credential from the Vault and creates the session on behalf of the user.

The administrator can access the system without seeing the credential.

This approach reduces the:

#### Credential Disclosure

this risk.

Because if the password is not known by the administrator the need for it to be kept in a notebook, password manager, text file, ticket or e-mail also decreases.

For this reason one of the important principles in modern PAM:

**Know the identity, not the privileged password.**

can be thought of in this way.

The organization must know who is accessing; but it may not be necessary for the user to know the privileged password.

#### The Difference Between Password Checkout and a Passwordless Privileged Session

**Some PAM implementations can show the user the password inside the Vault for a particular period. This is the Password Checkout model.**

For example the administrator checks out the password for 30 minutes, carries out their operation and at the end of the period the password is rotated.

This traditional model can still be necessary for some systems.

However, where possible the stronger approach is never to show the password to the user.

PAM can create the session itself.

In this case:

**User → PAM → Target**

this model is applied.

The password can still exist for the target system but is not known by the administrator.

This approach can significantly reduce the credential theft risk.

### How Does Automated Password Rotation Work?

When privileged credentials stay the same for a long time the period for which the attacker can use the credential in the case of a compromise increases.

For this reason PAM platforms can rotate privileged passwords automatically.

Rotation can be applied with different policies:

periodic,

after every use,

after a risk event,

on an administrator change,

after an incident.

For example the root password can be changed automatically after it is used over PAM.

In this way the administrator cannot use the password they saw earlier again.

However, password rotation must be designed carefully especially for service accounts. If an application connects to a database with a particular password PAM changing the password can break the application connection.

For this reason service account rotation must be dependency-aware.

PAM should first change the credential on the target system and afterwards update safely the configuration of the application or service that uses this credential.

### Why Is Privileged Session Management Critical in a PAM Architecture?

The Credential Vault protects the privileged password.

However, after the correct administrator connects to the system with the correct credential they can carry out a wrong or risky operation.

For this reason privileged access security does not end only with credential security.

**Privileged Session Management – PSM enables the session between the administrator and the target system to be controlled by PAM.**

For example an RDP connection:

**Administrator → PAM RDP Proxy → Windows Server**

or an SSH connection:

**Administrator → PAM SSH Proxy → Linux Server**

can be established in this way.

The administrator's workstation may not have to access the target system directly.

This architecture can at the same time provide an advantage in terms of network segmentation.

Target systems can permit only administrative connections coming from the PAM Session Gateway.

In this way it can be made harder for a compromised workstation to establish a direct RDP or SSH connection to a critical server.

#### Why Should Direct Administrative Access Be Closed?

If despite PAM having been installed administrators can connect directly to target systems the PAM controls can easily be bypassed.

For example if the user:

instead of connecting over PAM can directly use:

mstsc → server

or:

ssh root@server

Session Recording, the approval workflow and PAM auditing are put out of service.

For this reason network-level enforcement is important inside a mature PAM architecture.

A firewall or network ACL:

**Administrator VLAN → Critical Server RDP/SSH = Deny**

**PAM Gateway → Critical Server RDP/SSH = Allow**

can be designed in this way.

In this case privileged access technically has to pass over PAM.

**PAM in this way becomes not only a policy but an enforced security control.**

### Session Recording and Privileged Activity Monitoring

Privileged sessions passing over the PAM Session Proxy can be recorded.

Windows RDP sessions can be monitored in the form of a visual recording, and Linux SSH sessions in the form of command-level or terminal activity.

This is especially valuable in terms of:

incident investigation,

forensic analysis,

audit,

accountability

these.

However, the recordings only being created is not sufficient.

There can be thousands of hours of administrator session recordings and the security team cannot watch these manually.

For this reason the modern PAM approach is merging with privileged session analytics.

For example:

an unusual command,

unexpected system access,

a suspicious file transfer,

a privilege escalation attempt

activities such as these can create a risk signal.

These signals can be sent to the SIEM or SOC.

In this way PAM becomes not only a recording platform but a security sensor that provides identity threat visibility.

### How Does Just-in-Time Access Change the PAM Architecture?

In traditional PAM the user's administrator account can be continuously present but the password is protected by the Vault.

The JIT approach goes further.

The user's privileged permission is not kept continuously active.

For example if the administrator is going to carry out an operation on the production environment they create an access request.

The policy engine:

user identity,

target resource,

requested privilege,

time,

device,

risk level

can evaluate context such as this.

If approval is necessary the relevant manager or resource owner gives approval.

Afterwards the privilege is activated for example for 60 minutes.

When the period is completed the permission is removed automatically.

This model:

#### Standing Admin

instead of this:

#### Eligible / Temporary Admin

creates this approach.

When the attacker compromises a user account, because there is no continuous administrator privilege on it the attack impact can decrease.

### Reducing the Authority Level with Just-Enough-Access

JIT limits the duration of the access.

However, if the user temporarily becomes a full administrator more privilege than necessary may still have been given.

For this reason JEA – Just-Enough-Access can be applied.

For example if the administrator's need is only:

a service restart

it may not be necessary to give them full root access.

Privilege can be provided for a particular command or administrative task.

This model:

#### Maximum Access

instead of this:

#### Task-Based Access

is this approach.

When JIT and JEA are applied together:

#### Minimum Time + Minimum Privilege

is obtained.

This is one of the strongest applications of the Least Privilege principle in a privileged access environment.

### Zero Standing Privilege Can Be the Target of Modern PAM

Zero Standing Privilege, that is, ZSP, aims to remove permanent authorities on privileged access as far as possible.

The traditional model:

**User = Permanent Administrator**

The modern model:

**User = Standard Identity**

↓

Need Privilege

↓

Policy Evaluation

↓

Temporary Privilege

↓

Perform Task

↓

Privilege Removed

This approach can seriously narrow the attacker's opportunity window.

Instead of an account being an administrator 24 hours a day it can be an administrator for only 30 minutes.

Even mathematically the privilege exposure period decreases significantly.

However, Zero Standing Privilege cannot be applied with the same ease for every system.

Legacy systems, network devices or some applications can require permanent privileged accounts.

For this reason ZSP should for most organizations be evaluated not as a binary target to be applied at one go but as a maturity direction to be increased over time.

### The Relationship Between PAM, PIM and JIT

PAM is the broader privileged access security architecture.

PIM – Privileged Identity Management, on the other hand, is related especially to the lifecycle, eligibility and activation processes of privileged roles and identities.

For example a cloud administrator may not be a Global Administrator continuously.

**The user can be eligible for the role.**

At the moment of need the role is activated.

During activation:

MFA,

justification,

approval,

limited duration

can be applied.

Microsoft Entra Privileged Identity Management is one of the examples of this approach on the cloud identity side.

However, the scope of enterprise PAM is broader.

PAM:

Password Vault,

Credential Rotation,

RDP/SSH Session Proxy,

Session Recording,

Service Account Management,

Endpoint Privilege Management,

Secrets Management

can also cover use cases such as these.

For this reason:

#### PIM ⊂ Privileged Identity Security

thinking of it in this way can be more explanatory for many architectures.

### How Is Endpoint Privilege Management Included in a PAM Architecture?

Privileged access does not take place only on servers and cloud consoles.

Local administrator rights on employee endpoints can also create a serious risk.

If a user is a local administrator a malicious application can try:

to change the security tools,

to carry out operations on the system configuration,

to install additional software

these.

**For this reason modern PAM programs can also contain the Endpoint Privilege Management – EPM/PEDM layer.**

The user is taken out of being a local administrator.

When a particular application or process is necessary it is run with elevated privilege.

For example:

User = Standard

Application A = Allow Elevation

Unknown Installer = Block

PowerShell = Policy Controlled

This approach can help to reduce the ransomware and endpoint privilege abuse risk.

### How Should the Active Directory PAM Architecture Be Designed?

Active Directory is one of the most critical systems in terms of privileged access.

Domain Admin, Enterprise Admin and similar accounts can be evaluated as Tier 0 identities.

These accounts should not be used for daily use.

An administrator should not use a Domain Admin identity to read e-mail or access the internet.

In a safer architecture:

Normal User Account

and

Privileged Administrative Identity

are separated.

Privileged access is provided over PAM.

An administrative workstation or PAW can be used.

Network segmentation can limit privileged management traffic.

PAM sessions can be sent to the SIEM.

In this way the exposure risk of the Domain Admin credential on a normal endpoint is reduced.

### Database PAM Integration

Database administrator accounts can carry an extremely high risk.

Privileged accounts on Oracle, PostgreSQL, Microsoft SQL Server or other database platforms:

can change the schema,

can read data,

can create users,

can change audit settings.

For this reason database privileged access must be taken into the scope of PAM.

The administrator can establish a connection over PAM without knowing the database password.

A session audit can be applied.

In addition on the database side PAM logs can be correlated with Database Activity Monitoring – DAM.

For example:

PAM:

#### Who connected?

DAM:

#### Which query was run on the database?

can answer this question.

These two telemetries together provide strong accountability.

### Firewall, Switch and Network Device PAM Integration

Network infrastructure administrator credentials are also within the scope of privileged identity.

Systems such as firewalls, routers, switches, wireless controllers and load balancers being compromised can give the attacker great control over the network architecture.

For this reason for network devices:

centralized privileged access,

password rotation,

SSH session management,

command auditing

can be applied.

Especially instead of shared:

admin

accounts, the use of the personal identity → PAM → device model is important in terms of accountability.

### Should Backup Systems Be Taken into the Scope of PAM?

It should definitely be evaluated.

For ransomware attackers the backup infrastructure is an important target.

Before encrypting the production systems the attacker can try to carry out operations on the backup repositories or the backup management console.

For this reason Backup Administrator credentials must be separated from normal Domain Admin credentials.

For the backup infrastructure:

dedicated privileged identities,

MFA,

PAM,

network segmentation,

immutable backup

controls such as these must be used together.

PAM here becomes an important part of the cyber resilience architecture.

### Cloud PAM Architecture

Cloud environments have significantly changed the privileged access model.

Inside environments such as AWS, Azure and Google Cloud administrator access is not managed only with passwords.

Roles, policies, service principals, temporary credentials and workload identities can be used.

For this reason a cloud PAM architecture:

#### Credential Vault

rather than being centred on this:

**Identity + Entitlement + Temporary Privilege**

becomes centred on this.

For example instead of carrying a permanent Owner role a cloud administrator can use temporary role activation at the moment of need.

This is the JIT and Zero Standing Privilege approach.

Cloud PAM can in addition be used together with CIEM to detect excessive permissions.

### DevOps and PAM Integration

DevOps environments create an important challenge for traditional PAM.

A CI/CD pipeline can carry out a production deployment.

An automation script can run a database migration.

An Infrastructure-as-Code platform can create cloud resources.

These processes are not interactive human administrators but they carry out privileged operations.

Therefore DevOps identities must also be taken into the PAM or Secrets Management scope.

Instead of keeping a static administrator password inside the pipeline:

a Secrets Vault,

Workload Identity,

a Short-Lived Token,

a Dynamic Credential

can be used.

This is the point at which DevSecOps and PAM intersect.

### Dynamic Secrets and Short-Lived Credentials

A traditional credential:

**username + password → can be valid for months**

can be this.

A modern secrets architecture, on the other hand, can create the credential at the moment of need.

For example when the application is going to connect to the database the Vault produces a temporary credential.

The credential:

15 minutes,

30 minutes,

1 hour

can be valid for these.

Afterwards it expires automatically.

**This is the Dynamic Secrets approach.**

Even if the attacker obtains the credential the usable lifetime is limited.

For this reason one of the important aspects of a modern PAM and Secrets Management architecture is:

**Static Privilege → Ephemeral Privilege**

this transformation.

### Non-Human Identity and PAM

In modern organizations privileged access is not used only by humans.

Service Accounts,

Applications,

APIs,

Automation Bots,

CI/CD Pipelines,

Cloud Workloads,

AI Agents

can carry out privileged operations.

**These identities are evaluated as Non-Human Identities – NHI.**

As cloud and automation increase the number of NHIs can go far above human identities.

For this reason a PAM architecture can no longer be built only on administrator passwords.

A modern architecture:

#### Human Privileged Identity

and

#### Machine Privileged Identity

must manage these together.

### How Should the AI Agent PAM Architecture Be?

Agentic AI adoption creates a new architecture requirement in terms of privileged access.

If an AI Agent is permitted to carry out autonomous action on the infrastructure the agent must be given an identity.

However, giving the agent a static root password conflicts with modern security principles.

The safer model:

#### AI Agent Identity

↓

#### Requested Action

↓

#### Policy Engine

↓

#### Human Approval / Automated Risk Decision

↓

#### Short-Lived Privilege

↓

#### Action

↓

#### Audit

↓

#### Privilege Revocation

can be in this way.

For example an AI-based SOC Agent detected a compromised endpoint.

The agent wants to carry out a network isolation action.

Instead of the agent being a permanent administrator on the whole EDR platform only the:

**isolate_endpoint**

permission can be given temporarily.

**This is one of the important areas that can develop as Agentic Privilege Management in the PAM architecture of the future.**

### PAM and SIEM/SOC Integration

A PAM architecture should not be considered complete without monitoring.

PAM events can be sent to the SIEM.

Especially:

Failed Privileged Authentication

New Vault Account

Password Checkout

JIT Activation

Privilege Elevation

Break-Glass Access

Suspicious Session

Blocked Command

events such as these carry high value for the SOC.

However, only collecting the PAM logs is not sufficient.

Correlation rules must be created.

For example:

#### EDR Malware Alert

#### Same User PAM Login

#### JIT Domain Admin Request

if these are seen within the same time interval a critical incident can be created.

This Identity + Endpoint + Privilege correlation is one of the strong use cases of a modern SOC architecture.

### How Do ITDR and PAM Work Together?

While ITDR focuses on detecting identity attacks PAM enforces privileged access.

For example ITDR detected that the user carries an account takeover risk.

PAM can automatically block this identity's privileged requests or can request additional approval.

In this case:

**Detect Risk → Adjust Privilege**

this model arises.

In the Identity Security architecture of the future PAM policies can stop being static and become dynamic according to real-time risk signals.

### How Should the PAM System Itself Be Protected?

This is one of the most critical subjects of a PAM architecture.

Because the PAM platform can manage the organization's most valuable privileged credentials and administrative access paths.

**For this reason PAM itself must be evaluated as Tier 0 / Critical Security Infrastructure.**

PAM administrator accounts should not be the same as ordinary administrator accounts.

For the PAM infrastructure:

Network Segmentation

Strong MFA

Dedicated Administration

Least Privilege

Hardened Operating Systems

Restricted Internet Access

EDR

SIEM Monitoring

Secure Backup

High Availability

Disaster Recovery

must be applied.

The PAM database and Vault backups must also be protected with high security.

Because if the attacker compromises the PAM infrastructure they can obtain a central advantage for reaching a large number of privileged systems.

For this reason PAM:

#### Security Tool

as much as it is this:

#### High-Value Target

should also be thought of as this.

### Why Is PAM High Availability Important?

When PAM becomes the central point of all administrative access a platform outage can affect operations.

For example a production server has failed but the PAM platform is inaccessible.

The administrator cannot connect to the critical system.

For this reason an enterprise PAM architecture requires High Availability.

Components can work with redundancy.

Failover can be designed for the Vault, Session Gateway and application components.

The aim is to prevent PAM becoming a Single Point of Failure.

### How Should PAM Disaster Recovery Be Planned?

High Availability can provide protection against failures inside the same datacenter.

However, in the case of a site-level disaster a separate DR architecture can be necessary.

In a PAM Disaster Recovery plan:

Vault replication,

configuration backup,

credential consistency,

encryption keys,

recovery procedures,

DNS/network dependencies

must be taken into account.

The most important subject, on the other hand, is that the DR plan does not exist only in a document.

Periodic PAM DR tests must be carried out.

Because during a real incident the situation:

**"PAM is not working, we do not know the administrator passwords."**

can turn into a critical operational problem.

### Emergency Access and Break-Glass Architecture

When PAM is completely inaccessible an emergency access mechanism can be necessary for critical systems.

For this purpose Break-Glass accounts can be used.

However, because Break-Glass bypasses PAM it carries a high risk.

The credential can be protected with methods such as:

offline secure storage,

physical security,

dual control

these.

After use:

an alert,

an incident review,

credential rotation

must be applied.

Break-Glass access must not become a normal operational shortcut.

### How Should PAM Network Segmentation Be Carried Out?

The PAM infrastructure can be positioned inside a critical network zone.

User networks should not access target servers directly over administrative ports.

An example architecture:

#### Admin Workstation

↓

#### PAM Access Layer

↓

#### PAM Session Gateway

↓

#### Management Network

↓

#### Critical Servers

Target servers can accept only management traffic coming from the PAM Gateway.

This model can reduce the lateral movement risk.

At the same time it makes it harder for the attacker to carry out server administration directly over a compromised endpoint.

### Should PAM and a Privileged Access Workstation Be Used Together?

**Inside high-security environments a Privileged Access Workstation – PAW or Secure Administrative Workstation can be used.**

The administrator does not carry out privileged operations over a normal laptop.

They use a dedicated hardened workstation.

This device:

internet browsing,

personal e-mail,

unapproved software

is not used for these.

When PAW + PAM are used together:

**Trusted Admin Device + Controlled Identity + Controlled Session**

this model arises.

This provides a strong security architecture especially for Tier 0 infrastructure.

### Architectural Criteria in PAM Product Selection

While evaluating CyberArk, BeyondTrust, Delinea, One Identity Safeguard, WALLIX, ManageEngine PAM360, Keycyte and other PAM platforms one should not look only at the product feature list.

The organization's real architecture requirements must be determined.

For example these questions can be asked:

Will on-premises or cloud PAM be used?

How many privileged accounts are there?

How many concurrent sessions are there?

Are RDP and SSH proxies necessary?

Should database access be supported?

Will network devices be onboarded?

Is service account rotation necessary?

Will DevOps secrets be managed?

Is Endpoint Privilege Management necessary?

How important is JIT/ZSP support?

How will SIEM/SOC integration be carried out?

How will the HA/DR architecture be?

The answers to these questions should guide the product selection.

The PAM product should not determine the architecture; the PAM architecture should determine which product is suitable.

### The Most Frequently Made Mistakes in a PAM Architecture

In corporate PAM projects the following mistakes are frequently seen:

- Positioning PAM only as a Password Vault
- Not carrying out Privileged Account Discovery
- Missing the administrator accounts outside PAM
- Leaving direct RDP/SSH access open
- Permitting users to see the passwords
- Not applying Password Rotation
- Carrying out rotation without analyzing Service Account dependencies
- Not using JIT Access
- Not reducing Standing Privileges
- Leaving Local Admin Rights outside PAM
- Keeping Cloud Privileges outside the scope
- Not taking DevOps Secrets into the PAM/NHI programme
- Carrying out PAM Session Recording and not analyzing the recordings
- Not sending PAM logs to the SIEM
- Not monitoring Break-Glass accounts
- Not protecting the PAM infrastructure as Tier 0
- Not designing PAM HA
- Not carrying out PAM DR tests
- Not applying Network Segmentation
- Seeing PAM as a one-off technology project

### Corporate PAM Architecture Checklist

In a PAM architecture evaluation the following controls can be used:

- Is a Privileged Identity Inventory present?
- Is Privileged Account Discovery being carried out?
- Is risk-based PAM onboarding being applied?
- Are Domain Admin accounts within the scope of PAM?
- Are Cloud Administrator roles within the scope of PAM/PIM?
- Do database administrators access over PAM?
- Do network administrators access over PAM?
- Are backup administrators managed separately?
- Are Service Accounts in the inventory?
- Is a Credential Vault being used?
- Is Password Checkout at a minimum level?
- Is a passwordless privileged session supported?
- Is Automated Password Rotation active?
- Are direct RDP/SSH accesses being blocked?
- Is a Privileged Session Proxy being used?
- Is Session Recording active?
- Is JIT Access being applied?
- Is JEA being applied?
- Is there a Zero Standing Privilege roadmap?
- Is Endpoint Privilege Management being used?
- Are Local Admin Rights being reduced?
- Are DevOps Secrets managed centrally?
- Are Dynamic Secrets being evaluated?
- Are Non-Human Identities being taken into the scope of PAM?
- Are AI Agent privileges being controlled?
- Are PAM logs being sent to the SIEM?
- Is integration with ITDR being evaluated?
- Is the PAM network segment separate?
- Have PAM administrator identities been separated?
- Is Strong MFA being applied for PAM?
- Is PAM High Availability present?
- Is PAM Disaster Recovery present?
- Is DR tested regularly?
- Are Break-Glass accounts under control?
- Does Emergency Access use produce an alert?

### PAM Maturity Levels

**Level 1 – Direct Privileged Access: Administrators connect directly to target systems. Shared passwords and permanent privileges are widespread. Privileged activity visibility is low.**

**Level 2 – Vault-Centric PAM: Administrator credentials have been taken into the Vault. Password Rotation is applied but direct access or standing privilege can continue.**

**Level 3 – Session-Centric PAM: Administrative access is passed over the PAM Session Gateway. MFA, Session Recording and approval workflows are applied.**

**Level 4 – JIT Privilege Architecture: Permanent administrator permissions are reduced. JIT, JEA, PIM and Endpoint Privilege Management are used. PAM is integrated with the SIEM and ITDR.**

**Level 5 – Zero Standing Privilege Architecture: For Human, Machine and AI Agent identities privileged access is created at the moment of need and in a policy-driven way. Short-lived credentials, dynamic secrets and continuous risk evaluation are used.**

This transformation:

#### Password Management

↓

#### Session Management

↓

#### Privilege Management

↓

#### Identity-Based Privilege

↓

#### Zero Standing Privilege

proceeds in this way.

### Frequently Asked Questions

#### What is a PAM architecture?

A PAM architecture is the security structure in which the Vault, Session Management, MFA, JIT, JEA, credential rotation, monitoring and governance components that enable privileged identities, credentials and administrative sessions to be managed safely work together.

#### What is a PAM Vault?

It is the security component in which privileged passwords, secrets and other sensitive credentials are stored centrally and in encrypted form.

#### What is a PAM Session Proxy?

It is the intermediate layer that enables the RDP, SSH or similar privileged connection between the administrator and the target system to be passed over PAM.

#### What is JIT Access?

It is administrator privilege being given temporarily only for the period needed instead of being kept continuously active.

#### What is JEA?

Just-Enough-Access aims for the minimum privilege necessary for the operation the user will carry out to be given to them.

#### What is Zero Standing Privilege?

It is the approach of the privilege being created temporarily at the moment of need and removed after the operation instead of leaving permanent privileged permission on identities.

#### What is the difference between PAM and PIM?

While PIM mostly focuses on privileged roles and role activation processes, PAM can contain broader privileged access security capabilities such as credential, session, password rotation, service account and endpoint privilege.

#### Why should direct RDP be closed in PAM?

If the administrator can connect directly to the target server outside PAM, Session Recording, approval and other PAM controls can be bypassed.

#### Is High Availability necessary for PAM?

If PAM is becoming the centre of critical administrative access availability is extremely important. In the case of a PAM outage administrators may not be able to access critical systems.

#### Is Disaster Recovery necessary for PAM?

Yes. Because PAM's credentials and privileged access infrastructure are critical there must be a recovery plan for site-level failure and disaster scenarios.

#### What happens if the PAM server is obtained?

Because PAM is high-value security infrastructure a compromise can create a serious risk. For this reason PAM systems must be protected at the Tier 0 level; network segmentation, MFA, dedicated administration, EDR, SIEM monitoring, secure backup and strong hardening must be applied.

#### Is PAM necessary in a cloud environment?

Yes. However, cloud privileged access is not managed only over passwords. Cloud roles, JIT activation, temporary credentials, PIM, workload identities and entitlement management are parts of a modern cloud PAM architecture.

#### Can PAM be used for DevOps?

Yes. The secrets and privileged credentials used by CI/CD pipelines, applications and automation systems can be managed with PAM, Secrets Management or Workload Identity technologies.

#### Should an AI Agent be included in PAM?

If an AI Agent can carry out a privileged action PAM principles must be applied in terms of identity, authorization and privilege lifecycle. Instead of the agent working with a permanent administrator credential scoped and short-lived privileges should be preferred.

### Conclusion: A Strong PAM Architecture Starts Not from the Vault but from the Privileged Access Flow

In a PAM project the Password Vault is an important component.

However, the Vault on its own is not a PAM architecture.

The real security value emerges from how the administrator reaches the target system, how the privilege is given, how long it stays active, how the session is monitored and how the authority is removed after the operation.

The traditional architecture:

**Administrator → Password → Server**

was based on this model.

The modern PAM architecture, on the other hand:

**Identity → Strong Authentication → Policy → JIT/JEA → Controlled Session → Monitoring → Automatic Revocation**

is moving towards this model.

This change is extremely important.

Because in the first model security:

**on the credential**

rests.

In the second model, on the other hand, security:

**identity + context + privilege + time + behavior**

is provided through these.

As cloud and automation adoption increases this architecture is changing even more.

Static passwords are leaving their place to short-lived credentials.

Permanent administrator roles are leaving their place to JIT role activation.

Alongside human administrators service accounts, workloads and AI Agents are being added.

For this reason the PAM architecture of the future will not be a system that protects only administrator passwords.

Modern PAM:

**Human Privileged Access + Machine Privileged Access + Cloud Privilege + AI Agent Privilege**

will have to manage these layers inside a common policy and audit model.

However, at the centre of all technological transformations lies the same principle:

**Least Privilege.**

More privilege than they need should not be given to a user or machine identity and this privilege should not be kept open for longer than it is needed.

For this reason the fundamental formula of modern PAM:

**Discover → Verify → Authorize → Elevate → Monitor → Expire**

can be summarized in this way.

The stronger security target, on the other hand, is:

**No Direct Access + No Shared Credentials + No Permanent Admin + No Unmonitored Privileged Session**

this approach.

And the most important sentence of this chapter:

**The aim of a modern PAM architecture is not to store the administrator password better; it is to take under control where, why, by whom, for how long and for which operation administrator authority can be used.**