Give users the access they need, only when they need it
Local administrator rights are one of the most common ways an incident gets worse than it needed to be a phishing payload that would have stalled at a UAC prompt instead runs with full privileges, or a well-meaning user installs something that opens a door nobody meant to open. The usual fix is stripping local admin rights entirely which breaks legitimate work: installers that need elevation, IT scripts, one-off admin tasks. Syteca Privilege Elevation controls when and how administrator privileges are used on Windows endpoints, without requiring you to choose between security and productivity. It replaces the native Windows UAC prompt with a Syteca policy check, and applies one of three actions to every elevation attempt: Auto-elevate, Require approval, or Deny. Every decision is logged.Use this when you need to:
- Run a “remove local admin” initiative without blocking the work that depends on elevated access.
- Reduce the risk of malware and unapproved installers running with administrator privileges.
- Meet least-privilege, change-approval, and auditability requirements found in common security frameworks (for example CIS benchmarks and ISO 27001).
- Grant temporary, approved, time-boxed administrator access instead of leaving users permanently in the local Administrators group.
How it works, in short
1
Create a rule
Define what triggers the rule (an application by hash, name, path, publisher, or command line), which endpoints and users it applies to, and what should happen when it matches: Auto-elevate, Require approval, or Deny.
2
Syteca intercepts the elevation attempt
When a user tries to run something as administrator, the Syteca Client intercepts the UAC flow before it completes and evaluates your rules against it. Instead of the native Windows dialog, the user sees a Syteca-controlled experience matching your rule’s action.
3
The decision is enforced, and logged
The application runs immediately (Auto-elevate), waits for an administrator’s decision (Require approval), or never runs (Deny). Every attempt whether it is approved, denied, or automatic will be recorded on the Events tab.
Privilege Elevation does not remove users from the local Administrators group. It intercepts and governs how elevation happens, without changing group membership.
Supported platforms
- Windows 10 (Pro, Enterprise, LTSC/LTSB)
- Windows 11 (Pro, Enterprise, LTSC/LTSB)
- Windows Server 2012 (R2)
- Windows Server 2016
- Windows Server 2019
- Windows Server 2022
- Windows Server 2025
.NET Framework 4.6.2 or higher is required on any platform where the default installed .NET version is lower.
Licensing
Privilege Elevation is licensed independently from Password Management (PAM) and PAM Seats. You can have a Privilege Elevation license without buying either.-
Privilege Elevation is a toggle on the Endpoint License, enabled by default when a new license is generated. A sub-toggle, Privilege Elevation Monitoring, controls session recording during elevation and is disabled by default.
If Session Monitoring is already enabled on the same Endpoint License, Privilege Elevation Monitoring shows as unavailable with the note “Already included” — you don’t need to enable it separately.
-
Enabling Privilege Elevation doesn’t allocate PAM or PAM Seat licenses on its own. However, since rules use a Secret to perform elevation, the system automatically provisions 1 PAM application toggle and 1 PAM Seat license behind the scenes the first time a license with Privilege Elevation (but no PAM) is activated — purely so Privilege Elevation has something to work with. These service licenses aren’t shown as allocated in the License Portal, and don’t count against your visible PAM Seat total.
When a license containing only Privilege Elevation (no PAM or PAM Seat) is activated or updated, the Management Tool shows: “To support Privilege Elevation, a PAM Application and/or a PAM Seat License have been automatically provisioned by the system.”If you already have active or purchased PAM Seat licenses, this automatic provisioning is skipped — your PAM Seat count doesn’t change.
- Toggling the license off and on preserves your rules. If the Privilege Elevation license is disabled, existing rules stay in the database but stop being enforced, and the Privilege Elevation page becomes inaccessible. Re-enabling the license reactivates every previously configured rule without requiring you to rebuild them.
Permissions
A dedicated Privilege Elevation administrative permission controls access to the feature, available on the Add/Edit User (User Group) page only when a license with Privilege Elevation is active.- Enabled by default for the built-in admin user and the Administrators group.
- A PAM Seat license is not required to access the Privilege Elevation page, or to select a Secret when configuring a rule.
- A user only sees Secrets that are explicitly shared with them, and can reference a Secret in a rule with just PAM User permission on it — they don’t need a PAM Seat to reference it, only to use it directly for something else (like connecting through it).
What’s in this section
Creating and managing rules
Build a rule: elevation mode, targeting criteria, endpoints, users, and notifications.
Events and monitoring
The audit trail of every elevation attempt, and how session recording works.
End-user experience
What a user sees at the moment of elevation, and how to check on a pending request.
Related
Secrets & Password Management
The credentials Privilege Elevation rules use to perform elevation.
Assign PAM seat licenses
How PAM Seats are allocated, including the ones auto-provisioned for Privilege Elevation.