VN-09 · macOS Endpoint & Intune Posture

Status: Delivered (macOS enrollment/posture + Intune read-only posture). Native mobile agents are out of scope by design. Roles needed: Tenant admin

What the client asked for

"macOS 13+ agent support is Phase 1. Mobile device posture is Phase 1 through Microsoft Intune / Endpoint Manager API rather than native mobile agents."

What this proves

A macOS endpoint can enroll and report posture just like other endpoints, and mobile/managed-device posture is pulled (read-only) from Microsoft Intune rather than by installing a mobile agent.

How it works (at a glance)

Validate via Swagger (Try it out)

Open /api/docs, click Authorize, paste a tenant-admin token. Use the request schema shown in Swagger for each body. (A portal form also exists under Settings → Intune posture.)

#	Action	What you should see
1	POST /api/v1/integrations/intune/connections (display name, tenant authority, client ID, secret reference)	200; connection created with the secret reference redacted
2	POST /api/v1/integrations/intune/connections/{connection_id}/sync	A bounded sync runs (cannot loop unbounded on a cyclic/oversized Graph response)
3	GET /api/v1/integrations/intune/devices	Read-only device posture, tenant-scoped
4	GET /api/v1/integrations/intune/connections	Connection listed; no device-control actions exist (read-only posture)

Contract & tests: /api/v1/integrations/intune/* in the OpenAPI deliverable; Intune connector tests. The macOS agent enrollment itself is a portal journey (VN-01). Native mobile agents and device-control actions are out of scope by design.

Where to look in the portal

• Assets (for the macOS endpoint)
• Settings then Intune posture
• Audit

Validation walkthrough

Exact labels match the portal. The connection fields are your real Microsoft Entra/Intune values; substitute <azure-tenant-id> and <azure-app-client-id> with your tenant's actual identifiers.

#	Action	What you should see
1	Sign in as tenant admin. Open Assets.	The enrolled macOS endpoint appears with platform macOS/darwin and an OS version.
2	Open the macOS asset detail.	macOS posture/inventory fields are populated from heartbeat.
3	Open Settings and scroll to the Intune posture card.	A Create Intune connection form is shown (tenant-admin only).
4	Fill Connection display name = Contoso Intune, Tenant authority = https://login.microsoftonline.com/<azure-tenant-id>, Client ID = <azure-app-client-id>, Secret reference = opk://tenant/<your-tenant>/intune/client-secret, leave Enable sync checked. Click Create Intune connection.	The form shows Intune connection created.; the connection appears in the list with its status and sync enabled, and the secret reference is redacted in the row.
5	Review the connection row and any synced device posture.	Posture data is read-only; provider secrets are redacted.
6	Confirm there is no device-control action.	No remote-wipe / push-config controls exist (read-only posture only).
7	Sign in as an operator; open Settings → Intune posture.	The Create Intune connection form is not shown; posture remains viewable.
8	Open Audit.	macOS enrollment and Intune connection/posture activity are recorded for your tenant.

Pass / fail checklist

• A macOS 13+ endpoint enrolls and appears as a managed asset (platform = macOS/darwin)
• Tenant admin creates an Intune connection from Settings → Intune posture → Create Intune connection and it appears with the secret reference redacted
• Operators do not see the create form; posture is read-only
• No device-control actions are exposed
• macOS and Intune data are scoped to the owning tenant
• Intune device sync is bounded (a cyclic/oversized Graph response cannot cause an unbounded fetch loop)

Intentionally not in Phase 1

• Native mobile (iOS/Android) agents. Mobile posture is via the Intune API by design.
• Device-control actions (remote wipe, push config). Phase 1 is read-only posture.

Evidence to capture

• Screenshot of the macOS endpoint in Assets.
• Screenshot of the Intune posture snapshot.