Talk to any modern engineering organisation preparing for or living with SOC 2 in 2026 and the same uncomfortable conversation comes up. The auditor wants evidence that the in-scope service is protected by effective controls, including on the devices that touch it. The reality is that those devices are no longer a neat corporate fleet:

full-time employees on macOS, Windows and Linux, some of them with strong opinions about lockdown;
BYOD and BYOPC users — personal laptops and home PCs that the company does not legally own;
contractors and partners who arrive with their own hardware, ship for three months, and offboard the day the SOW ends;
developers with admin rights, IDEs, package managers, SSH keys, PATs and a long list of local tools they will not give up;
and now a brand-new actor: coding agents — Cursor, Claude Desktop, Claude Code, Codex, OpenClaw — running on the same workstations, with shell access, file-system access and 20+ MCP-connected services.

Each of those populations widens the SOC 2 surface in a different direction, and none of them fits the classic "enrol every device in MDM/UEM" answer. That is the problem this post is about — and the reason my company EDAMAME built the layer that sits exactly where MDM/UEM is the wrong shape.

SOC 2 is an attestation, not a device-management mandate

The first thing to get out of the way is the most common misreading. SOC 2 is not a technology prescription. The AICPA defines SOC 2 as an examination report on controls relevant to the Trust Services Criteria — Security (the "common criteria", always in scope) plus Availability, Confidentiality, Processing Integrity and Privacy selected as applicable. The auditor is not asking "did you deploy Intune, Jamf or Workspace ONE?". They are asking "how do you control risk over the in-scope service, and what evidence shows the control operated effectively over time?"

That distinction matters because it opens a much better-shaped answer than the default one. If the question is risk + evidence, the answer can be a layered, identity-first, posture-aware control mesh that fits the modern fleet — instead of forcing every contractor and BYOD user into an enrolment flow they will (rightly) refuse. NIST's SP 800-207 Zero Trust Architecture explicitly framed remote users, BYOD and cloud resources as the reason organisations should stop relying on network location or asset ownership as trust boundaries. The audit question follows the same logic: prove trust per request, not per device-owner-on-the-asset-register.

Why legacy MDM is the wrong shape for the modern in-scope fleet

Legacy MDM/UEM is a reasonable tool for specific use-cases — regulated medical fleets, kiosk endpoints, certain logistics scenarios. It is the wrong shape for the SOC 2 fleet that actually matters in most service organisations today. Five reasons keep coming back:

BYOD and BYOPC do not enrol. NIST's own SP 800-124r2 warns that wiping data the enterprise does not own can create real legal issues, and that organisations should think carefully about scrubbing enterprise data from BYOD or third-party-controlled devices. A control that the legal team will not let you enforce is not a control.
Contractors offboard faster than MDM rollouts. Many contractors are productive in three to five days and gone in three months. MDM enrolment, profile installation, certificate issuance and de-enrolment are not a three-day flow.
Developers will fight lockdown — and win. I wrote about how engineers routinely defeat MDM, UEM and "user experience" agents on their corporate laptops in Tales from the Front Lines. The pattern is consistent: when lockdown is the wrong shape, it gets worked around.
MDM does not speak "continuous evidence". It gives you an enforcement surface, not a live assurance feed into the compliance platform an auditor actually opens. Evidence is still re-assembled out of screenshots, exports and ad-hoc scripts when the audit window lands.
Coding agents are a new actor MDM has no semantics for. Cursor, Claude Code and the rest are deputies with shells, package managers, file-system access and tool-access via MCP. The question "is this agent's host trustworthy at the moment it touches code or secrets?" is not a question MDM was designed to ask, let alone answer.

The net effect: a service organisation pursuing SOC 2 sits in an uncomfortable middle — compliance platform in place, baseline hygiene in place, customers asking for more, and a legitimate reluctance to answer with a full MDM rollout. That middle is where the post-MDM endpoint trust layer belongs.

The control mesh that actually maps to the Trust Services Criteria

A workable no-legacy-MDM SOC 2 stack is not one product. It is a control mesh: identity-first access, posture signals from a lightweight trust agent on every machine that matters, conditional access or ZTNA at the request boundary, repo-side and runner-side enforcement for the SDLC actors, and continuous evidence flowing into the GRC platform that the auditor actually reads.

Mapped against the in-scope populations, the picture stops being abstract:

BYOD / BYOPC employees — gate access on identity + posture; require encryption, firewall, patching and EDR-grade signals; minimise local data storage; export posture attestations as audit evidence. The user-centric approach exists precisely because the asset-register answer doesn't.
Contractors and third parties — same posture model, plus strong joiner-mover-leaver and rapid deprovisioning. Contractor BYOD is the easiest case to mishandle and the easiest one to get right with the trust layer.
Developers on local workstations — protect code and secrets at the repo boundary, not just at SSO. Branch protection, audit logging, OIDC for cloud access, and posture-conditional repo access close the token loophole that has been burning enterprise incident-response teams for two years.
CI/CD runners and build hosts — treat runners as crown-jewel infrastructure; verify host posture before code or secrets touch them. Self-hosted runner compromise is a supply-chain attack at build time, not a generic incident.
Coding agents on the workstation — inventory the agents, models, plugins and MCP tools; constrain tool scopes; log sessions and tool use; monitor divergence between the agent's declared task and observed host behaviour. This is the new front line; EDAMAME's coding-agent runtime verification is built for it.

Each row of that table is a Trust Services Criteria conversation in disguise — typically Security CC6–CC9, and Confidentiality / Privacy / Processing Integrity where the in-scope service makes them relevant.

The principle that makes a no-MDM SOC 2 audit actually defensible

There is one non-negotiable design principle behind all of the above:

Unmanaged endpoints may access more; they should store less and do less.

The more sensitive data is synchronised onto a personal laptop or contractor workstation, the more a no-MDM programme begins to inherit the same assurance burden as a lightly managed fleet — without the enforcement levers. Keeping customer data in controlled SaaS, browser or app sandbox contexts, and proving that access is gated on live posture, is what makes the auditor's Type II opinion easy to write.

EDAMAME × Vanta — the live-evidence loop that closes the audit

Picking the right control mesh is half the problem. Producing reviewable, continuous, auditor-friendly evidence from that mesh is the other half — and it is where most no-MDM programmes still fall back on screenshots, spreadsheets and quarterly heroics.

That is exactly the gap my company EDAMAME and Vanta close together, and it is the partnership we have been quietly proving in production for over a year. The integration is now official in the Vanta Marketplace, and the shape is intentionally simple:

EDAMAME Security runs locally on the laptop or workstation — employee, BYOD or contractor — and continuously checks OS integrity, encryption, firewall, patch level, EDR posture and a long tail of host-truth signals.
EDAMAME Posture does the same job on CI/CD runners, self-hosted build hosts and coding-agent hosts, including the MCP path that lets the agent monitor its own system and network behaviour.
The device-posture attestation is streamed to EDAMAME Hub — no remote admin privileges, no covert changes, no remote wipe. Reporting-only architecture; users see what is wrong on their own machine and fix it themselves.
EDAMAME Hub continuously syncs those attestations into the customer's Vanta tenant via Vanta's public Device Monitoring API. Vanta maps them to its native device controls — "Disk encryption enabled", "OS up-to-date", "Antivirus running", "Firewall enabled" — and surfaces them inside the SOC 2 and ISO/IEC 27001 report packs the auditor reviews.

The net effect on the audit is concrete:

the device inventory in Vanta includes BYOD, BYOPC and contractor endpoints, not just the corporate-owned fleet;
posture evidence is continuous, not point-in-time, so Type II report-period coverage is real;
when a device falls out of compliance, the owner is flagged to remediate locally — no IT ticket, no remote control, no privacy debate;
the deeper review questions enterprise customers now routinely ask — "which devices can access sensitive systems right now?", "how do you know contractor laptops are encrypted?", "what about coding-agent hosts?" — get answered with live data, not policy text.

The full mechanics, including the two-sided setup flow from EDAMAME Hub and from the Vanta marketplace side, are documented in EDAMAME × Vanta: Endpoint Compliance — No MDM Required and on the compliance page.

Coding agents — the new actor that has to be on the same trust layer

Coding agents deserve their own paragraph, because they are the population that has changed most in the twelve months since the Vanta integration first shipped. A coding agent with shell access, package-manager access and 20+ MCP-connected services is not a chatbot — it is a deputy with hands, acting under a developer's identity and frequently with the same authority to commit, push and deploy.

For SOC 2 purposes, that means the agent's host is now part of the in-scope surface whenever it can affect production code, customer data, secrets, releases or service commitments. NIST SP 800-218A (Secure Software Development Practices for AI Models) extends the SSDF logic to this exact question. The audit-ready answer is the same trust layer applied to coding agents specifically:

an inventory of agents, models, plugins, MCP servers and data classes the agent is allowed to touch;
least-privilege scopes for tools and credentials;
session and tool-use logs sufficient to reconstruct what the agent did, when, on which host, against which repository;
runtime verification of the gap between the agent's declared intent and the host's observed behaviour — credential harvest, sensitive-file access, token exfiltration, suspicious egress;
and a human-in-the-loop escalation point for privileged or irreversible actions.

That is what EDAMAME's coding-agent runtime verification ships today — across the agents our customers actually deploy (Cursor, Claude Desktop, Claude Code, Codex, OpenClaw). The same posture stream flows into Vanta alongside the laptop and runner evidence, so coding-agent governance is not a separate audit conversation — it is a row in the same evidence pack.

A practical minimum control set for a no-legacy-MDM SOC 2

For an engineering organisation pursuing SOC 2 across a mixed fleet of employees, contractors, BYOD users, developers and at least some AI-assisted engineering, the minimum control set is genuinely workable and genuinely defensible:

Scope and data flow design — define what the in-scope service is, where customer data may reside locally, and which endpoint personas touch it.
Identity and JML — central IdP, MFA, SCIM where possible, no shared accounts, contractor termination SLA, quarterly access reviews.
Endpoint baseline and posture — encryption, firewall, patching, EDR-grade signals, supported-OS policy, documented exceptions, continuous posture evidence from EDAMAME.
Access gating — conditional access or ZTNA tied to identity and live device posture. No direct private-app access without policy evaluation.
Data minimisation and movement control — keep sensitive data in controlled SaaS / browser / app contexts; apply DLP where needed.
Contractor governance — security terms in contract, posture-gated access, defined offboarding SLA faster than employee baseline.
Developer controls — branch protections, required reviews and checks, OIDC for cloud access, secret hygiene, audit logs, posture-conditional repo access. See Zero Trust for GitHub.
Runner and build-host controls — harden hosts, isolate runners, prefer ephemeral credentials, verify posture before code or secrets are reachable. See CI/CD security.
Coding-agent governance — approved inventory, plugin / MCP review, least-privilege scopes, session logs, runtime verification, human approvals for sensitive actions.
Evidence automation — continuous export of posture and control evidence into Vanta (or comparable GRC), with retained change records and control narratives.

Each of those rows is something an auditor will ask about. Each of them is something the trust layer + Vanta evidence loop answers with live data instead of policy text.

Developer-first stays the ground rule

A common objection sounds like "this still sounds like another agent on my laptop". The design principle is deliberately the opposite. EDAMAME is one agent whose only job is continuous posture and (where the customer wants it) posture-conditional enforcement at the trust boundary. It does not try to be EDR, MDM, DLP or a compliance platform in disguise. It complements them, and it replaces nothing the customer is already relying on. And because the architecture is reporting-only — user-up, not lockdown-down — it keeps contractors, BYOD users and fast-moving engineering teams on-side instead of turning endpoint security into an adversarial relationship with the people whose devices it runs on.

What "audit-ready" actually looks like

Run the SOC 2 review questions straight through the trust layer + Vanta loop and the story reads cleanly:

"Which devices can access the in-scope service right now, including BYOD and contractor devices?" → Continuous posture on every attested device, exported live into Vanta.
"How do you prove encryption, OS patch level and EDR posture for personal laptops?" → EDAMAME Security on the workstation, attestation in Hub, evidence in Vanta — no enrolment, no remote wipe, no privacy debate.
"What about your developers' tokens, SSH keys and PATs?" → Posture-conditional access at the Git layer closes the token loophole; a stolen credential on a non-attested device stops working.
"What about your CI/CD runners and build hosts?" → Same trust layer applied to runners; posture verified before code or secrets are reachable.
"What about your coding agents?" → Inventory + scopes + session logs + runtime verification of declared vs. observed behaviour, on the same evidence stream.
"Can you put live evidence into Vanta?" → Yes — continuous attestations via the Device Monitoring API, not screenshots reassembled every quarter.

Next steps

Read the full SOC 2 without legacy MDM white paper — the deep version of this post, with audit-scenario walk-throughs, the layered control mesh in detail, and the EDAMAME × Vanta evidence loop end-to-end.
Read how the trust layer flows live into Vanta on the EDAMAME compliance page.
See the existing EDAMAME × Vanta integration end-to-end, including the two-sided setup flow.
See the SDLC side of the same trust layer on Zero Trust for GitHub and CI/CD security.
See the coding-agent runtime side on the coding agents page.
Try it on your own fleet: connect Vanta from EDAMAME Hub in a few minutes.