About the EPM Windows Architecture

EPM Windows is composed of the following:

• A centralized administration module on the Segura platform.
• An agent installed on the user's workstation.

There are three available applications in the custom installation process for the agent:

• Core
• Automation
• Vault

Services

Windows services

• The LOCAL_SYSTEM user can automatically execute the services.
• The Microsoft Isolated Storage securely stores sensitive data, following the standards of Microsoft.
• Data transferred between the Segura platform and EPM Windows occurs through HTTP connection and API REST. This communication occurs within the EPM services to prevent capture by logged-in users.
• Exchanged messages have additional asynchronous encryption with a random key.

go Service

It's responsible for any interaction that occurs in the system, as:

• IDS (Intrusion Detection System) service to block applications executed outside of EPM Windows.
• IDS service to block applications that communicate via TCP/IP and UDP to destinations other than the password vault.
• Possibility of identifying applications that are automatically elevating privilege without the user's knowledge or consent.
• Processing the license file and machine registration on the server, log synchronization, and folder and file monitoring.
• Prevention of workstation cloning attempts to misuse EPM Windows by a workstation or ghost user.
• Prevention of horizontal jumping through network sharing or unauthorized binary access to network resources.
• Interconnection service responsible for synchronizing any EPM Windows settings.
• Interconnection service with Windows Kernel for privilege elevation and session control.
• Recording program (Recorder).

Other integrations

EPM Windows integrates with DLLs and drivers that allow it to take action in Windows processes that involve user identification, such as:

• Login
• RDP Access
• UAC Elevation

Kernel driver — process interception

The EPM Windows kernel driver intercepts every process creation request on the workstation before any process code runs. This mechanism uses the PsSetCreateProcessNotifyRoutineEx Windows kernel notification routine.

How it works

1. The driver loads at system boot or when the EPM Windows service starts.
2. When any process creation request is made — regardless of origin (user, system, script, or child process) — the driver intercepts it before execution begins.
3. The driver notifies the EPM Windows service, which evaluates the request against the active access policies.
4. Based on the evaluation result:
   • If permitted, the driver releases the process creation.
   • If blocked, the driver cancels the creation before any code runs and returns a blocked status to the operating system.
5. The EPM Windows service generates a Process Blocked event and sends it to Segura® for audit.

Security and compliance

• The driver is digitally signed and meets Microsoft driver signing requirements.
• Access controls and input validation follow Microsoft secure driver development practices.
• The driver is protected against tampering attempts.
• Blocked events are logged in real time with full context for audit.