Most teams that adopt AI coding agents already have a device management gap next to their agent visibility gap: the laptops running Claude Code, Cursor, or Codex need a baseline too, and until now that baseline lived in a different tool entirely. Beam MDM closes that gap inside the same workspace — enroll Apple and Windows devices, push their configuration, and follow device operations next to the agent activity already running on them. See the Beam MDM product page for the full walkthrough.
What's new
| Question | Answer |
|---|---|
| What does it manage? | Apple (macOS, iOS, iPadOS) and Windows devices — enrollment, configuration profiles, inventory, and remote operations |
| Is it a separate product? | No — it's a second, independent setup path in the same Beam workspace as agent monitoring |
| Do I need to self-host anything? | Not on Beam-hosted plans. Beam hosts the backend services; self-hosted operators can run the same stack from the published runbook |
| Does selecting it enroll devices automatically? | No. Selecting device management only makes the setup path available; enrollment is a deliberate step |
| Can I use my existing Intune tenant? | Yes, as a connection option — inventory and compliance review, with enrollment staying in Intune |
| Are lock and wipe on by default? | No. Remote actions require administrator access, device confirmation, and password verification, and are enabled per device |
Why device management belongs next to agent monitoring
Beam's agent runtime security already answers "what did the agent do on this machine." Beam MDM answers the question that usually sits with a different team entirely: "what state is this machine in, and did our configuration actually reach it." Our enterprise AI coding agent rollout checklist already calls out an MDM baseline — approved clients, pinned versions, pushed hook or config templates — as a prerequisite for rolling agents out org-wide. Beam MDM means that baseline and the agent activity it's supposed to constrain can now live in one workspace instead of two disconnected consoles.
That also matters for the audit trail teams increasingly need to produce. Our compliance audit trail work and the EU AI Act coverage for coding agents both point at the same requirement: evidence that has to hold up in a review, not just a dashboard that looks reassuring in the moment. A device enrollment record and an operation history sitting next to agent event logs make that evidence easier to assemble, not because Beam MDM certifies compliance on its own, but because the two records now share a workspace and a timeline.
Who can see and do what
Access has two layers, and both must allow it. First, MDM is in beta and requires an explicit feature grant for the workspace and a configured provider; a workspace role alone does not turn it on, and owners and administrators can request access from Setup. Second, the user's role decides what they can do. Owners and administrators operate: they enroll, deploy profiles and request actions. Security managers and auditors get read-only access. Members and billing-only roles have no MDM access. Switching workspaces matters, because a role in one workspace does not carry into another.
Three connection options
The device management area offers three connections, and they are not interchangeable:
| Connection | Use it for | What it needs |
|---|---|---|
| Fleet through Beam | Apple and Windows inventory, enrollment, installers, profiles and available provider actions | An isolated Fleet instance for the workspace, platform enrollment identities and published installers |
| Beam device response | Lock and wipe through a separately provisioned channel | NanoMDM for Apple or a signed Windows worker, plus a verified Fleet inventory binding |
| Microsoft Intune | Reading existing inventory, compliance and encryption, with optional sync | An existing licensed Intune tenant and server-side Graph credentials |
If native Fleet management and Intune are both configured, the native connection takes precedence in the dashboard. Beam does not merge them into one deduplicated inventory. Fleet's capabilities and licensing are separate from a Beam subscription.
How enrollment and configuration work
Enrollment follows each platform's own mechanism rather than a generic agent installed on top:
- Apple — enrollment profiles and configuration profiles are deployed using Apple's management protocols. Manual enrollment works out of the box; Apple Business Manager can be configured for automated enrollment. Available controls depend on OS version, supervision state, and enrollment type.
- Windows — a signed installer establishes enrollment, and Windows configuration files carry settings to the device. The inventory view shows last check-in time and whether pushed settings have actually landed, not just whether they were sent.
Apple: the push certificate is the part to track
Apple management depends on the Apple Push Notification service (APNs). Beam's native path uses the workspace's Fleet engine, which needs an APNs certificate and the engine's SCEP identity; automated company-device enrollment additionally needs Apple Business Manager configured in the engine. Owners and administrators can complete the certificate flow from Enrollment & installers: download a certificate request, sign in to Apple's Push Certificates Portal with the Apple account responsible for the organisation's certificate, then upload the returned .pem. Only the certificate is uploaded; the enrollment keys stay on the server.
Fleet's own documentation explains why the account matters. Fleet's Apple MDM setup guide says Apple requires APNs certificates to be renewed annually; that if a certificate expires you must turn MDM off and back on for all Apple hosts; and that, in the meantime, profile changes and other commands stay stuck in "Pending". It also says to renew with the same Apple ID each year and to choose the certificate whose Common Name matches the one Fleet shows, or the same turn-off-and-on is needed. It recommends a shared Apple account for the certificate so renewal does not depend on one employee. Beam's docs add that an expiry indicator is not a renewal service or a notification system, and that automatic renewal alerts are not provided, so track the renewal date outside Beam.
Beam's guidance on the enrollment profile is also practical. It is not a single-use invitation, so deliver it through a private channel and keep copies limited to the intended device operators. A desktop inventory agent alone does not establish Apple MDM enrollment. For background on what a profile can configure and how enrollment types differ, see Apple's Platform Deployment documentation on device management profiles.
Windows: installer, identity and a signed-in user
Windows needs both server-side setup and an endpoint install. The operator configures Fleet's Windows MDM certificate and private key (the WSTEP identity) and backs them up; replacing the pair can affect access to previously escrowed BitLocker recovery material in the provider. Then a signed MSI for the correct workspace is published. The docs state that the source repository contains build scripts, not pre-signed release packages, and that a valid service connection does not generate or sign an MSI. A missing download usually means no installer has been published for that workspace.
On a test endpoint, check the package's Authenticode publisher using your normal deployment process, install as an administrator, and sign in as a Windows user, which enrollment requires to complete. Then confirm identity, enrollment, OS and recent check-in in the inventory.
Reading the inventory without over-reading it
The inventory shows device name and OS version, whether the engine reports enrollment, the provider's encryption report, and last-seen time in UTC. Each field has a caveat the docs spell out. Enrollment means the engine reports management enrollment, not just that a record exists. An unknown encryption state is not evidence either way, and an encryption flag does not mean a FileVault or BitLocker recovery key has been escrowed in Beam; the recovery-key escrow screen is not available. Native inventory comes in pages of up to 100 records, so counts such as "Devices on this page" refer to that page only. Do not use a hostname as proof of identity.
Configuration profiles are group operations
Beam accepts Apple .mobileconfig and Windows .xml profiles up to 500 KB through Configuration profiles. The important detail is the target: profiles created here apply to matching Apple or Windows devices in the Fleet engine's Unassigned group. Existing Fleet groups keep their own profiles, and Beam provides no group-targeting editor or per-device picker for this workflow. Uploading a profile is therefore a group operation, and removing one removes the settings it enforces from assigned devices. Validate in a test workspace first.
After you submit, record the operation ID and check Operation history. A provider's acceptance only shows it accepted the request; devices apply settings when they check in. Beam does not inspect every operating-system effect of an arbitrary profile, and the listing may show only the first 100 profiles.
Both platforms report into one inventory, so a mixed Apple/Windows fleet shows up as a single list rather than two systems a reviewer has to reconcile by hand.
This closes one half of a gap explainx.ai covers from the other side in MDM isn't enough anymore: managing AI agents on company devices — traditional MDM answers "is this device compliant," not "what is the agent running on it actually doing." Beam already answers the second question through agent runtime monitoring; Beam MDM now means the device compliance layer that guide argues you still need doesn't have to live in a separate, disconnected console.
Two ways to get remote actions
Beam MDM separates "can I see device state" from "can I act on a device," and offers two paths to the latter:
- Self-hosted MDM service — Beam's workspace controls and operation history sit in front of a dedicated Fleet engine per workspace. Fleet handles enrollment and device protocol delivery. Fleet-based lock and wipe require Fleet Premium.
- Beam-owned device response — native Apple lock and erase through a separately provisioned NanoMDM enrollment, or a signed Windows worker for session disconnect and OS reset. This path doesn't require Fleet Premium, but it adds its own requirements: per-device wipe enablement, password verification, explicit confirmation, and a command journal. Windows session disconnect is a session action, not persistent device lockout.
Either path, or an Intune connection for inventory and compliance review only, requires real certificates, signed packages, and hardware validation before activation — nothing in Beam MDM assumes that infrastructure already exists just because the setup path was selected.
Reading an operation record
An operation record shows the action, target, status, message, UTC time and ID. Profile content, credentials and raw Apple response bodies are excluded from the journals. The states are worth learning because the central rule is that accepted does not mean completed:
| State | Meaning | Next step |
|---|---|---|
| Recorded intent | Beam recorded the request before dispatch | Follow the same operation instead of creating another |
| Queued or dispatching | Delivery is pending | Check connectivity and the channel |
| Accepted | The provider or execution path accepted the request | Wait for device evidence and check the endpoint |
| Unknown or unconfirmed | A timeout or interruption prevented a trustworthy conclusion | Inspect provider, OS state and worker receipts before retrying |
| Reported outcome | The channel returned an acknowledgement or result | Verify the real device effect for high-impact actions |
Exact state names vary between provider operations and response journals. The service records durable intent and idempotency before mutations, a per-device response journal admits one outstanding command, and crashes or timeouts do not trigger automatic retries. The response journal keeps the last 50 commands per device, and the administrative ledger keeps operation and request IDs without automatic expiry; the operator must preserve it, along with worker receipts, across upgrades.
For unknown results, stop acting on the device, record the operation ID, check the provider queue and check-in data, and have the operator reconcile the outcome from retained evidence. Do not delete the ledger or send a second wipe as a diagnostic.
What Beam MDM does not do
Stated plainly, the same way we describe what Beam does not do for agent monitoring:
- It is not automatic enforcement. Remote lock, erase, and session disconnect are opt-in, gated actions — not a background policy engine that acts on its own.
- It does not replace Fleet Premium where Fleet-based lock/wipe is required. Beam's own response path is a distinct, separately activated alternative with its own hardware and signing requirements.
- It is not a substitute for a compliance certification. An enrollment and operation record is evidence a reviewer can examine, not a pass on its own — see AI compliance and regulation for agent activity.
What each response action does
The lock and wipe actions differ by platform, and the differences are easy to miss:
- Mac, through Beam response: Apple's DeviceLock with an operator-supplied six-digit recovery PIN. Wipe is limited to verified Apple silicon or T2 devices ready for Erase All Content and Settings. Beam does not escrow the PIN or offer remote unlock for this channel, so store a fresh PIN in your own vault before entering it. NanoMDM necessarily stores the command payload, so protect its storage and backups.
- iPhone and iPad: DeviceLock, which does not enable Lost Mode or location tracking, and EraseDevice with appropriate device-enrollment rights. User Enrollment is not the equivalent of device enrollment.
- Windows: lock disconnects active console and RDP sessions; the user can sign in again, and accounts are not disabled. Wipe requests the operating system's standard reset and depends on Windows recovery support.
- Fleet provider actions: depend on the platform and Fleet's capabilities; iOS and iPadOS lock uses Lost Mode. Fleet Windows lock and unlock additionally needs scripts enabled, which the provided installer builders do not turn on.
High-impact requests need deployment enablement, the exact device name and password reauthentication. Beam response also needs an operational reason, and wipe additionally needs the typed phrase ERASE ALL DATA and per-device wipe enablement. Unknown results block further Beam response actions on that device until resolved.
Offline devices behave differently by platform. Apple commands accepted by NanoMDM do not expire in Beam and cannot be cancelled, so a device that reconnects later may still execute them. On Windows, an uncollected command can be cancelled and expires after ten minutes; once the worker collects it, there is a single-use 60-second execution window and cancellation is no longer available. Disabling a binding does not undo an action the operating system has already accepted.
Binding a response channel to the right device
The response channel is bound to a device, not a hostname. An Apple binding pins the Fleet host ID, inventory UUID, platform and NanoMDM device-channel identity, and the docs tell operators to verify the channel ID against the Fleet inventory record. Replacing hardware needs a new verified binding, and identifiers must never be recycled for another device. A device already enrolled with Fleet must be re-enrolled to change MDM authority; Beam's Fleet enrollment profile is not a NanoMDM profile.
NanoMDM, the Apple server used for this channel, describes itself as a minimalist Apple MDM server and says it is only one component of a working setup: you need at least a SCEP server and TLS termination around it. Beam's guide repeats this: NanoMDM does not supply TLS, SCEP or an enrollment-profile builder by itself, and it needs APNs, an enrollment CA and persistent storage.
On Windows the worker is a signed PowerShell script that runs as SYSTEM and polls once a minute for that device's commands. The operator generates a unique enrollment file per device, bound to the hardware UUID, and does not clone it across machines. The installer encrypts the credential with machine DPAPI, protects %ProgramData%\BeamResponse for SYSTEM and administrators, and registers a scheduled task that requires signed scripts.
Connecting an existing Intune tenant
The Intune connection is for devices already managed there. Beam reads supported Apple and Windows inventory, compliance and encryption, and can optionally request sync; enrollment, policy creation, app installation, lock, retire and wipe stay in Intune. Only the Microsoft global cloud is supported, and one tenant maps to exactly one workspace.
An operator registers an application in the customer's Microsoft Entra tenant and grants the Microsoft Graph application permission DeviceManagementManagedDevices.Read.All with administrator consent. Microsoft's Graph reference for listing managed devices lists that read permission among those that allow the call. Credentials are kept server-side in the dashboard's secret manager, with no browser entry form. Inventory is read live and stops after ten provider pages, and Beam marks partial results. Optional sync needs a further permission, DeviceManagementManagedDevices.PrivilegedOperations.All, which Beam's docs note is broader than sync even though Beam exposes only sync, so they advise a dedicated application. Sync has a rolling 60-second per-device cooldown across operators, and a successful sync response acknowledges the request, not a completed check-in.
Self-hosting and readiness
For operators running the self-hosted deployment, the guidance is conservative. Use a separate Fleet instance, hostname and data volumes per workspace; do not split one engine by Fleet group and call it tenant isolation. Pin tested container images by digest. A Beam licence does not include Fleet Premium. The operation ledger requires durable Redis with append-only persistence, appendfsync always and noeviction, because losing request IDs can compromise duplicate protection. The service's /health endpoint only proves the process responds, so monitor provider connectivity, storage, identity expiry and representative device check-ins separately.
Beam also lists what the current interface does not provide: application distribution, Beam group targeting, OS-update policy editors, a recovery-key escrow screen and automatic certificate-renewal alerts.
Related reading
For the response side of a rollout, see AI agent deployment and incident response and SOC 2 for AI coding agents.
Get started
Start with a small test fleet: verify enrollment on a couple of disposable devices, confirm configuration profiles land, and only then plan a wider rollout. The Beam MDM page walks through connection options and links to a demo if you want to talk through your specific setup first.
Frequently asked questions
What is Beam MDM?
Beam MDM is a device management area inside a Beam workspace for enrolling and managing Apple and Windows devices — deploying configuration profiles, reviewing device inventory and posture, and tracking remote operations, separate from and alongside Beam's AI agent monitoring.
Do I have to use Beam MDM to use Beam for agent monitoring?
No. Agentic CLI monitoring and device management are two independent setup paths in the same workspace. A team can select one, both, or add the other later; choosing device management does not enroll any devices automatically.
Does Beam MDM require its own infrastructure?
No. Beam hosts the backend services for a Beam-hosted workspace — a customer does not deploy Fleet, MySQL, or a management engine themselves. Self-hosted operators can run the same components using the published deployment runbook.
What happens on Apple and Windows devices specifically?
Apple devices enroll through platform enrollment profiles and management protocols; Windows devices enroll through a signed installer and configuration files. Both report into the same inventory view, with delivery state for pushed configuration and a record of submitted operations.
Are lock and wipe available out of the box?
Remote actions are opt-in and gated behind administrator access, device confirmation, and password verification. Fleet-based lock and wipe require Fleet Premium; Beam's own Apple and Windows response path is a separate, explicitly activated connection with its own per-device enablement.
Can I connect an existing Microsoft Intune tenant instead?
Yes. A licensed Intune tenant can be connected to review Apple and Windows inventory and provider-reported compliance and request sync, while enrollment and policy management stay in Intune.
Product details reflect the Beam MDM deployment runbook as of September 15, 2026. Certificates, signed packages, and hardware validation are required before enabling any remote action.