DocumentationAPI ReferenceRelease Notes
Documentation

EPM-L cloud security

ℹ️

For informational purposes only.

Executive summary and overview

BeyondTrust overview

BeyondTrust delivers identity and access security solutions that enforce least privilege, prevent credential theft, and secure access across endpoints, clouds, and infrastructure.

EPM for Linux (EPM-L) overview

BeyondTrust Endpoint Privilege Management for Linux (EPM-L) enables organizations to enforce granular, policy-based least privilege across Linux and Unix environments without disrupting administrative productivity. By replacing unrestricted root or blanket sudo access with fine-grained delegation, command-level filtering, and centralized audit logging, EPM-L prevents unauthorized privilege escalation and lateral movement.

Delivered as a SaaS platform hosted on Amazon Web Services (AWS), EPM-L combines centralized policy management with endpoint-enforced policy execution. This document details the security architecture, endpoint identity, tenant isolation, network controls, and encryption mechanisms protecting customer data within the EPM-L SaaS environment.

Platform architecture and ingress paths

EPM-L SaaS is built on a regional, multi-tier AWS architecture designed to separate administrative web interactions from high-throughput machine-to-machine endpoint communications.

Architecture overview

The platform exposes two distinct ingress paths based on client type:

  1. Machine-to-Machine (M2M): External Linux/Unix endpoints connect over outbound HTTPS (Port 443) using Mutual TLS (mTLS) for cryptographic identity verification.
  2. User-to-Machine (U2M): Human administrators access the management web portal via Amazon CloudFront using browser-based TLS.

Both ingress flows route traffic to dedicated, tenant-isolated compute instances located in secure private subnets.

Endpoint Privilege Management for Linux architecture diagram

Network traffic paths and protocols

Path A: Machine-to-Machine WebSocket (WSS): Policy & Logging

  • Scope: Handles /policy/* and /log/* operations.
  • Protocol: Initiated as an HTTPS request over Port 443, then upgraded via HTTP 101 Switching Protocols to a persistent, bidirectional WebSocket connection.
  • Path: Linux Endpoint → Device-Entrypoint ALB → ECS Client Router → Internal ALB → Tenant EC2 Instance.
  • Connection Management: Both the device-entrypoint and internal ALBs maintain an idle timeout of 900 seconds to preserve long-lived bidirectional tunnels. The internal ALB enforces a 910-second deregistration delay to ensure in-flight connections gracefully drain during instance lifecycle events. WAF is attached to device-entrypoint ALB. All external clients communication (/policy/, /log/ and /REST/*) passes through this firewall.

Path B: Machine-to-Machine REST: Endpoint APIs

  • Scope: Handles short-lived, transactional endpoint requests for external client’s /REST/* requests.
  • Protocol: Standard HTTPS requests.
  • Path: Linux Endpoint → Device-Entrypoint ALB → ECS Client Router → Tenant’s internal ALB → Tenant EC2 Instance.
  • Characteristics: Ephemeral requests using standard HTTP request/response semantics with default timeouts.

Path C: User-to-Machine REST: Management Portal

  • Scope: Administrative access to the web console for policy creation, host management, and analytics.
  • Protocol: HTTPS through Amazon API Gateway. Path C doesn't use mTLS.
  • Path: Administrator browser → BeyondTrust platform authentication → Amazon CloudFront (edge caching) → Amazon API Gateway → backend AWS Lambda function (runs inside the VPC and routes requests by tenant) → internal ALB → tenant EC2 instance
  • Characteristics: All traffic is short-lived REST requests. Edge caching is handled by AWS Lambda@Edge functions running on Amazon CloudFront. Path C bypasses the ECS client router, and M2M traffic never uses this path.

Physical and infrastructure security

EPM-L SaaS is hosted in Amazon Web Services (AWS) data centers. Under the AWS shared responsibility model, AWS is responsible for the physical security of its data centers, including site access, surveillance, intrusion detection, environmental controls, and secure media destruction. Each tenant’s EC2 instance is isolated from other workloads at the hypervisor level and runs in a private subnet within an AWS virtual private cloud (VPC). BeyondTrust is responsible for securing the EPM-L platform deployed on this infrastructure, as described in this document.

WAFs, network control through security groups, IAM policies and roles are in place to bind tenant data to its tenants EC2 instance.

Administrator authentication

Administrators authenticate to the EPM-L web console through the BeyondTrust platform at login.beyondtrust.io. Access to console features is controlled by role-based permissions.

Endpoint identity, authentication and PKI

EPM-L enforces a zero-trust endpoint connection model. Endpoints are authenticated cryptographically prior to receiving policies or dispatching event telemetry.

1. One-Time activation

  • Administrators sign in to the BeyondTrust web console at login.beyondtrust.io and download the client software package.

  • The administrator installs the package on the target Linux or Unix host.

  • From the Installers page, the administrator selects Retrieve Token to generate an activation token.

  • The administrator or an automation runner runs the following command on the host:

    pbactivate -t <access_token>
  • The client sends an HTTPS request over port 443. Amazon Route 53 resolves the request to the regional Amazon API Gateway, which forwards it to a certificate-issuing AWS Lambda function.

2. Certificate issuance and regional subordinate CA

  • The certificate-issuing Lambda function validates the activation token. The client package includes the tenant ID from provisioning, which is used to verify the JSON Web Token (JWT) during activation.
  • After the token is validated, the regional subordinate certificate authority (sub-CA) signs an X.509 client certificate that is unique to the host and the tenant.
  • The certificate and private key are written to the host's local disk.

3. Mutual TLS (mTLS) verification

  • After activation, all machine-to-machine (M2M) traffic from commands such as pbrun connects over port 443 to the SaaS entrypoint URL defined in pb.settings.
  • mTLS terminates only at the device-entrypoint ALB. The ALB validates the client certificate against the regional sub-CA trust store.
  • The ECS client router reads the validated certificate attributes to identify the tenant, then routes the request. Requests without a valid client certificate are rejected.

4. Automated certificate lifecycle and renewal

  • Client certificates are automatically renewed before expiration during routine operations (e.g., during pbrun execution cycles), eliminating manual certificate management overhead and preventing service interruptions.

Tenant isolation and compute security

EPM-L enforces strict tenant isolation at both the compute and network layers.

Architecture LayerIsolation Mechanism
Data ResidencyPermanent Regional Binding: Each tenant is permanently provisioned in a customer-selected AWS region. All traffic, telemetry, logs, and compute remain strictly within that region.
Compute IsolationDedicated EC2 Compute: Each tenant is assigned a dedicated AWS Auto Scaling Group (ASG) maintaining a dedicated EC2 instance. Multi-tenant compute sharing is not used for customer core processing.
Shared Management ServicesTenant-Specific Service Connections: BeyondTrust management services that serve multiple tenants connect to each tenant's instance only through a dedicated, tenant-specific AWS Internal ALB.
Network SegmentationVPC & Security Group Boundaries: Tenant EC2 instances reside in private subnets with no public IP addresses. AWS Security Groups restrict inbound traffic exclusively to the internal ALB.
High Availability & RecoveryAutomated Instance Replacement: Health checks continuously monitor the tenant EC2 instance and EPM-L services. In the event of health check failure, the ASG automatically terminates and reprovisions a fresh instance within 10–15 minutes.

Data protection and encryption standards

Encryption in transit

  • External to Cloud: All communications require TLS 1.2 or TLS 1.3 over Port 443. Legacy SSL (2.0/3.0) and deprecated TLS (1.0/1.1) protocols and weak ciphers are disabled.
  • Mutual TLS (mTLS): Enforced on all external machine-to-cloud connections, ensuring bidirectional cryptographic proof of identity.
  • Internal transit: Traffic between the ECS client router, the internal ALB, and the tenant EC2 instance is encrypted with HTTPS over private AWS networking. Client certificates are validated only at the device-entrypoint ALB, not at internal hops.

Encryption at rest

Tenant data stored in Amazon Elastic File System (Amazon EFS) and Amazon Relational Database Service (Amazon RDS) is encrypted at rest using AES-256-GCM with AWS Key Management Service (AWS KMS) keys.

Secrets management

Service credentials that allow platform components to communicate with a tenant instance are stored in tenant-specific secrets in AWS Secrets Manager. Each secret is created when the tenant is provisioned, and the application key is rotated automatically on every platform upgrade.

Data processed by the platform

The tenant instance stores and processes:

  • Policy definitions
  • Event logs from Linux and Unix hosts
  • I/O logs (session recordings of command input and output), when I/O logging is turned on in policy
  • Host details such as host name

Policy caching on hosts uses REST requests to download policies and to forward cached event logs and I/O logs to the tenant instance. I/O logs can contain sensitive command output, so customers should review their I/O logging policies.

Customer network and firewall impact

  • Outbound-Only Connectivity: Linux endpoints require only outbound HTTPS connections on Port 443 to the regional SaaS server entrypoint.
  • No Inbound Ports: No inbound listening ports are opened on customer network firewalls or on individual Linux servers.
  • Proxy Support: Standard enterprise forward proxies are supported, provided they allow TLS-passthrough (to permit the end-to-end mTLS handshake between the endpoint and the ALB).

Operational access and security monitoring

BeyondTrust operational access

  • BeyondTrust operations, engineering, and support personnel do not have default access to customer instances or policy data.
  • Back-office access for maintenance or troubleshooting is strictly restricted to authorized staff using BeyondTrust Privileged Remote Access (PRA).
  • All administrative sessions require hardware-backed, phishing-resistant Multi-Factor Authentication (MFA), role-based approval tickets, and complete session video/keystroke recordings retained for a minimum of 90 days.

Security monitoring and vulnerability management

  • Vulnerability Scanning: Container images, infrastructure templates, and virtual machine base images are scanned continuously for vulnerabilities in CI/CD pipelines and production environments.
  • Infrastructure Auditing: CloudTrail, VPC Flow Logs, and ALB access logs are aggregated into BeyondTrust’s central Security Information and Event Management (SIEM) system.
  • Threat Detection: Monitored 24/7 by the BeyondTrust Security Operations Center (SOC) with automated anomaly detection and incident response procedures.
  • Third-Party Penetration Testing: The EPM-L SaaS platform undergoes annual third-party penetration testing conducted by independent external security firms. Testing covers ingress load balancers, client routing services, administrative web consoles, and tenant isolation controls. All findings are prioritized for remediation according to strict SLA guidelines, followed by formal re-testing. Executive summary reports are available to customers under NDA upon request.

Health monitoring

Each tenant instance has a health endpoint that reports metrics in Prometheus format. BeyondTrust Cloud Operations uses it to monitor the EPM-L environment.

Logging

EPM-L application logs are forwarded to Datadog. Datadog monitors and alerts are in place to monitor and troubleshoot issues. Logs are available for 15 days and they are automatically purged.

Event forwarding to customer SIEM

Customers can forward EPM-L events to their own Elasticsearch or Splunk server by configuring event forwarding from the web console.


©2003-2026 BeyondTrust Corporation. All Rights Reserved. Other trademarks identified on this page are owned by their respective owners. BeyondTrust is not a chartered bank or trust company, or depository institution. It is not authorized to accept deposits or trust accounts and is not licensed or regulated by any state or federal banking authority.