Consultants on client-owned laptops you cannot enrol need access. How do you scope that exemption so an attacker cannot simply claim it, and what does it cost?

## The shape of the problem A consultancy works inside client tenancies. Some staff carry the firm's managed, attesting laptops. Others work on client-owned machines the firm did not buy, cannot image, cannot enrol and will never get a hardware-rooted signal from. Those people still need access to the firm's systems. So a fallback branch exists, and the whole question is how that branch is selected. ## The defect: an exemption the device asserts The naive design puts the fallback on the wrong side of the trust boundary. Policy evaluates the posture document; if there is no attestation block, or a field says the device is unmanaged, the request is routed down the unmanaged path. The adversary reads that logic exactly as written: *to get the weaker policy, present no attestation.* Anyone with a stolen credential and their own machine takes the fallback branch on purpose, and the branch you built for a colleague becomes the branch the intruder uses. Same defect, other costumes: a header the client sets, a fingerprint the browser reports, an arrival network the attacker can also arrive on. If the connecting party controls the input, the connecting party controls the tier. ## The correction: the assertion runs the other way Cohort membership is a **fact the server already holds about the identity**, not a fact the session brings with it. - Membership is recorded against the person during onboarding to an engagement, entered by someone other than the person who benefits from it. - It names the engagement or the access it exists for, so it is not a blanket property of the account. - Absence of attestation on a non-member is simply a denial, not a downgrade. The unattested path is not reachable by choosing it. The device may still send whatever it likes; nothing it sends can move it between tiers. That inversion is the entire security content of the answer, and it is what an interviewer is listening for. ## What you can still anchor on a device you do not own Give up on device health and take what is genuinely provable: | Signal | What it really proves | | --- | --- | | A hardware-held authenticator issued by the firm | a person with our token is present and the request is bound to our origin | | Server-side cohort membership | this identity is one we deliberately admitted to the thin tier | | Session and access telemetry | what that tier did, available after the fact | | Anything the endpoint reports about itself | nothing, under compromise | The honest formulation is: *person strongly authenticated, device untrusted, data does not land.* That is a coherent posture. "Unmanaged device, full access, because we checked a box in the browser" is not. ## Scoping the tier to the blast radius Because you must assume the endpoint is hostile, the tier's reach **is** the damage. Ways to keep it small, roughly in order of how much they cost: - rendered or streamed access so the data never sits on the endpoint; - read paths only, with bulk export and administrative surfaces excluded outright; - narrower application scope — the engagement's systems, not the firm's; - shorter windows and more frequent re-authentication with the hardware authenticator. What you must not do is grant the thin tier and then quietly add exceptions to it until it matches the managed tier. If the thin tier is nearly as capable, the fallback branch is again the adversary's preferred route. ## The bill, stated plainly This design is not free and pretending otherwise is a weak answer. - **The consultant pays first.** Rendered access is slower, offline work stops, and familiar tooling may not be available. On a billable engagement that is visible immediately. - **Somebody staffs the cohort.** Membership has to be added, removed when an engagement ends, and reconciled against who is actually working where. That is ongoing work with no glamour. - **The firm may have to buy its way out.** Issuing managed, attesting laptops for engagements that touch sensitive client data, or funding a rendered-access capability, are the two real escapes, and both are line items. - **Some clients will refuse.** A client that will not permit the firm's laptop in its building, and also will not accept the thin tier, is a commercial conversation, not a technical one. ## The one-line version "The device never gets to say which policy applies to it. We decide that server-side, for named people, and the tier we give them is small enough that we can survive whoever ends up holding their credentials."