MOBILE TRUST BOUNDARY
Mobile carries the identity, the file access, and the MFA prompt — inside the boundary in practice, outside it on paper. Mobile Trust Boundary closes that gap with a short-lived, signed attestation — identity, device, connection — that the access platforms an enterprise already runs consume as a conditional-access input.
Not an agent. Not device management. Nothing ships inside your applications. A claim your platform reads — or it isn't for you.
Mobile Trust Boundary is a control plane, not a network. It selects and governs across networks it does not own.
① THE GAP
Your controls stop at the sandbox. Device management tells you a device enrolled; it does not tell you the device was intact, the line uncompromised, or the network clean when your data moved across it.
So the boundary in your documentation and the boundary in the world are two different shapes — and only one of them is audited.
The question you can't answer today: "Which of last quarter's access events happened on a device we could actually vouch for?"
② WHAT IT EMITS
Not a dashboard. Not a score. A short-lived signed token your platform reads and throws away.
"verdict": {
"trust": "degraded",
"risk_tier": "limited",
"reasons": ["conn.rogue_ap"],
"families": {
"identity": "unknown",
"device": "trusted",
"connection": "degraded"
}
}Worst-of, never averaged. A clean device on a hostile network is not a trusted session. There is no compensating control.
unknown never becomes trusted. If a signal can't be evaluated, it says so and propagates. Absence of evidence is never upgraded into evidence of safety.
Scoped to a window. It arms on an event you already generate and disarms when the window closes. Outside the window it evaluates nothing and emits nothing.
③ WHAT IT WILL NEVER DO
Architectural commitments, not disclaimers. Each is something that will not be built, so it cannot later be asked for.
| It will never | Why that matters to you |
|---|---|
| Manage your devices or issue device commands | You already have a management plane. Two is a support incident, not a feature. |
| Read message, email, or document content | Keeps it out of content-privacy review entirely. |
| Collect GPS or device location | Jurisdiction is derived from context you already hold, never sensed on the device. |
| Store SIM, IMEI, IMSI, or phone numbers at rest | Rotating derived tokens only. Never subscriber identifiers. |
| Inventory installed applications | Posture booleans only. Never a package list. |
| Ship code inside your applications | No binary, no release coupling, no app-store surface. |
Travelers are pseudonymous per tenant. The same person produces a different reference in a different customer's environment — cross-customer correlation isn't restricted, it's impossible.
④ VERIFY IT
The attestation and its decision log map to NIST 800-53 (IA-2, IA-5, AU-2, AU-3, AU-10, SC-8, SC-13, SI-4, CM-6), SOC 2 (CC6.1, CC6.6, CC6.7, CC7.2, CC7.3), ISO 27001:2022 (A.5.15, A.5.17, A.8.5, A.8.16, A.8.20) and ISO 27701 (7.2.2, 7.4.4). The privacy properties are schema-level, not policy promises — testable in review rather than assertable in a questionnaire.
Inputs and timestamps, checks evaluated, policy version and hash, tier applied, verdict, outcome. A trust verdict without provenance isn't auditable — so provenance is the format, not an add-on.
Four worked scenarios traced end to end with real hash chains, and a Python script that verifies tamper-evidence with no network, no credentials, and no dependency on us.
Current state, plainly: the identity family resolves to unknown for the entire first phase — device and connection carry it. Carrier-sourced identity signals require a feed that is a later dependency, named as such. Nothing described here is generally available. This is a design-phase specification, shaped with the organizations that adopt it first.
⑤ WHERE YOU LIKELY STAND
Your main gap — is not detection. It is evidence. You almost certainly have controls covering some of what's described here — what you don't have is a signed, timestamped claim that survives being asked about a year later.
What's happening now — you attest to a boundary drawn at the sandbox, while the data crosses one drawn at the device. Both statements are true, and only one is documented.
Why it matters — the gap is invisible until someone asks you to evidence it. Then it is the only thing anyone talks about.
Fix first — decide where a trust field would live on your existing record — first-class attribute or metadata. That single decision determines whether the audit story is native or bolted on, and it costs nothing to answer.
What can wait — enforcement. The first phase is read-only throughout. Nothing gates, nothing blocks, no user sees a change.
Likely benefit — an answer to the one question you can't answer today, in a form an auditor accepts and an engineer can verify without calling you.
Two half-days. We bring the attestation schema, the trigger map against identity and access surfaces you already run, the decision-log format, and the worked scenarios. You bring your requirements.
Request the session →Three documents and the offline verifier. Read them on your own time, without a call.
Not now? The argument develops weekly in the Brief. Subscribe →