Control Plane
Watch it run. Change the rules. Show what happened.
One screen for the whole fleet: what each person approved, on which device, and what your policy decided about it. The authority itself lives in the hardware of the person's phone, not in the software you operate.
In Short
What is the Yuthent control plane?
It is the screen your team works from once Yuthent is in. It shows every action your people approved, the device each approval came from, and what your policy decided. From the same screen you change that policy, turn a device off, and send the record to your own systems.
Who Operates It
One screen. Three jobs.
Set the rules. See the fleet.
Tenant Administrator
- Every enrolled device, with its platform, status and when it was last seen
- One device's history: what it approved, when, and what your policy said
- A policy editor for what gets challenged, and how hard
- Send a live test action to an enrolled device
Triage. Respond. Turn it off.
Security Operations
- Alerts sorted by how serious they are and what raised them
- Turn a device off, and it stops approving from that moment
- A feed of device, approval and alert events into your SIEM
- A callback so your own fraud engine returns the verdict
Show the work.
Compliance & Audit
- A daily export into a storage bucket you own
- For any person, what they approved and in what order
The Record
What you can show afterwards.
Every approval leaves a record, and the record is yours: it lands in your own storage on your own terms, and it says who approved what, on which device.
In order, per person
Each approval is recorded against the person who made it, in the order it happened. The record holds hashed identifiers, not personal data.
Yours to export
A daily export into a storage bucket you own, under your retention policy, your encryption and your access control.
Off means off
Turn a device off from this screen and it stops producing approvals from that moment, on every action it used to cover.
Integration Surface
Plugs into the stack you already run.
Events out to your SIEM. Verdicts in from your fraud stack. The record out to your storage. Devices off by API.
Webhooks
Device, approval and alert events, pushed out to your SIEM or event bus. A delivery that fails is retried.
External decision callback
Your fraud engine returns the verdict at approval time: challenge harder, ease off, or soft-block. No SDK change.
Audit export
A daily export into your own Google Cloud Storage bucket. You keep the retention policy, the encryption and the access control.
Revocation API
Turn a device off by identity or hash. The device is told straight away, and it stops producing approvals from that moment.
Where The Line Sits
Some things are settled before your policy sees them.
A short, fixed list is settled on the device itself. Everything else is collected, signed and reported to your policy engine, which returns the verdict. Banks own fraud policy under PSD2 and DORA, and the SDK does not overrule them.
Settled on the device
Not a policy setting
- The approval was released by the person's own fingerprint or face
- The device is the enrolled one, and its hardware says so
- The signing key is still held in the device's secure hardware
- The approval is new, not a repeat of an earlier one
These are settled in the secure hardware of the person's phone, the Secure Enclave on iOS and StrongBox or the TEE on Android, and released by their fingerprint or face. Nothing on this screen changes them.
Your policy decides
Collected · signed · reported
Every one of these reaches your policy engine with the approval it belongs to. What to do about any of them is your call, and you change it here.
Data Posture
Tenant data stays in the tenant scope.
Isolation is enforced at the datastore, not at the UI. Every read and every write carries the authenticated tenant identity. Each tenant sees its own data and no one else's, and the Yuthent team sees none of it without support consent you give, which is logged.
DORA, PSD2 and the EU AI Act all expect you to show that a person, not a system, stood behind a consequential action. The control plane is where that record lives. The full compliance posture is published on the Security page.
Questions
The control plane, answered.
Does it replace my SIEM or fraud stack?
No. It composes with what you run; it does not replace it.
Who needs a login?
Whoever operates it: the person who sets the policy, the person who answers alerts, and the person who pulls the record for audit. Access is scoped by role.
What happens when we turn a device off?
It stops producing approvals from that moment, and the device itself is told straight away rather than finding out on its next call.
See it on your own flow.
Your app, your call, our SDK.