Note: Blueprint Compliance is currently available for Architect customers.
Use Blueprint Compliance when you need provable compliance, faster troubleshooting, or audit-ready evidence that your fleet policies are actually enforced.
Use Blueprint Compliance and Drift Audit when you need provable compliance, faster troubleshooting, or audit-ready evidence that your fleet policies are actually enforced.
In this article:
- How Drift Detection Works
- Drift Severity Levels
- Configuring Blueprint Compliance in a Blueprint
- Viewing Drift on a Device
- Why a Device Might Be Compliant Despite an App Count Mismatch
- Tips for Using Blueprint Drift
How Drift Detection Works
Without Blueprint Compliance, the Esper console marks a device as "in drift" only when its blueprint ID no longer matches the one assigned in the console. A device can pass that check and still have an outdated app version, an altered Wi-Fi profile, or a silently changed policy.
Blueprint Compliance inspects the device at the field level. It compares the live state of every supported blueprint attribute against the expected value and surfaces any deviation — including its severity and the exact value that changed.
Drift Severity Levels
Every drift-aware blueprint attribute is assigned a severity level. The Esper Console uses the same three levels in status indicators, filters, and notifications.
The user selects these drift levels while creating or updating a blueprint.
| Severity | Description |
|---|---|
| Critical | A security- or compliance-sensitive deviation that requires immediate remediation. Examples: encryption disabled, required VPN profile removed. |
| Major | A meaningful deviation that affects fleet behavior or device user experience. Examples: wrong app version installed, missing Wi-Fi profile. |
| Minor | A low-impact deviation worth tracking but not urgent. Example: a cosmetic setting change. |
| Log Only | The setting is logged only. Examples: Changes not applicable to the use case or changes that device users control. |
| Coming Soon / Not available | A setting that’s not currently available for drift detection. |
Configuring Blueprint Compliance in a Blueprint
Blueprint Compliance is enabled per blueprint, so you can turn it on for specific fleets without a fleet-wide commitment.
Step 1: In the Esper Console, navigate to Blueprint Manager and create or edit the blueprint you want to configure. Then, enable the Blueprint Drift toggle.
Step 2: Locate the Blueprint Compliance toggle next to the applicable setting. It is located next to the Apply setting.
Step 3: Once enabled, a Drift Detection setting appears on each supported attribute. Select the severity level — Critical, Major, Minor— that a deviation from that attribute should raise.
Save, publish, and converge the blueprint. It may take a moment for the devices to reflect the blueprint drift settings.
Viewing Drift on a Device
The Blueprint Drift Audit tab on a device detail page shows every attribute that has drifted from the assigned blueprint, along with the severity, the current value, and the expected value.
To reach the Drift Analysis tab:
Step 1: In the Esper Console, navigate to Devices and select the device you want to inspect.
Step 2: Click on the Blueprint Drift Audit tab.
Step 3: Review the list of drifted attributes. Each entry shows the attribute name, severity level, current value on the device, and expected value from the blueprint.
Step 4: To bring the device back into compliance, click Converge on the device detail page. Converge applies the blueprint and resolves the listed deviations.
Tip: You can also trigger convergence in bulk from the Devices list. Use drift status filters to identify affected devices, then select them and choose Converge from the actions menu.
Drift application modal
If you marked installed applications for drift, you’ll see the application count in the Drift Audit Summary.
Click on the app count to see detailed information about the applications and versions on the device.
Application counts can differ depending on applications added outside of the device list. The Google Play Store, for example, may be added outside of the device list. See the Why a Device Might Be Compliant Despite an App Count Mismatch section of this article to understand how specific applications can affect application counts on a device.
Why a Device Might Be Compliant Despite an App Count Mismatch
A device can show as compliant in Blueprint Compliance even when the number of visible apps on the device doesn't match what you expect from the blueprint's app list. This happens because a handful of packages are added to the device outside the blueprint's app configuration, so Blueprint Compliance doesn't treat them as drift.
OS packages un-suspended by a blueprint setting
Enabling certain Blueprint settings un-suspends OS packages that ship with the device, moving them from a hidden state to the show state. This adds them to the visible app count, but the change is expected and doesn't indicate drift.
- com.google.android.googlequicksearchbox — Google Assistant (via Allow Google Assistant)
- com.google.android.apps.assistant — Google Assistant (alternate package on some OEMs)
- com.android.settings — Android Settings App (via Android Settings App)
Esper-owned companion apps
The following packages are Esper-owned companion apps installed to support device management. This set mirrors the DPC's getEsperPackages() and getInternalPackages(), and Blueprint Compliance excludes them from app count drift.
Exact package names:
- io.shoonya.shoonyadpc — Esper Settings / DPC (via Allow Esper Settings App)
- io.shoonya.helper — Esper Helper companion app
- io.esper.remoteviewer — Remote Viewer companion app
- io.esper.tesseract — Tesseract companion app
- io.esper.plugin.supervisor — Generic Supervisor companion app
- com.shoonyaos.oculus.plugin.supervisor — Default Oculus Supervisor variant
Package prefixes (per-device variants carry a device-model suffix):
- com.shoonyaos.oculus.plugin.supervisor.* — legacy per-device supervisor (for example, ...supervisor.pixel7)
- io.esper.supervisorshell.* — per-device supervisor shell (for example, io.esper.supervisorshell.pixel7)
Tips for Using Blueprint Drift
You might notice that devices occasionally report drift despite having all Compliant settings. This can be for the following reasons:
- The blueprint was updated and the device hasn’t converged to the latest version.
- A region-locked application is included in the blueprint but couldn’t be installed on the device.
Use the device’s Event Feed to check for error messages and ensure the device has checked in recently to resolve drift.
Use drift status filters in the Devices view and the Drift Analysis tab to triage deviations. Converge devices individually or in bulk to bring them back to the blueprint-defined state.