ElevateIQ overview
ElevateIQ is an endpoint privilege management (EPM) platform. It removes standing local-administrator rights from end users, then hands admin power back in small, audited, time-boxed pieces, only when a request justifies it.
Why remove standing admin?
A user who is always an administrator is an open door: every phishing payload, every drive-by installer and every macro runs with the same rights the user carries. Most ransomware playbooks assume it. With ElevateIQ, users stay standard. When something genuinely needs admin, the request is captured, scored, decided and logged, and the elevation expires on its own.
The pieces
| Component | What it does |
|---|---|
| Windows agent | A signed service plus a tray app on each endpoint. Catches elevation attempts, shows the request form, enforces decisions, inventories the device and ships tamper-evident logs. |
| macOS agent | A notarized launchd daemon plus a menu-bar app. Grants time-boxed admin group membership with crash-safe revocation, and hosts the execution monitor used by allowlisting. |
| Admin console | The web app at app.elevateiq.me: request queues, rules, devices, USB control, reports, policy settings and audit logs. |
| Approver app (iOS) | Push notification per pending request; approve or deny with the same scope controls as the web console. |
| Cloud API | The decision authority. Evaluates rules, signs approvals, scores requests, stores the audit trail. Agents authenticate with per-device certificates. |
Life of an elevation request
- A standard user launches something that needs admin. The agent intercepts it and collects the binary's full identity: hash, publisher certificate, version resources, launch context.
- The rule engine runs first. A matching rule can auto-elevate silently, require MFA, block outright, or let the request continue to review.
- If review is needed, the user adds a justification and the request lands in the admin queue. Approvers see it on the web and as an iOS push, alongside its confidence score and risk signals.
- An approver decides, picking a scope (below) and optional constraints such as an allowed command line or working directory.
- The approval is signed by the server (ECDSA). The agent verifies the signature and elevates using the chosen execution mode. When the window ends, the elevation is gone.
Execution modes
How the approved binary actually runs, chosen per rule or per approval:
| Mode | Meaning |
|---|---|
| admin | Runs under a managed local admin account that is hidden from logon screens and rotated per use. The default, and the industry norm. |
| user | Runs under the user's own token with admin privileges attached, so per-user settings and profile paths behave normally. |
| system | Runs under a SYSTEM-derived token. For machine-wide installers that misbehave under any user context. |
Approval scopes
| Scope | Meaning |
|---|---|
| one_time | This launch only. |
| session | Repeated launches until the user's session ends, without re-prompting. |
| machine | This binary on this device, going forward. |
| client | The binary across one client's fleet (MSP tier). Requires an expiry date. |
| global | Tenant-wide. Deliberately heavy: requires a second approver, a change ticket and a review date. |
Security model in one paragraph
Devices authenticate with per-device certificates (mTLS identity). Approvals are ECDSA-signed server-side and verified by the agent, so a tampered console session or intercepted response cannot mint an elevation. The rule bundle agents cache locally is signed the same way and is advisory for UX only: the server re-evaluates every request. Unsigned or invalid-signature binaries are blocked by a global signature gate unless a rule with a cryptographic anchor explicitly bypasses it. Everything lands in a hash-chained audit log.