Privileged Access Management (PAM)
A privileged account can change a server’s configuration, reach the databases and bypass security controls. Access like that cannot be managed by the same rules as ordinary user access.
Clean up access first
We remove excess privileges before moving them into a new system.
Privilege with an expiry
Access is granted for a task and revokes itself instead of living with a person permanently.
It has to be convenient
A system that is hard to use soon grows workarounds and shadow access.
Privileged Access Management solutions
Hafaza Tech designs and implements PAM based on Delinea, Fudo Security, Segura and Krontech, tying the technology to the real model of administrative access in the organization.
An enterprise PAM platform. Used for managing credentials, granting privileged access, controlling sessions and running least-privilege scenarios.
The exact set of components is defined by the customer’s architecture and the scenarios they need.
Used for managing privileged access and controlling administrative sessions.
Suits controlled remote access, session monitoring and the management of privileged credentials. The specific protocols and control mechanisms are verified against the current version and during the pilot.
An enterprise PAM platform for managing privileged access, credentials and administrative sessions.
The new name of senhasegura — the vendor has rebranded, so both names will be in circulation for a while. We consider it where the full lifecycle of privileged access has to be built.
Kron PAM covers the core scenarios: privileged session management, secure storage of credentials and control of administrative access.
We deliberately avoid describing the platform with a long feature list — for a project it matters more to verify the required protocols, session control, credential handling and integrations against the current version.
What PAM is
It is more than a password vault
Keeping administrative passwords in a secure vault is an important control, but on its own it does not solve the problem. If a user keeps standing administrative rights and can connect to systems directly, a vault changes little. PAM is a combination of credential protection, authorization, least privilege, session control, audit and a process that actually works.
Questions PAM answers
Which privileged accounts exist
Who may use them and on which systems
With what level of privilege and under what conditions
For how long and with which credentials
What happens inside a privileged session
When the access has to be revoked
How to prove who performed which actions
The lifecycle of privileged access
Discover
→
Protect
→
Authorize
→
Grant access
→
Monitor
→
Revoke and rotate
→
Audit
The question is not only where the password is kept, but who gets privileged access, when, why and by what route.
Which accounts count as privileged
Privileged access is much wider than the domain administrator. There are almost always accounts in the infrastructure that nobody remembers.
Infrastructure administrators
Active Directory administrators, local administrators, root and sudo, administrators of virtualization and cloud environments.
System and application accounts
Database administrators, accounts on network equipment and security tools, application administrators, service and application accounts.
Special categories
Shared administrative accounts, break-glass emergency accounts, contractor and vendor access, separate machine and application accounts.
Inventory of privileged accounts
The first stage of a project is not installing a password vault
There are almost always accounts in the infrastructure that never made it into the formal management model: old service accounts, local administrators, shared credentials, temporary contractor accounts, accounts from closed projects, privileged groups whose purpose has changed.
What has to be established for every find
Whether the account is needed at all
Who owns it
Which rights are genuinely required
Whether it is in use right now
Whether there are dependencies
Whether it can be deleted or its rights cut back
Whether it has to be brought under PAM
Subject
→
Account
→
Target system
→
Owner
→
Privilege
→
Usage
Fix the access model first, automate second
One of the most dangerous mistakes is to take an existing bad access model and simply automate it.
The goal is to remove unnecessary privileged access before it becomes part of the new PAM architecture, so that old problems are not carried into the new system.
Policies and credentials
Manage not just passwords, but the conditions of access
A mature model is built around authorization rules, not only around handing out a password. A policy answers the question: who → to which resource → with which privilege → under which conditions → for how long. It can take into account the account, the role, the target system, the privilege required, the time window, MFA, a ticket or change request, approval, location and device posture.
A vault reduces the risk of a password that
Is known to several people
Is kept in Excel or in documentation
Is used on several systems
Is rarely changed
Stays known after the employee changes role
Who
→
To which resource
→
With which privilege
→
Under which conditions
→
For how long
Depending on the platform, the tools used include secure credential storage, automatic rotation, check-out and check-in of passwords, expiry, reconciliation with the target system, password injection without showing it, controlled disclosure and rotation after use. The preferred model is to give a person access to the target system without disclosing its credentials at all.
Least Privilege, Just-in-Time and Just-Enough Access
If a user is always an administrator, compromising their account automatically means compromising the privileges.
Just-Enough Access narrows the scope of the privilege further: the user gets only the actions needed for a particular operation.
PAM should reduce standing privileges
Not put them behind a nicer interface. The goal: the minimum privilege → only when needed → only where needed → only for as long as needed.
Not every privileged action has to go through manual approval: if every routine operation turns into a long approval, people start working around the process.
MFA and PAM solve different problems
MFA answers the question “is this really that user?”. PAM answers in addition whether they are entitled to privileged access, to which resource, in which role, for how long, whether approval is needed, which credentials will be used and when the access is revoked.
MFA is one element of a PAM architecture, not a replacement for it.
Session control and audit
A recorded video of an RDP session is only one possible element of audit. What matters more is that no privileged action bypasses the access rules and the log.
PAM is not necessarily built on a proxy: control can be provided through a session proxy, agents on the systems themselves, a broker that issues credentials, privilege elevation on request, or a combination of these. The key principle is different — privileged actions must not bypass the access rules and the audit trail.
The retention period and location of recordings, access to them, privacy compliance, protection against tampering and integration with SIEM are designed separately.
Contractor and vendor access
One of the most obvious PAM scenarios is administrative access for external specialists. A contractor gets access to a specific system for a limited time and never sees the credentials.
A contractor gets access only to a defined system, in an agreed time window, after approval, without knowing the credentials, and every action is recorded. PAM makes it possible to separate remote access from privileged authorization, so an ordinary VPN does not become a universal administrative entry point.
Service accounts, application secrets and EPM
Privileged accounts do not belong only to people. These adjacent areas are worth keeping distinct from the lifecycle of human access.
Service accounts
Passwords are rarely changed, credentials are written straight into scripts, one account is used by several applications, the owner is unknown, and rotation can break dependent services.
Discover → Identify the owner → Map dependencies → Protect → Rotate → Verify
Application secrets
Application secrets, API keys, tokens, credentials of CI/CD pipelines and workloads. They usually have to be used and changed programmatically, without a person involved.
In the design it is important to separate privileged access for people from secrets for machine-to-machine communication, and to apply different controls to each.
Endpoint Privilege Management
An adjacent but separate technology: removing standing local administrator rights, allowing a specific application to run elevated, granting administrative rights temporarily, controlling privileged applications.
Not a mandatory component of every PAM deployment. If EPM is part of the chosen ecosystem, it is treated as a separate control with an architecture of its own.
PAM as a critical security component
A large share of administrative access runs through this system
Compromising PAM potentially gives access to many target systems at once. PAM being unavailable, conversely, leaves administrators unable to manage the infrastructure. So PAM itself needs a well-thought-out protection model, and if access to the most critical systems runs through it, its own administration is protected to the same standard.
What is designed in advance
Fault tolerance, backup, disaster recovery, replication
Protection of the vault and the encryption keys
Storage of session recordings
Network placement and certificate management
Time synchronization, monitoring, logging
Separation of administration and emergency access
Emergency access (break-glass)
A failure of the PAM platform itself must not make recovery of the infrastructure impossible. The emergency access mechanism is separated from the normal process, tightly limited, protected, monitored, audited and tested regularly.
Use of an emergency account should raise an alert and a follow-up review. What needs testing is not just the password itself but the recovery scenario: what happens if PAM and the access management systems are unavailable at the same time.
Separation of duties
One person should not be able to create privileged access, approve it, use it and alter the audit trail on their own.
So the roles are split: platform administration, access approval, ownership of privileged accounts, audit, session review and security administration. The most critical operations get an extra approval or the four-eyes principle.
PAM does not replace a well-designed account model. If a single privileged account has access to Active Directory, servers, databases, network equipment, firewalls, backup and virtualization all at once, putting it in a vault does not make the model secure. Privileged accounts have to be separated by purpose and level of trust.
Integration and isolated environments
PAM as a source of access data for the SOC
PAM produces valuable telemetry: privileged logins, failed access attempts, approvals, JIT requests, credential usage, session starts, emergency access and policy violations. The chain “a new JIT privilege → an unusual target system → access outside working hours → an endpoint security alert” is far more informative than any one of those events on its own.
What regulated environments require
Local management and the organization’s own vault
Local session control components
Controlled updates
Integration with AD and LDAP
Operation across segmented networks
Local storage of logs and recordings
In the design it is especially important to place the PAM components correctly relative to the network segments: the system must not become a new uncontrolled bridge of trust between isolated segments.
How Hafaza Tech implements PAM
A project does not start with installing a password vault. The main job is to change the way privileged access is obtained, so the stages run from putting things in order to automation, not the other way round.
Assessment
→
Inventory
→
Access clean-up
→
Access model
→
Architecture
→
Pilot
→
Onboarding accounts
→
Access control
→
Integration
→
Phased rollout
→
Regular review
We identify the privileged users, the target systems, the existing accounts, direct RDP and SSH access, service accounts, contractor access, the current MFA and the approval process. We analyze the access model separately: AD groups, local groups, sudo, RBAC, shared accounts and excessive rights.
We build a map: Subject → Account → Privilege → Target system → Owner → Usage, covering not only the known administrators but the unmanaged privileged accounts too. Before onboarding to PAM we decide which accounts to delete, which rights to reduce and which shared accounts to replace.
We design the future access architecture: “user → MFA → policy → PAM → target system”, or “request → approval → temporary privilege → automatic revocation”. System administrators, database administrators, network engineers, developers, contractors and auditors each get a different process.
The pilot is tested on real administrative scenarios: Windows administration, SSH, access to network equipment and databases, remote contractor access, password rotation, JIT, approval and session audit. We check not only the features but the convenience, the latency, protocol compatibility and recovery.
Accounts are brought under PAM gradually. Before onboarding you need to know the owner, the target system, the dependencies, the rotation method, the approval requirements and the rules for disclosing the password. Service accounts call for particular care: the wrong rotation can stop an application.
We roll out in stages: critical accounts → individual administrators → critical systems → contractors → the rest of the infrastructure → service accounts. The exact order follows the risk assessment. After the rollout, new privileged accounts and residual standing privileges are reviewed regularly.
A security tool that is inconvenient to use will sooner or later be worked around: shadow access paths appear, credentials get shared, emergency accounts are abused. So the architecture has to provide fast routine access, approvals scaled to risk, automated scenarios for low-risk operations, a link to the ticketing system, convenient JIT and stable operation of the administrative protocols.
Delinea, Fudo, Segura or Krontech?
There is no universally best PAM platform. We define a few critical scenarios and test them in a PoC: can the standing privilege be removed → the credentials hidden → the access authorized → the administrative task completed → the audit trail produced. That is more useful than comparing hundreds of rows in a feature table.
Accounts and targets
Types of privileged accounts, target systems, operating systems, databases, network equipment.
Deployment model
Cloud or on-premise infrastructure, service accounts, contractor access, fault tolerance and disaster recovery requirements.
Access control
Requirements for JIT, session control and credential rotation.
Integrations
SIEM, ITSM, access management systems, ticketing and secret stores.
Operations
Licensing and operational complexity — how realistic the system is to run day to day.
Metrics, not the number of accounts in the vault
Share of privileged accounts under management, unmanaged accounts, residual standing privileges, JIT adoption, rotation success rate, shared credentials, stale contractor access, time to revoke access.
The goal of PAM is to steadily reduce the sum of: unknown privileges + standing privileges + shared credentials + uncontrolled access.
Any other questions? We will definitely answer!
Didn't find the answer to your questions? Send your question below and our support team will answer it soon. We are here to help you with cybersecurity!
Ask a question!
Get a consultation!
If you want to learn more about our cybersecurity services or are not sure which solutions are right for you, leave a request and our specialists will contact you for a free consultation.
Related solutions
Complementary solutions for comprehensive infrastructure protection and a higher overall level of information security.
Database Security
Control over what privileged users do inside the database itself.
SIEM
Correlation of privileged events with the rest of the security telemetry.
Vulnerability & Patch Management
Remediation of vulnerabilities on the systems that administrative access is granted to.