Security and privacy

For tenant admins, auditors, security reviewers and data protection officers.

AdminExplorer is built on one principle: no user is ever a local administrator, and no standing admin account is created. Elevation is granted per program, decided on the device, and audited. The Security model overview guide has the full component table and the architecture diagram; this page summarises it and collects the privacy and retention facts in one place.

On the device

• One decision point. The AdminExplorer service (LocalSystem) makes every decision from the policy and the license. The tray app and the right-click menu only ask; they never hold elevation code.
• The caller is identified by Windows, not by what the request says: user, session and integrity level. Remote, low-integrity and app container callers are refused.
• The file is checked once and locked. It is opened once, checked on that open handle (local fixed drive, no links, junctions or network paths) and cannot be changed until the program has started.
• Only that program is elevated, in the user’s own session and under the user’s own identity. Child programs are not elevated unless you allow it per entry or rule (Enterprise).
• The kernel driver catches starts of pre-approved programs, lets only the installed service create elevated tokens and governs child processes. Its device is open to SYSTEM only. The driver is attested and signed by Microsoft.
• “Any application on demand” requires the person at the keyboard to confirm on a secure desktop that only SYSTEM can open, and never elevates a file the user controls. See Any application on demand.
• Fail safe. A malformed setting falls back to its safe default; an invalid policy or license from the portal is refused as a whole and the previous one stays; a device without a valid license elevates nothing.
• Group Policy wins. Values set under the AdminExplorer Policies key always win over the portal.

Between the device and the portal

• The device connects out to the portal over HTTPS (TLS 1.2 or 1.3) with server certificate validation and never follows redirects. The portal never connects to the device.
• A device enrolls once with the enrollment key from your bundle, then uses its own device token (1 hour) and a rotating refresh token. They are stored under a registry key only SYSTEM and Administrators can read. A revoked device stops working at its next call.
• Licenses are signed by the portal and verified on the device.
• What the device sends is listed field by field in Data collected by the device.

Signing in to the portal

• No passwords are stored. Admins sign in with a work account (Microsoft, Google or Okta, as offered) or a one-time email link, and are matched to a portal user by their verified email address.
• The portal keeps no identity provider tokens. Sessions are held in the browser’s memory with a protected refresh cookie, last at most 12 hours and end after 60 minutes without use.
• Roles limit what each person can do: tenant admin, approver, auditor (and partner admins for partners).
• You can connect your own Microsoft Entra directory and require Entra sign-in, so assignment and Conditional Access in your directory decide who signs in: Microsoft Entra sign-in. You can also use your own app registration, authenticated with a certificate whose private key never leaves the portal’s key vault.

Hosting

• The portal API and all portal data are hosted in Microsoft Azure, region Sweden Central.
• The portal web app and this documentation site are static content served globally by Azure Static Web Apps.
• Publisher: Circle of Bytes ApS.

What the portal stores

Data	Purpose
Tenant, users and roles	Sign-in and access
Policy	What devices may elevate (one current version per tenant)
Devices	Hostname, machine id (a hash), last seen, reported license and policy, agent version, sandbox capability
Audit records	Evidence of every elevation attempt, sandbox run and local administrator removal
Approval requests	Manual approval
Installed software	Current inventory per device and the change history
Local administrator state	Members of the protected local groups (SID, name, type, status), findings and history
Entra group membership copy	Group targeting: object id, user principal name, on-premises SID, group ids
Download bundles	Your configured installer

Retention

Data	Kept
Audit records	400 days
Approval requests	90 days
Software change history	400 days
Current software inventory of a device	Until the device is revoked or tracking is turned off
Local administrator history	400 days
Current local administrator state of a device	Until the device is revoked or its mode becomes Off
Expired local administrator exceptions	Leave the list 30 days after they expire
Entra group membership copy	Until group targeting is turned off, Directory Sync is disconnected, the consent is revoked or the tenant is deleted
Address a re-installed machine enrolled from	While its re-enrollment waits for approval, at most 7 days
Devices, policy, users, bundles	Until removed, revoked, replaced or the tenant is deleted
Portal sessions	At most 12 hours; 60 minutes without use
Unconverted trials	Deleted 90 days after the trial license ends, unless a device still checks in
Records waiting on the device	Until sent; at most 50 MB or 10,000 records, oldest first out
Device event log	As configured in Windows on the device

Data deletion

Action	Effect
Revoke a device	Its tokens stop working and its current software inventory and local administrator state are deleted. Its audit records and histories remain as evidence until they expire.
Turn off installed software tracking	Collection stops and every current inventory of the tenant is deleted at once. The change history stays until it expires.
Turn off Entra group targeting, or disconnect Directory Sync	The membership copy is deleted at once.
Stop using your own app registration	The portal deletes its certificates (or the stored secret), the sign-in link and the memberships read through your app.
Delete the tenant	Every record of the tenant (devices, policy, licenses, audit, approvals, software, local administrator data, bundles) is deleted, and users who belong only to this tenant are removed.
Uninstall the client (msiexec /x)	The settings are removed from the device (unless KEEPCONFIG=1), and records that were not sent yet are lost.

What AdminExplorer does not collect

• Passwords or other credentials of your users.
• File contents, documents, screenshots or keystrokes.
• Browsing or application usage data.

Questions about security or data protection go to your provider or to Circle of Bytes.