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.
1 of 4
Reset MFA for a field supervisor, from a phone
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.
The question you can't answer today: "Which of last quarter's access events happened on a device we could actually vouch for?"
So the boundary in your documentation and the boundary in the world are two different shapes, and only one of them is audited.
Your carrier's core may now run on the same cloud as your identity provider. One bad day can reach both, and neither one records who approved what from the phone.
② WHAT IT EMITS
Before a sensitive action goes through, MTB returns allow, limit, step up, or deny, with a short-lived signed receipt your team can check without calling us.
③ 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. |
Nothing we return can be used to follow a person from one customer to another.
④ 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.
Available now, one license at a time, provisioned by hand.
⑤ 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. 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 →Not now? The argument develops weekly in the Brief. Subscribe →