Devices and groups
/api/v1/devicesReview inventory, ownership, groups, certificates, and enrollment state.
Enklave
BetaEnklave gives IT and security teams one governed control plane for enrolling devices, applying policy, deploying applications and patches, monitoring compliance, and responding to endpoint incidents across major operating systems.
Beta operating manual
Enklave beta operator manual
Enroll devices, apply intent-based policy, stage applications and patches, review posture, and control remediation through the Enklave UEM beta.
Audience, scope, and prerequisites
Covers approved beta operator workflows for device inventory, enrollment tokens, policy intent, drift, staged application/patch rollout, incidents, remediation, approvals, and posture. The verified source contains backend services but no reviewable end-user frontend, so interface labels are deployment-specific.
Who this is for
- Authorized endpoint administrators
- Security and incident responders
- Enklave auditors and support
Before you sign in
- An approved UEM role in the correct tenant
- A device-ownership and enrollment authority
- Test devices and rollout rings
- Maintenance, incident, and emergency-access procedures
Roles and responsibilities
| Role | Access | Responsibilities |
|---|---|---|
| Inventory operator | Manage assigned device inventory, groups, enrollment, and certificates. |
|
| Policy or deployment operator | Prepare policy, application, patch, and model assignments. |
|
| Security responder or approver | Review incidents, evidence, remediation, audit, and controlled approvals. |
|
Enroll and govern devices
Bind every enrollment to an approved owner, platform, tenant, and lifecycle state before assigning policy.
Enroll a device
Create a bounded token and verify the resulting device identity and certificate.
- 1Approve the device
Confirm owner, tenant, platform, asset record, and supported enrollment method.
- 2Create a bounded token
Set the shortest useful expiry and usage count and restrict distribution.
- 3Enroll from the intended device
Use the platform-specific approved flow and verify server identity.
- 4Review inventory
Confirm stable device identity, owner, OS, serial or hardware identity, certificates, and first posture state.
- 5Revoke unused material
Revoke the token after use and any unexpected certificate or duplicate enrollment.
Expected result
One authorized device appears in the correct tenant with traceable ownership, certificate, and posture state.
Publish and assign a policy intent
Version policy, test compilation, and assign it to the smallest device group.
- 1Define the security intent
State required posture, supported platforms, exceptions, and remediation boundaries.
- 2Create a draft version
Use a new version rather than silently changing deployed intent.
- 3Review compiled output
Check platform-specific controls and unsupported settings.
- 4Assign to a test group
Use representative devices and explicit rollback criteria.
- 5Publish and monitor
Review compliance, drift, device health, and user impact before expanding.
Expected result
A versioned policy is assigned first to a bounded test group and its compliance impact is understood.
Stage changes and respond safely
Remote deployments and remediation can disrupt or erase endpoint state; use rings, maintenance windows, approvals, and evidence.
Run a staged application or patch rollout
Progress from test rings only when health and rollback conditions are satisfied.
- 1Approve artifact and scope
Verify package source, signature, version, platforms, device groups, and change record.
- 2Set maintenance behavior
Choose the approved window, restart policy, user notice, and failure threshold.
- 3Start ring 0
Deploy to internal test devices and monitor install, posture, performance, and application health.
- 4Review the gate
Compare success, failure, rollback, and incident signals with acceptance criteria.
- 5Promote one ring at a time
Pause immediately when thresholds or unexpected impact are reached.
- 6Close with evidence
Record final coverage, failures, exceptions, and rollback state.
Expected result
The approved artifact reaches only accepted rings and every failure or exception has a traceable disposition.
Review and remediate policy drift
Distinguish stale telemetry, approved exception, and real noncompliance before remediation.
- 1Open the drift record
Confirm device identity, policy version, observation time, and severity.
- 2Check current posture
Determine whether the device has reported since the drift event.
- 3Review exceptions
Confirm whether an approved time-bounded exception applies.
- 4Choose acknowledge or remediate
Acknowledge only with owner and reason; remediate only within the approved playbook.
- 5Verify outcome
Wait for new posture and preserve action and device evidence.
Expected result
The drift has an accountable disposition and verified post-action state.
Approve a remote incident remediation
Review scope and possible data or availability impact before remote action.
- 1Open the incident
Verify device, owner, tenant, severity, evidence, and containment need.
- 2Select an approved playbook
Review each action, required connectivity, and rollback or recovery path.
- 3Assess impact
Identify data loss, isolation, restart, credential, user, and legal consequences.
- 4Obtain approval
Use the audit approval workflow for consequential actions.
- 5Execute and monitor
Run once and watch command, device, and telemetry state.
- 6Preserve evidence
Record before/after posture, command results, failures, and follow-up.
Expected result
A justified, approved remediation runs against the intended device and produces auditable outcome evidence.
Security and data handling
- Treat enrollment tokens, certificates, packages, models, and remote-action authority as privileged credentials.
- Use test devices and staged rollout rings.
- Require approval for consequential remediation and policy expansion.
- Verify tenant and device identity before every remote action.
- Preserve audit, posture, command, and incident evidence without copying secrets.
Known limitations
Read before relying on an unsupported workflow
These limits describe the source-pinned Enklave beta source release eee705d scope and must be rechecked when the product changes.
- The verified repository contains backend microservices and no reviewable end-user frontend.
- Platform-specific enrollment, policy, application, patch, and command support varies across iOS, macOS, Android, Windows, and Linux.
- Telemetry can be delayed or absent when devices are offline.
- Intent compilation and AI-model distribution require separate platform validation.
- An API success response does not prove a device applied or retained the requested state.
Troubleshooting
You cannot sign in to Enklave
Likely cause: The session expired, the identity is not assigned to the application, or the tenant claim is missing.
- Open the application from the approved portal and complete sign-in again.
- Confirm that the correct organizational identity and tenant are selected.
- If access is still denied, record the time and request an entitlement check from support.
A documented action or navigation item is not visible
Likely cause: The current role, release, tenant configuration, or feature flag does not expose that operation.
- Confirm the role and prerequisites listed for the procedure.
- Reload the page after signing in again; do not attempt to bypass the interface through direct URLs.
- Ask the product owner whether the feature is enabled for the tenant before reporting a defect.
A saved change or background operation is not visible
Likely cause: Validation failed, processing is still running, or the current view is stale or filtered.
- Review inline validation, status indicators, filters, and the selected tenant or workspace.
- Refresh once and search for the item by its stable name or identifier.
- Do not repeat irreversible or externally visible actions until the original operation status is known.
A device does not enroll or report posture
Likely cause: Token, certificate, platform service, tenant, connectivity, or device identity is invalid.
- Confirm token state without exposing it.
- Verify platform support, tenant, device time, connectivity, and certificate result.
- Revoke uncertain enrollment material before creating a replacement.
A rollout or remediation remains pending
Likely cause: The device is offline, ring/window gate is closed, command delivery failed, or approval is missing.
- Review device last-seen and current posture.
- Check ring, window, approval, and command-result state.
- Do not issue duplicate remote actions until the original disposition is known.
Contact support
Contact support when
- A repeatable Enklave error blocks an approved workflow
- Expected data, permissions, or tenant boundaries appear incorrect
- A security, privacy, compliance, or data-loss concern is suspected
- A token, certificate, package, or remote-action credential may be exposed
- A remote action targets the wrong device or tenant
- A rollout, policy, or remediation causes widespread impact
Include
- The page, action, and expected result
- The exact error text and time of occurrence, including time zone
- Your tenant, role, browser, and a sanitized record or item identifier
- Whether the problem can be reproduced and which troubleshooting steps were tried
Never include
- Passwords, access tokens, API keys, recovery codes, or session cookies
- Unredacted personal, health, financial, or other regulated data
- Private encryption keys or complete confidential documents unless an approved channel is provided