MOBILE TRUST BOUNDARY

Signed, checkable trust for the boundary your data actually crosses.

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.

Try it in the sandbox

Mobile Trust Boundary is a control plane, not a network. It selects and governs across networks it does not own.

Which side of the boundary are you on?

① THE GAP

Then this is the part of your boundary you cannot currently evidence.

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

One signed answer your access platform already knows how to read.

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

Six things this will never do.

Architectural commitments, not disclaimers. Each is something that will not be built, so it cannot later be asked for.

It will neverWhy that matters to you
Manage your devices or issue device commandsYou already have a management plane. Two is a support incident, not a feature.
Read message, email, or document contentKeeps it out of content-privacy review entirely.
Collect GPS or device locationJurisdiction is derived from context you already hold, never sensed on the device.
Store SIM, IMEI, IMSI, or phone numbers at restRotating derived tokens only. Never subscriber identifiers.
Inventory installed applicationsPosture booleans only. Never a package list.
Ship code inside your applicationsNo 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

Nothing here asks you to take our word for it.

A controls crosswalk

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.

A decision log on every verdict

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.

A verifier you can run offline

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

If you've read this far, here's the honest read.

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.

The architecture session.

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 →