A step-by-step guide to least privilege

A workflow for EPM for Linux

Scope of this guide

This guide covers the full end-to-end setup workflow for least privilege access on Linux endpoints with BeyondTrust Endpoint Privilege Management (EPM). The idea is simple: give people only the access they need to get their work done, and nothing more.

Following this guide will help you tighten security across your Linux systems, maintain consistent access controls, and capture the audit trails required for SOC 2, ISO 27001, CIS Benchmarks, and PCI-DSS.

Prerequisites

Confirm the prerequisites are in place.

• BeyondTrust EPM for Linux cloud license
• Management console access. Admin-level credentials to EPM Pathfinder
• EPM agent installed on endpoints. EPM Linux agent deployed to all target Linux hosts.
• Network connectivity. Linux endpoints can communicate with the EPM cloud service
• Inventory of user roles and commands. Document of current privileged users and the commands they use

Workflow: Setting up least privilege

The eight steps walk through the complete configuration lifecycle.

Workflow stages at a glance

Step 1: Enable role-based policy

Role-Based Policy (RBP) is the governance framework that drives all least privilege decisions in EPM for Linux. Enabling RBP switches the system from a flat permission model to a structured hierarchy in which permissions are defined by roles, and roles are assigned to users or groups. This is the foundational step that all other configuration depends on.

Why you need this

Without RBP, all users may operate under a single, undifferentiated policy. Enabling RBP allows you to define distinct permission profiles for different job functions (e.g., developer, DBA, sysadmin) and to enforce those boundaries consistently across all managed endpoints.

How to

1. Log in to the BeyondTrust EPM cloud management console using your administrator credentials.
2. Navigate to Policy Management from the left-hand navigation menu.
3. Select Policy Settings (or Global Settings, depending on your console version).
4. Locate the Role-Based Policy toggle or checkbox in the Access Control section.
5. Enable Role-Based Policy and confirm the action when prompted.
6. Save your changes. The console will confirm that RBP mode is now active.

Note: Enabling RBP may not immediately change any end-user behavior. Users will continue to operate under any existing policy until roles and command groups are fully configured and deployed.

Step 2: Create command groups

Command groups are collections of Linux commands or command patterns that you want to control as a unit. Rather than writing individual rules for every possible command, you group related commands together and then apply permissions to the whole group at once. This simplifies policy management as your environment scales.

Why you need this

Command groups are the core of least privilege enforcement at the command level. A well-designed set of command groups lets you express business requirements clearly: a 'Network Diagnostics' group for approved troubleshooting tools, a 'Package Management' group for approved update commands, and so on.

Plan your command groups

Before creating groups in the console, document the commands each user persona legitimately needs. A useful planning matrix might look like this:

How to

7. In the management console, navigate to the What tile in the policy editor.
8. Click Add Command Group and provide a descriptive name (e.g., 'Network Diagnostics - Read Only').
9. Add individual commands using exact paths (e.g., /bin/ping) or patterns using wildcards where appropriate.
10. Set the command disposition to Allow or Reject as required for each entry.
11. Optionally, add a description to document the business justification for the group.
12. Save the command group. Repeat this process for each command group identified in your planning matrix.

⚠️

Avoid using broad wildcards (e.g., /bin/*) in allowed command groups. Overly permissive patterns can inadvertently grant access to commands that were not intended. Always be as specific as possible.

Step 3: Define secure users

In EPM for Linux, a Secure User is a user account that is managed under the EPM policy framework. Once defined as a secure user, an account's privileged command execution is governed by EPM rather than by the operating system's default sudo configuration. This is the step at which you bring your user population under the control of the least privilege model.

Why you need this

Until a user is defined as a secure user, EPM policies do not apply to them. Correctly defining your secure users ensures comprehensive coverage and prevents policy gaps where some accounts remain unmanaged.

User definition approaches

EPM supports several ways to define who is a secure user:

• Individual user accounts: Add specific Linux usernames directly.
• Local groups: Reference operating system groups (e.g., sudoers, wheel) to bring all members under EPM control.
• Directory groups: Integrate with Active Directory or LDAP to use identity provider groups as the source of truth.

How to

13. Navigate to the Who tile in the policy builder.
14. Click Add User or Add Group and specify the user account name, local group, or directory group.
15. For directory-integrated environments, ensure the EPM agent is configured with the appropriate LDAP or AD connection settings before this step.
16. Assign a meaningful label so the user or group can be easily referenced when creating roles.
17. Review the full list of secure users to confirm all privileged accounts are included. Pay particular attention to service accounts and shared accounts.
18. Save your user definitions.

⚠️

Service accounts and shared accounts should also be defined as secure users if they have the potential to execute privileged commands. Leaving them unmanaged creates a policy gap that attackers may exploit.

Step 4: Create roles

Roles are the central building blocks of the least privilege model in EPM. A role combines three dimensions of control: who can act (users and groups), what they can do (command groups), and on which hosts and at what times. Roles translate your organizational job functions into technical policy statements.

Why you need this

Well-defined roles allow you to implement the principle of least privilege accurately and maintainably. A change to a role propagates to all users assigned to it, making policy updates fast and consistent across your entire Linux estate.

Role design principles

• Align roles to job functions, not individuals. Roles such as 'Junior Developer', 'Senior DBA', and 'IT Support' are easier to maintain than person-specific roles.
• Start restrictive and expand. It is easier to grant additional permissions in a controlled way than to take permissions away after users have come to rely on them.
• Separate duties where business requirements dictate. If policy requires that no single person can both deploy code and manage the database, create separate roles that enforce this separation.
• Use host scoping to limit roles to the systems they are relevant to. A database administrator role should only grant database commands on database servers.

How to

19. Navigate to the Roles tile in the policy editor.
20. Click Add Role and provide a descriptive name aligned to a job function (e.g., 'Linux Support - Level 1').
21. In the Who section of the role, add the secure users and groups that should hold this role.
22. In the What section, assign the appropriate command groups that define permitted actions. Set allowed and rejected dispositions as required.
23. In the Where section, restrict the role to relevant host groups or individual hostnames. Avoid leaving the scope set to 'All Hosts' unless genuinely required.
24. In the When section (if available), optionally restrict the role to specific time windows (e.g., business hours only) for added control.
25. Configure privilege escalation settings: define whether commands run as root, a service account, or another specified user.
26. Save the role. Repeat for each job function identified in your user inventory.

💡

Consider creating a 'Break Glass' role with elevated permissions for emergency situations. This role can include additional logging requirements and be restricted to a very small number of trusted administrators.

Step 5: Assign roles

Role assignment is the act of binding the roles you have created to the users and groups who should operate under them. This step makes your policy configuration effective. Until roles are assigned, no access controls are being enforced.

Why you need this

Role assignment determines the effective permissions for every managed user. A careful, deliberate assignment process prevents both over-privileged accounts (a security risk) and under-privileged accounts (an operational risk).

Assignment best practices

• Conduct a role assignment review with the relevant team managers before this step. They will know which team members need which access levels.
• Do not assign multiple overlapping roles unless you have verified how EPM resolves conflicts. In most configurations, the most permissive applicable role wins.
• Keep role assignments in a configuration register (a spreadsheet or CMDB record) so you have an authoritative reference independent of the management console.

How to

27. Navigate to the Roles tile and open each role for editing.
28. Confirm the list of users and groups assigned to the role. Make any adjustments based on the approval process conducted with team managers.
29. Alternatively, navigate to the Who tile, select a user or group, and review all roles assigned to that entity from a user-centric perspective.
30. Verify that every privileged user is accounted for and that no accounts have been left without a role assignment (which would leave them outside policy control).
31. For users who currently rely on unrestricted sudo, confirm that their new EPM role provides equivalent access to everything they genuinely need before proceeding to deployment.
32. Save all assignment changes.

⚠️

Do not go to policy deployment (Step 7) until role assignments are reviewed and approved. Deploying an incomplete policy may disrupt legitimate business operations if users find they cannot run required commands.

Step 6: Audit and monitor

EPM for Linux provides comprehensive session logging and auditing capabilities. This step ensures that logging is configured before deployment, so that from day one you have a complete record of all privileged activity across your managed endpoints.

Why you need this

Audit and monitoring capabilities serve two purposes: security (detecting misuse or anomalous behavior) and compliance (demonstrating to auditors that least privilege controls are operating as designed). Without logging enabled before deployment, you may miss critical activity in the early post-deployment period.

Logging configuration

EPM supports several levels of logging. Configure based on your compliance requirements and storage capacity:

How to

33. In the management console, navigate to Audit and Reporting settings.
34. Enable session logging for all roles that involve elevated privileges.
35. Configure log retention policies in line with your compliance requirements (typically 90 days to 1 year for most frameworks).
36. Set up real-time alerts for high-risk events such as rejected command attempts, access outside business hours, or access to sensitive host groups.
37. Integrate EPM audit logs with your SIEM (Security Information and Event Management) platform if available, to correlate EPM events with other security telemetry.
38. Schedule a recurring review of the EPM Reports section. Recommended cadence: weekly for active operations, monthly for policy review and refinement.

💡

EPM reports can provide evidence of least privilege compliance for audits. Maintain a practice of exporting and archiving monthly summary reports as part of your compliance program.

Step 7: Deploy policies

Policy deployment pushes the configuration you have built in the management console out to the EPM agents running on your managed Linux endpoints. Once deployed, the policies become active and users will operate under least privilege controls.

This is the step when your least privilege model goes live.

Why you need this

Deployment is an operational transition point. Careful preparation ensures that the go-live is smooth and that business operations are not disrupted. A staged deployment approach is strongly recommended for large or complex environments.

Deployment strategy

Consider using a phased rollout:

• Phase 1 - Pilot: Deploy to a small group of volunteer users or a non-production host group. Run for one to two weeks, collecting feedback and reviewing audit logs.
• Phase 2 - Expanded Rollout: Deploy to larger host groups, incorporating any policy adjustments identified in the pilot.
• Phase 3 - Full Deployment: Deploy to all remaining managed endpoints once the policy has been validated.

How to

39. In the management console, navigate to Policy Deployment or Policy Distribution.
40. Select the policy or policy set you have configured in the preceding steps.
41. Choose the target host group for your initial deployment (pilot group for staged rollouts, or all hosts for a direct deployment).
42. Review the deployment summary to confirm the correct policy is being sent to the correct endpoints.
43. Initiate the deployment. The management console will report deployment status for each endpoint.
44. Verify successful deployment by checking the agent status on a sample of endpoints. Confirm that the EPM policy is active by running a test command that should be allowed, and one that should be rejected.
45. Monitor the audit logs closely in the first 24–48 hours post-deployment for any unexpected rejections that may indicate a policy gap.

⚠️

Before deploying to production, ensure you have a rollback plan. Document the steps required to revert to the previous policy state in the event of a critical operational issue.

Ongoing policy maintenance

Implementing least privilege is not a one-time task. Policies require regular review and maintenance to remain effective and aligned to business needs. The following cadences are recommended: