Managed identity, unmanaged device

A contractor starts on Monday. By ten past nine you know their name, their manager, their department, the group that granted their access and the rule behind it, the exact minute they authenticated and the phone that approved it.

You do not know whether their disk is encrypted.

The account is not the mistake

Nothing in that setup was done badly. The identity work is right, and it is the part most organizations get wrong, so it is worth being clear that this is not that.

Single sign-on establishes the authentication path. Multi-factor raises confidence in the user presenting it. Provisioning decides which accounts should exist. Three good controls, primarily concerning identity and account state.

A modern identity platform can also consume device signals, but those signals have to come from somewhere: MDM compliance, a device certificate, endpoint posture, a managed browser or another attestation source. The fact that a user authenticated successfully does not, by itself, tell you the state of the machine.

Grant access from an unmanaged endpoint and you may have high confidence in the identity while still having little or no authoritative device posture. After the session opens, both matter to what happens to your data.

The list you cannot answer

For a device you do not manage, you generally do not know:

• Whether the disk is encrypted.
• The operating system version, and whether it still receives patches.
• Whether endpoint protection is installed, licensed, current and actually enforcing.
• What other local accounts exist, and who uses them.
• Whether the browser profile is signed into a personal account and syncing history, credentials and tabs to it.
• Which extensions are installed and what page content they can read.
• Whether sync software is copying local folders to personal cloud storage.
• Where downloads land, and what else can read that folder.
• Whether the machine is shared at home, travels, or gets left unlocked.

That is not a list of hypotheticals. Every line is a question a customer security questionnaire or an auditor may ask, and on an unmanaged device the honest answer to all of them is the same: we do not know.

The moment access becomes a copy

Session access is revocable. Disable the account, terminate sessions, strip the group, and the reach ends.

An ordinary downloaded copy is not reliably revocable. Once a file lands on local storage, control moves from your access policy toward a machine whose configuration you may not be able to observe. Unless the content is protected by a controlled workspace or rights-management mechanism, disabling the identity does not retrieve that local copy. You may not know it exists.

Which reframes the question. It is not whether this person should have access. They obviously should, that is why you engaged them. It is whether the work requires your data to come to rest on their endpoint, and more often than people assume, it does not.

Assistants and retrieval tooling sharpen this considerably. A connector authorized under a contractor's identity reaches whatever that identity reaches, which is the intended behavior, and makes previously theoretical access practical to exercise at scale. The companion note, Where data actually leaves through an AI platform, covers that mechanism.

This is not a control-plane conflict

Worth separating from a neighboring problem, because they get conflated.

When an identity provider and an MDM both hold facts about the same person and device, the difficulty is authority: which one wins when they disagree. Real design question, covered in Your identity provider and your MDM are two control planes.

This is different. In the unmanaged case there may be no authoritative device control plane at all. You have a confident answer about the user and no equally reliable source for the machine. The problem is absence rather than disagreement, and absence is easy to miss because nothing necessarily shows as broken.

The options and their tradeoffs

Issue a managed device. The cleanest answer. The endpoint joins the same policy and lifecycle as everyone else's, and you have a defined mechanism for compliance, support and offboarding. It costs hardware, logistics and shipping time, and for short or distributed engagements it often gets rejected on those grounds. Argue for it first anyway. The comparison is against the exposure, not against zero.

Enroll their device. Cheaper, and frequently refused for reasons that deserve respect. It is their property and their personal data. Where it is accepted, be precise in writing about what management can and cannot see, and understand that you have taken on obligations regarding personal information on a machine you do not own.

Check posture without managing the device. Certificate-based device identity, or an agent or browser-level attestation of encryption, patch state and protection at the point of authentication. Considerably less than full management and enormously more than nothing. This is the pragmatic middle for most contractor cases, and it is where conditional access earns its keep. Not as a product feature, but as the thing that converts an unanswerable question into a policy decision.

Manage the browser instead of the machine. When most of the work happens in SaaS applications, an enterprise or secure browser can govern the layer the data actually passes through without taking over the rest of the device. Depending on the product, that can include a separated work profile, extension control, session policy, logging, and restrictions around download, copy, paste, print or other data movement. The contractor keeps their machine and personal browsing while the work surface becomes more governable.

The limits are worth stating with the same clarity. It covers what goes through that browser and nothing else, so anything using a native client, a repository checkout, a database tool or an SSH session sits outside it entirely. It does not stop a photograph of the screen. It requires the contractor to actually work inside it, which is an adoption problem rather than a technical one. And it puts another vendor in the path of your data. For a contractor whose work is SaaS and web applications, it is often the best return of anything on this list. For an engineer with a local toolchain, it solves a fraction of the problem.

Keep the data off the endpoint as far as possible. Where nothing above fits, reduce the need for company data to rest locally. Remote browser isolation or a virtual desktop, view-only permissions, download and copy restrictions on the specific locations involved, and sync clients disabled for those accounts. Heavier for the user than a managed browser and potentially more complete. It does not eliminate every capture path, but it can sharply reduce persistent local copies.

Accept it deliberately, in writing. Sometimes the honest position is that the exposure is small, the engagement is short, and the mitigations cost more than the risk. That is legitimate when it is a decision, with named accountability, defined scope, an end date and a review. What is not legitimate is arriving at the same place by never having asked.

Narrowing the reach

Independent of the device question, the account should match the engagement rather than the department it sits near:

• Access scoped to the specific project locations, not inherited from a general-purpose group.
• Guest or restricted membership in collaboration platforms, with channels and spaces chosen rather than defaulted.
• Where the platform supports it, an expiry date on the account and relevant memberships, set at creation rather than tracked in somebody's calendar.
• No authority to authorize third-party applications or connectors under that identity.
• Named external access rather than link sharing, so the grant stays attached to something you can revoke.

The exit nobody triggers

Contractor offboarding is easy to miss for one structural reason. There may be no HR termination event. A supplier's statement of work can simply run out, so the process that reliably catches employees may never fire.

The compensating control is the end date set when the account is created, on the account and on every membership, so expiry is the default and extension is the exception that requires somebody to decide.

The device side of the exit needs an equally explicit answer, agreed in the contract rather than negotiated afterwards. What happens to local copies, what confirmation you get, and what comes back.

The check worth running

List every active account in your environment for which you cannot state the encryption status, patch level and protection state of the device it is used from.

That list is your unmanaged surface. It is rarely only contractors. Personal devices, unenrolled machines inherited from an acquisition, and long-lived accounts that predate your current MDM all tend to appear on it.

Explore this expertise: Endpoint Management & MDM

All technical notes