Device Operations Bridge: supporting cloud-only devices

A remote Windows laptop shows as online in Intune. It is not on the corporate network, and a technician needs to inspect a service or fix a local setting. Because it is cloud-joined, the familiar domain-based administration route is unavailable. Windows LAPS supplies a managed local administrator password. Useful, certainly. But there is still a support task to organize around that password.

This series calls the private implementation Device Operations Bridge. It joins those pieces: finding the managed endpoint, authenticating and authorizing the operator, creating a time-bounded session, optionally reaching the device through a network gateway, and recording events. Entra ID, Intune, Microsoft Graph, Windows LAPS, and WinRM still do their own jobs. The bridge works with them, not in their place.

The operational gap

The gap is easy to miss when management and support appear on the same slide. Intune can show that the device is managed and apply policy. LAPS can supply the local administrator credential. Neither tells the technician how to start, whether they may access this particular device, how long access should last, or which path can reach its remote network.

Leave the joins to people and the likely result is copied passwords, informal authorization, and a ticket updated afterwards, when everybody remembers a slightly different sequence. I would rather make those controls part of the task. That is the audience here: endpoint support teams, identity and security administrators, and platform engineers troubleshooting cloud-managed Windows devices without making the password the whole access model.

The bridge groups the work around one target device and operator. Now the device identity, caller, session window, execution path, and end of the operation can be examined together. Less reconstruction later.

Follow the request through its boundaries

Figure 1: the workflow coordinates existing identity, device-management, credential, and network capabilities rather than replacing them.

1. The operator identifies a managed device

An operator supplies a device identifier through a client: the PowerShell module, a REST endpoint, or an MCP tool in a compatible assistant client. Each exposes selected capabilities. I would not treat them as interchangeable trust boundaries just because they can begin similar work.

2. The service evaluates access

First the service authenticates the caller. Protected LAPS session routes then check a role, such as LAPS.Admin or LAPS.User. Accepting a token, certificate, or API key does not grant those roles. It answers the first question, not both.

For an assistant integration, check this separately. A REST role filter is not protection for every MCP tool. MCP needs appropriate authentication and authorization of its own, and the client may receive any value the tool returns. That includes values you would not put in an ordinary support transcript.

3. Graph data and session tracking provide context

Graph-backed services fetch the relevant Entra and Intune device information and, if permitted, the Windows LAPS credential. The session record holds the operator, device, creation time, expiry, status, and credential. Current records live in the session manager's process memory. They are not durable history; another API instance does not automatically see them.

A configurable concurrent-access policy can warn or block if the same device already has an active session. Helpful for avoiding accidental overlap, within the limits of that process-local state. It is not a distributed lock across instances or restarts.

4. The network path is optional—and real

If a remote command is needed and the API cannot reach the endpoint directly, there is an optional gateway. It maintains an outbound SignalR connection to the API. The API routes a request to a connected gateway, which uses PowerShell remoting over WinRM from a network that can reach the Windows device.

This extends the network path; it does not make an offline or unresolvable device available. Check name resolution, routing, firewall rules, WinRM configuration, and gateway placement. They still decide whether the command can run. Device management and authorization remain separate responsibilities, neither replaced by the gateway.

5. Closing the operation is not the same as proving every outcome

The API and gateway can emit lifecycle and execution events, but audit handling follows a separate path. Recent events may sit in a bounded in-memory cache; telemetry can go to Application Insights. Durable persistence through Service Bus, an Azure Function, and SQL is optional. Configure and monitor that route separately if it is needed.

Do not read “closed” as “password changed.” The MCP stop flow can request rotation when its setting is enabled and no other session remains. Other stop and stale-session cleanup paths do not all call that Graph rotation method. Closure and rotation depend on the route, so verify the actual route and result. An audit event alone is not proof of a changed LAPS password.

What this approach improves—and what it does not

For me, the improvement is having a support task with a target, an operator, a time window, and related lifecycle events. The concurrency policy makes overlapping work more deliberate. The optional gateway keeps network-side execution separate from the cloud control plane. If records need to persist, the configurable audit pipeline can provide that path.

There is still no single “all safe” indicator. Session state is volatile and process-local. Emitting an audit event does not ensure durability. A session identifier does not hide a credential returned by the selected client, and session-start success says nothing about whether DNS, routing, or WinRM is ready. These are separate checks.

Deployment considerations

• Scope Microsoft Graph permissions to the device and LAPS operations the service actually performs.
• Assign LAPS roles deliberately, and verify authorization independently for REST and MCP entry points.
• Place a gateway only in network segments it needs to serve; validate device resolution and WinRM from that gateway.
• Require encrypted WinRM and certificate validation in production rather than disabling checks to make a connection succeed.
• Treat LAPS values, command output, assistant transcripts, diagnostics, and telemetry as sensitive data.
• If investigations require durable records, enable and test the Service Bus, Function, and SQL path, including its failure alerts and retention policy.

I would finish a deployment review by asking somebody to explain one real test operation: who requested access, which device was targeted, which path reached it, how the session was governed, and what evidence survived. Having a managed local administrator password answers only part of that. Better to find the missing answers in a test than during an urgent call, when “we will document it tomorrow” is already preparing its entrance.