# Privileged access

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/privileged-access

## Quick definition

Privileged access means having extra permissions beyond a standard user. It lets you do important tasks like installing programs or managing other users. Because it is powerful, it must be carefully controlled to prevent misuse. Think of it as having a master key to a building instead of just a key to one room.

## Simple meaning

Imagine you work in a large office building. As a regular employee, you have a badge that lets you enter your own floor and your own office. You can use the break room and the bathroom, but you cannot enter the server room, the CEO's office, or the maintenance tunnels. That is like having standard user access in a computer system.

Now imagine you are the building's facilities manager. Your badge lets you go everywhere. You can unlock any door, turn off the security system, and access the electrical panels. That is privileged access. In the IT world, privileged access is the master key that lets administrators bypass normal restrictions. It allows them to install new software, create or delete user accounts, change security settings, access confidential files, and even shut down entire systems.

Privileged access is not just for people. Software programs and automated processes also need privileged access to do their jobs. For example, a backup program needs privileged access to read all files and copy them to a storage drive. A security scanner needs privileged access to check every part of the system for vulnerabilities.

Why is this so important? Because with great power comes great responsibility. If a malicious hacker gets privileged access, they can steal all your data, install ransomware, or destroy your entire network. That is why organizations use special tools like Privileged Access Management (PAM) to control and monitor who has this power. They enforce the principle of least privilege, which means giving someone only the permissions they need to do their job and nothing more.

In everyday life, think of privileged access like a parent's control over a child's tablet. The parent can install apps, set screen time limits, and view browsing history. The child can only use the apps already installed. The parent has privileged access; the child has standard access. The same idea applies in companies, where IT administrators have privileged access to manage systems while regular employees only have access to the applications they need for their work.

Understanding privileged access is crucial for anyone studying IT security. It appears on almost every major certification exam, and real-world security breaches often happen because privileged access was not properly protected.

## Technical definition

Privileged access refers to elevated permissions granted to users, accounts, processes, or systems that exceed those of a standard non-administrative user. In technical terms, it is the ability to perform actions that affect the security posture, configuration, or core functionality of an operating system, application, network device, or cloud environment. Privileged access is typically associated with user accounts that belong to built-in administrative groups such as Administrators on Windows, root on Linux, or Domain Admins in Active Directory.

A key protocol governing privileged access is the Security Account Manager (SAM) on Windows and the /etc/passwd and /etc/shadow files on Linux, which store user account information and password hashes. When a user authenticates with an administrative account, the operating system issues a security token or access token that contains the user's security identifier (SID) and group memberships. This token is then compared against access control lists (ACLs) on securable objects to determine if the requested action is allowed. For example, when an administrator attempts to modify a system file, the Windows security reference monitor checks the token against the file's ACL. Because the administrator's token includes the Administrators SID, and the ACL grants the Administrators group full control, the action is permitted.

On Linux systems, privileged access is managed through user IDs (UIDs). The root user has a UID of 0 and can bypass all permission checks. Processes running as root can read, write, or execute any file, change the system time, create device nodes, and interact directly with hardware. Linux also employs capabilities, which are fine-grained privileges that can be assigned to non-root users or processes. For example, the CAP_NET_BIND_SERVICE capability allows a process to bind to a privileged port (below 1024) without full root access.

In enterprise environments, privileged access is often managed through a dedicated Privileged Access Management (PAM) solution. PAM systems provide a centralized vault for storing administrative credentials, session recording, password rotation, and just-in-time (JIT) access. JIT access grants temporary elevated permissions only when needed, reducing the attack surface. For instance, a support engineer may request temporary root access to a production server for a two-hour maintenance window. The PAM system approves the request, creates a one-time password, records all commands executed, and then automatically revokes the access after the window expires.

Cloud environments have their own models for privileged access. In AWS, IAM roles with AdministratorAccess or PowerUserAccess policies provide privileged access. In Azure, the Global Administrator and Privileged Role Administrator roles grant broad control over Azure AD and subscriptions. Azure AD Privileged Identity Management (PIM) provides JIT activation and approval workflows for these roles.

Standards and frameworks such as the NIST SP 800-53, ISO 27001, and the CIS Controls mandate strict controls over privileged access. The principle of least privilege is a core requirement: users should have only the minimum permissions necessary to perform their job functions. Segregation of duties ensures that no single individual has both the ability to request privileged access and the authority to approve it. Regular audits and reviews of privileged account usage are required to detect misuse.

Real IT implementation involves creating separate administrative accounts that are not used for daily activities like checking email or browsing the web. These accounts are often named differently (e.g., jdoe_adm) and require smart card or multi-factor authentication. Organizations also implement jump servers or bastion hosts: dedicated, hardened systems through which all privileged access to production environments must pass. All sessions are logged and monitored for suspicious activity.

Privileged access is also relevant to service accounts, which are non-human accounts used by applications and services to interact with the operating system or other services. These accounts often have elevated privileges and run with high integrity levels. If a service account is compromised, an attacker can leverage its privileges to move laterally across the network. Therefore, service accounts should be documented, have strong passwords, and be subject to periodic privilege clean-up.

## Real-life example

Think about a large hotel. The hotel has many rooms, each with its own door lock. Guests get a key card that only opens their assigned room and maybe the fitness center or pool. This is like standard user access. They cannot enter the hotel's back office, the mechanical room, or the manager's suite.

Now consider the hotel manager. The manager carries a master key that opens every single room in the hotel, including supply closets, the laundry room, the electrical panel room, and the security office. The manager can also override the computer system that controls the door locks, assign new key cards, and review the logs of who entered which room. This is privileged access.

But the manager is not the only one with a master key. The head of maintenance also has a master key so they can fix plumbing issues in any room. The IT coordinator has a master key to access the network server closet. The security supervisor has a master key to investigate incidents. In a well-run hotel, there is a strict log of who has a master key, when they use it, and why. If a master key is lost or stolen, it is a major security incident because someone could enter any room at any time.

That is exactly how privileged access works in IT. Standard users can only access their own files and applications. Administrators have master keys that let them go anywhere and do anything on the system. If an administrator's password is stolen, the attacker has the master key to the entire network.

To protect the hotel, the manager might decide that not everyone with a master key should use it all day. Instead, the master keys are kept in a secure safe. To get a master key, an employee must sign it out, explain why they need it, and return it afterwards. That is just-in-time access. The hotel might also require two people to be present when the master key is used, a form of dual control.

This analogy shows why privileged access needs careful management. You would not want a disgruntled employee with a master key to walk into every room and steal valuables. Similarly, in IT, you do not want a disgruntled or compromised administrator to delete all databases or install ransomware. By controlling and monitoring privileged access, organizations reduce the risk of catastrophic damage.

## Why it matters

In practical IT, privileged access is the single most critical security control. If an attacker gains privileged access to a system, they can bypass almost all other security measures. They can disable antivirus software, delete logs, create backdoor accounts, exfiltrate sensitive data, and deploy ransomware. Many of the most damaging cyberattacks in history, such as the 2013 Target breach and the 2017 Equifax breach, involved the compromise of privileged credentials.

For IT professionals, managing privileged access is a daily responsibility. System administrators must use separate administrative accounts, enable multi-factor authentication on all privileged accounts, and limit the use of shared accounts like root or Administrator. They must also conduct regular audits to ensure that former employees no longer have privileged access.

Privileged access is also central to compliance. Regulations like GDPR, HIPAA, PCI DSS, and SOX require organizations to control and monitor access to sensitive data. Failing to protect privileged access can lead to fines, lawsuits, and reputational damage.

the shift to cloud computing has made privileged access management even more complex. Cloud environments have their own administrative roles and APIs. Misconfigurations, such as granting too broad permissions to an IAM role, can expose the entire cloud infrastructure to attack. Tools like AWS IAM Access Analyzer and Azure AD PIM help, but they require ongoing attention.

Finally, understanding privileged access is foundational for earning IT certifications. Almost every security exam covers the principle of least privilege, separation of duties, and the need to protect administrative accounts. Without a solid grasp of these concepts, candidates will struggle with scenario-based questions that ask about securing privileged access.

## Why it matters in exams

Privileged access is a core concept for multiple certification exams. On the CompTIA Security+ exam, it appears under Domain 3 (Implementation), specifically in objectives related to identity and access management, the principle of least privilege, and account management. You may see scenario questions where you must choose the best way to grant temporary administrative access or determine why a shared root password is a security risk. The exam also tests your knowledge of PAM solutions and just-in-time access.

For the ISC2 CISSP exam, privileged access is part of Domain 5 (Identity and Access Management). The CISSP emphasizes concepts like separation of duties, need-to-know, and rotation of privileged duties. You will need to understand how to design a privileged access governance framework and how to audit privileged account usage. The exam also covers the difference between administrative accounts, service accounts, and emergency accounts (break-glass accounts). Exam questions often present a scenario where an organization is implementing a new access control policy, and you must identify the best practice for managing root accounts in a Linux environment or Domain Admins in Active Directory.

The AWS Certified Solutions Architect (SAA) exam covers privileged access through IAM policies and roles. You need to know how to create least-privilege IAM policies, use IAM roles with temporary security credentials, and set up AWS Organizations to enforce service control policies. Questions may ask you to design a solution where developers have administrative access only in a specific account, or where a Lambda function needs privileges to read from an S3 bucket.

Microsoft exams like MD-102, MS-102, AZ-104, and SC-900 all cover privileged access management in Microsoft 365 and Azure contexts. The SC-900 (Security, Compliance, and Identity Fundamentals) specifically tests knowledge of Azure AD PIM, role-based access control (RBAC), and privileged identity management. You might be asked how to enable just-in-time access for a Global Administrator role or how to review privileged role assignments.

The CySA+ exam, being focused on security analytics, tests your ability to detect and respond to misuse of privileged access. Questions may involve analyzing logs to identify a suspicious account that was added to the Domain Admins group or detecting pass-the-hash attacks that leverage privileged credentials.

Finally, the ISC2 Certified in Cybersecurity (CC) exam introduces privileged access at a foundational level. You will need to understand why administrative accounts should not be used for daily tasks and what the principle of least privilege means. This exam uses multiple-choice questions that directly ask about best practices.

Across all these exams, privileged access is a recurring theme. Candidates should practice with scenario-based questions and be able to explain why each control, such as MFA for admins or separate admin accounts, reduces risk.

## How it appears in exam questions

Privileged access questions appear in several common patterns across certification exams. The most frequent is the scenario-based question where a company is implementing a new access control policy and you must recommend the best way to manage administrative privileges. For example: "A system administrator needs to perform maintenance on a production server during a two-hour window. Which of the following is the most secure method to grant this access?" The correct answer typically involves a PAM solution with just-in-time access and session recording.

Another pattern is the conceptual question that tests your understanding of least privilege. You might be asked: "Which of the following best describes the principle of least privilege?" with options that confuse it with separation of duties or need-to-know. The correct answer is that users get only the permissions needed to perform their job functions.

Configuration-based questions are common on Azure and AWS exams. For Azure, you might see: "You need to ensure that the Global Administrator role in Azure AD requires approval before activation. What should you configure?" The answer is Azure AD Privileged Identity Management. For AWS, a question might ask: "An IAM user needs to temporarily assume an administrator role to troubleshoot an EC2 instance. Which feature should you use?" The answer is AWS STS (Security Token Service) with an IAM role.

Troubleshooting questions involve diagnosing a security breach. For example: "A security analyst finds that an attacker used stolen credentials to add a new account to the Domain Admins group. Which control would have prevented this?" Options include requiring MFA for all privileged actions, using a PAM solution with approval workflows, or implementing a separate admin forest.

Multiple-choice questions often contain distractors that sound similar but are incorrect. For instance, a question might ask about the most secure way to store admin passwords, with options like "store in a text file on the admin's desktop" (wrong), "use a password manager with MFA" (better), or "use a PAM vault with automatic rotation" (best). The exams are designed to test your ability to choose the strongest security control.

Some exams also use drag-and-drop or ordering questions where you must arrange steps for granting privileged access in the correct order. For example, for a JIT access request: submit request, manager approves, PAM generates temporary password, administrator performs task, access is revoked, and session is audited.

Finally, some questions test your knowledge of logging and monitoring. You might be asked which events related to privileged access should be sent to a SIEM for alerting, such as successful logons with admin accounts outside business hours, or creation of new privileged accounts.

## Example scenario

You are an IT support technician at a medium-sized company called TechWidgets Inc. The company uses a Windows Server with Active Directory. You have been asked to help with a security audit. The audit team wants to see who has administrative rights on the server and whether those rights are being used appropriately.

You start by running a command to list all members of the Domain Admins group. To your surprise, you see that three people are members: the IT manager, a temporary contractor who left last month, and a user named jdoe who is the CEO's assistant. You know that jdoe only needs to reset passwords and unlock accounts. Having full Domain Admin rights is excessive and dangerous.

When you investigate further, you discover that the previous IT administrator had given everyone in the IT department full admin rights to "make things easier." There was no process for requesting or approving privileged access. Passwords for the built-in Administrator account were shared via email, and no one used multi-factor authentication.

You realize that if a hacker managed to compromise any of those accounts, they would have complete control over the entire Windows domain. They could deploy ransomware across all computers, steal financial data from the accounting server, or delete all user data in the company.

Following security best practices, you implement the following changes: You create a new group called Helpdesk Admins that has permissions to reset passwords and unlock accounts, but nothing else. You remove jdoe from Domain Admins and add them to Helpdesk Admins. You remove the departed contractor. You set up a Privileged Access Management solution that vaults all admin passwords, requires approval for their use, and rotates them after each use. You also enforce MFA for all administrative actions.

A month later, the IT manager thanks you. The company had a minor security incident where a phishing email tricked a user into revealing their password, but because the user no longer had admin rights, the attacker could not escalate their privileges. The audit team is satisfied, and the company passes its compliance review.

This scenario shows how improper privileged access management can create a major security risk and how implementing simple controls like least privilege, MFA, and PAM can protect an organization.

## Common mistakes

- **Mistake:** Believing that only the root or Administrator account has privileged access.
  - Why it is wrong: Privileged access can be granted to any account through group memberships, sudoers entries, or role assignments. A standard user added to the Domain Admins group has just as much power as the Administrator account.
  - Fix: Audit all group memberships and role assignments regularly. Look for accounts in groups like Administrators, Domain Admins, sudo, or equivalent.
- **Mistake:** Using the same account for daily work and administrative tasks.
  - Why it is wrong: If an admin uses their privileged account to check email or browse the web, and that account gets compromised by malware, the attacker gains full system access. The principle of separation of duties requires separate accounts for administrative and non-administrative activities.
  - Fix: Create a separate administrative account with a different username (e.g., jdoe_adm) and use it only for privileged tasks. Never log into that account for routine activities.
- **Mistake:** Sharing the root or Administrator password among multiple team members.
  - Why it is wrong: Shared passwords break accountability. If a malicious action is performed using the shared password, you cannot determine who did it. Shared passwords also increase the attack surface because the password is known to more people.
  - Fix: Use a PAM solution that provides unique, temporary credentials for each user. Alternatively, use sudo with individual user accounts and review logs to track who ran which command.
- **Mistake:** Granting all IT staff full admin rights by default.
  - Why it is wrong: This violates the principle of least privilege. Most IT staff do not need full admin rights to do their jobs. A helpdesk technician may only need password reset rights, not full Domain Admin privileges. Over-provisioning leads to unnecessary risk.
  - Fix: Implement role-based access control (RBAC). Define specific roles with the minimum permissions required for each job function. For example, create a role for password resets, a role for server maintenance, and a role for security auditing.
- **Mistake:** Not enabling multi-factor authentication (MFA) on privileged accounts.
  - Why it is wrong: Passwords alone are weak. They can be stolen through phishing, keylogging, or data breaches. MFA adds an extra layer of security that makes it much harder for an attacker to use stolen credentials. Without MFA, a single password compromise can lead to a complete system takeover.
  - Fix: Configure MFA for all privileged accounts, either through a dedicated MFA solution or cloud identity provider. For on-premises AD, use Windows Hello for Business or a third-party MFA integration.
- **Mistake:** Assuming that cloud environments are immune to privileged access risks.
  - Why it is wrong: Cloud environments have their own forms of privileged access, such as IAM roles with AdministratorAccess, Azure Global Administrator roles, or root user accounts. Misconfigured permissions can expose the entire cloud infrastructure. Many breaches occur because of overly permissive IAM policies.
  - Fix: Apply the same least privilege principles to cloud accounts. Use managed policies with minimal permissions, enable MFA for all console access, and use cloud-native tools like AWS IAM Access Analyzer or Azure AD PIM to review and restrict privileged roles.
- **Mistake:** Failing to revoke privileged access when an employee leaves or changes roles.
  - Why it is wrong: Former employees or employees who moved to a different department may still hold privileged access. This is a classic insider threat. Disgruntled former employees have caused significant damage by using old credentials.
  - Fix: Implement a formal offboarding process that immediately disables all accounts and revokes group memberships when an employee departs. Regularly review privileged access assignments as part of quarterly audits.

## Exam trap

{"trap":"On several exams, you will see a question that asks: 'Which of the following is the MOST secure way to manage privileged access?' and one of the options is 'Use a shared administrative account with a strong password.' Many learners pick this because they think a strong password is sufficient.","why_learners_choose_it":"Learners focus on the password strength and overlook the word 'shared.' They assume that a strong password is the best defense. They may not fully grasp the importance of individual accountability and non-repudiation.","how_to_avoid_it":"Recognize that any shared account violates the security principle of accountability. A strong password does not solve attribution. The most secure approach is to use individual accounts with just-in-time access, MFA, and session monitoring. Always choose options that enforce least privilege and individual accountability over password-only controls."}

## Commonly confused with

- **Privileged access vs Administrative rights:** Privileged access is a broader concept that includes administrative rights but also covers service accounts, API keys with full permissions, and emergency break-glass accounts. Administrative rights are just one type of privileged access. In exams, 'administrative rights' refers specifically to built-in admin accounts, while 'privileged access' can include any highly permissive account or role. (Example: A service account running a backup application has privileged access because it needs to read all files, but it is not an administrative account used by a human.)
- **Privileged access vs Least privilege:** Least privilege is a security principle that guides how privileged access should be granted. It says users should have only the minimum permissions needed. Privileged access is the actual permission level. You can have privileged access without applying least privilege (e.g., giving a user full admin rights when they only need password resets). (Example: Applying least privilege to a helpdesk technician means giving them only the 'Reset Password' right, not full Domain Admin rights.)
- **Privileged access vs Separation of duties:** Separation of duties is a principle that prevents any single person from having too much power. It divides critical tasks among multiple people. Privileged access is what must be split. For example, one person can request a privileged operation, another must approve it, and a third audits the action. (Example: An administrator cannot both create a new admin account and also approve that account creation; those duties are separated.)
- **Privileged access vs Privilege escalation:** Privilege escalation is the act of gaining higher levels of access than originally granted. It is an attack technique, not a state of being. Privileged access is the target that attackers seek through privilege escalation. Understanding privilege escalation helps you see why protecting privileged access is critical. (Example: An attacker who compromises a standard user account uses a local exploit to gain root access. That is privilege escalation. The root access is the privileged access they obtained.)
- **Privileged access vs Just-in-time (JIT) access:** JIT access is a method for granting privileged access temporarily only when needed. Privileged access is the permission itself. JIT is a way to manage privileged access securely. In exams, you might be asked to distinguish between permanent privileged access and temporary access granted through a PIM or PAM solution. (Example: A support engineer uses Azure AD PIM to activate the Global Administrator role for one hour. The role is privileged access; the time-limited activation is JIT.)

## Step-by-step breakdown

1. **Identify Privileged Accounts** — The first step is discovering all accounts that have elevated permissions. This includes built-in local admin accounts, domain admin accounts, service accounts with high privileges, and cloud IAM roles with broad permissions. Use scanning tools or manual audits to create an inventory. Without knowing what exists, you cannot secure it.
2. **Classify by Risk Level** — Not all privileged access is equal. Tier 0 accounts (e.g., Domain Admins in Active Directory) have control over the entire identity infrastructure and are the highest risk. Tier 1 accounts (e.g., server admin) control critical servers. Tier 2 accounts (e.g., workstation admin) are lower risk. Classification helps prioritize security controls.
3. **Establish Least Privilege Policies** — Define exactly what permissions each role needs. A helpdesk technician may need only password reset rights, while a database administrator may need full control over SQL servers. Write policies that enforce minimal permissions. This reduces the attack surface and limits damage if an account is compromised.
4. **Deploy Privileged Access Management (PAM)** — Implement a PAM solution to vault credentials, enforce approval workflows, rotate passwords automatically, and record sessions. The PAM system acts as a security layer between the user and the target system. It ensures that no user directly knows the password of a privileged account; instead, they check out the credential through the vault for a limited time.
5. **Enforce Multi-Factor Authentication** — All privileged accounts must have MFA enabled. This can be done through a built-in MFA provider (e.g., Azure AD MFA) or a third-party solution. MFA ensures that even if a password is stolen, the attacker still needs a second factor like a phone or hardware token to authenticate.
6. **Implement Just-in-Time Access** — Replace standing privileged access with time-bound, approved access. Users request elevation when needed, and the PAM system grants it for a specific duration. After the time expires, access is automatically revoked. JIT access minimizes the window of opportunity for an attacker to use stolen credentials.
7. **Monitor and Audit All Activity** — Enable detailed logging for all privileged sessions, including commands run, files accessed, and configuration changes. Send these logs to a SIEM for analysis. Regular audits help detect anomalous behavior, such as an admin logging in at 3 AM from an unusual IP address. Logs are also critical for forensic investigations after a breach.
8. **Review and Revoke Excess Privileges Regularly** — Conduct quarterly reviews of all privileged account memberships and role assignments. Remove any accounts that no longer need elevated privileges. This addresses privilege creep, where users accumulate permissions over time as they change roles. Automation can help by generating reports of stale or overprivileged accounts.

## Practical mini-lesson

Managing privileged access in a real-world enterprise requires a combination of technology, policy, and continuous monitoring. As an IT professional, you will often be responsible for implementing and maintaining a Privileged Access Management (PAM) solution. Let us walk through a typical implementation.

First, you need to inventory all privileged accounts. This includes local admin accounts on thousands of workstations and servers, domain admin accounts, service accounts, application accounts, and cloud IAM roles. Manually tracking these is impossible at scale, so you use discovery tools like Microsoft's Privileged Identity Management (PIM) for Azure AD or third-party tools like CyberArk or BeyondTrust. These tools scan your environment and list all accounts with elevated privileges.

Next, you categorize accounts. In Active Directory, you group accounts into tiers. Tier 0 accounts (Domain Admins, Enterprise Admins, Schema Admins) have the highest privileges and must be protected most aggressively. Tier 1 accounts (server administrators) manage the operating systems of critical servers. Tier 2 accounts (workstation administrators) manage user desktops. You enforce that Tier 0 accounts cannot be used to log into Tier 1 or Tier 2 systems, preventing lateral movement.

Then you configure the PAM vault. You onboard each privileged account into the vault. Instead of knowing the actual password, administrators must check out the password from the vault via an authenticated request. The vault generates a unique password for each checkout, and it can be set to expire after a single use or a time limit. The vault also records all keystrokes and screen activity during the session.

For example, a system administrator named Alice needs to install a security patch on a critical database server. She opens her browser, logs into the PAM portal, and requests the admin account for that server. Her request is routed to her manager for approval. Once approved, the PAM vault gives her a one-time password and logs the start of her session. Alice connects to the server via a jump host, installs the patch, and disconnects. The vault automatically rotates the password so that the old password is no longer valid. The entire session is recorded for later review.

What can go wrong? If the PAM solution itself is not hardened, an attacker could compromise the vault and gain access to all privileged credentials. Therefore, the vault server must itself be treated as a Tier 0 asset, with MFA, strict access controls, and regular patching. Another common issue is that administrators find the PAM workflow tedious and try to bypass it by creating backdoor local admin accounts. This must be prevented through continuous monitoring and strict policy enforcement.

Another practical challenge is managing service accounts. Service accounts often run with high privileges and are rarely changed. Attackers target these accounts because they are often forgotten. You should use managed service accounts (gMSA) in Windows that automatically rotate passwords, or use account discovery tools to identify and secure them.

In cloud environments, privileged access is managed through cloud-native tools. In AWS, you create IAM roles with specific permissions and use IAM policies to enforce least privilege. In Azure, you use Azure AD PIM for JIT activation of roles like Global Administrator. You also enable Azure AD Identity Protection to detect risky sign-ins for privileged accounts.

Finally, successful privileged access management requires buy-in from leadership and users. Users must be trained on the importance of using separate admin accounts and not sharing passwords. Regular security awareness training should include phishing simulations that target admin users to reinforce safe behavior.

Professionals should also stay current with evolving threats. For example, the rise of identity-based attacks like MFA fatigue has led to new recommendations, such as using number matching in MFA prompts or requiring a separate device for approval. The landscape of privileged access security is always changing, and certifications help keep your knowledge up to date.

## Memory tip

Remember the '3 Ps' of privileged access: Protect the accounts (MFA), Provision only what is needed (least privilege), and Prove every action (audit logging).

## FAQ

**What is the difference between a standard user and a privileged user?**

A standard user can only perform tasks that do not affect the core system, like running applications and accessing their own files. A privileged user can change system settings, install software, and access all files. Privileged users have elevated permissions that grant them more control and, accordingly, more responsibility.

**Why should I use a separate account for administrative tasks?**

If you use your regular user account for admin tasks, any malware that infects your machine will inherit those admin rights. By using a separate, dedicated admin account, you reduce the risk that everyday activities like checking email or browsing the web will compromise your administrative privileges.

**What is just-in-time (JIT) access?**

JIT access is a security model where privileged permissions are granted only for a limited time when they are needed, rather than being always available. For example, an admin can request temporary admin rights for a two-hour maintenance window. After that, the rights are automatically revoked.

**Do I need a paid tool to manage privileged access?**

For small environments, you can use built-in tools like sudo on Linux or User Account Control (UAC) on Windows. However, for enterprise environments with many servers and users, a dedicated PAM solution like CyberArk, BeyondTrust, or Microsoft PIM is recommended to automate password vaulting, rotation, and session recording.

**How often should I rotate privileged passwords?**

Best practice is to rotate privileged passwords after each use or at least every 90 days. Many PAM solutions automate this process, changing the password immediately after a user checks it back in. This limits the exposure window if a password is compromised.

**What is a break-glass account?**

A break-glass account is an emergency privileged account that is only used when normal privileged access is unavailable, such as during a system outage or if the PAM solution is down. It is tightly controlled: the password is stored in a sealed envelope, and its use triggers an immediate alert to security teams.

**Can privileged access be removed automatically?**

Yes. Through PAM solutions and identity governance tools, you can set policies that automatically revoke privileged access after a defined period or after a specific task is completed. This reduces the risk of privilege creep and ensures that temporary assignments do not become permanent.

**What is the relationship between privileged access and the principle of least privilege?**

The principle of least privilege dictates that users should have only the minimum permissions necessary to perform their job. Privileged access is the set of permissions an organization grants. Applying least privilege means carefully defining privileged access to ensure no one has more permissions than they absolutely need.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/privileged-access