The SDK is half the product.
The control plane is the other half.
Every Yuthent deployment operates from a live control plane, device forensics, enrollment, a policy editor, anomaly triage, the tamper-evident action ledger, analytics, webhooks, and access control. The operator, the responder, and the auditor each get the surface they need, live from day one.
What is the Yuthent control plane?
The control plane is the operational surface over Yuthent Execution Authority Infrastructure. It shows every action the SDK emitted: device forensics, trust policies, the hash-chained action ledger, fraud triage, and audit export. Operators revoke a device in one step and export a proof bundle verifiable against a published public key.
Where this sits in the stack you already run.
Authentication, authorization and audit each answer their own question correctly. None of them is present at the moment an action executes. Execution Authority fills that centre.
One surface. Three audiences.
A Yuthent deployment does not end at integration. It is a production system with a day-two story. Each role sees the view that matches its responsibility. Data stays scoped to the tenant.
Configure. Operate. Prove value.
Tenant Administrator
The day-to-day operator of a Yuthent deployment. Manages enrolled devices, configures trust policy, reads the action ledger, pulls audit exports for board review.
- Device fleet view, with status, platform, and last-seen
- Per-device forensics: action history, session timeline, fraud flags
- Trust policy editor for biometric thresholds and enforcement mode
- Send a test action to any enrolled device, live
Triage. Respond. Revoke.
Security Operations
The responder who sees a fraud signal and needs to act within seconds. Operates the fraud center, revocation controls, and webhook integrations into the existing SIEM and fraud stack.
- Fraud alert triage with severity and event-type breakdown
- Immediate device revocation with push propagation
- Webhook feed into SIEM, fraud platform, or internal systems
- External-decision callback to inject upstream fraud verdict
Export. Attest. Defend.
Compliance & Audit
The auditor who needs to reconstruct what happened and prove it to a regulator, a court, or an internal committee. Works from the immutable action ledger and BigQuery export.
- Hash-chained action ledger with daily anchors
- BigQuery audit export to a bring-your-own-storage bucket
- Per-action forensic record: device state, trust state, counter
- Exportable proof bundle verifiable against a published public key
Four tiers. Chosen per action, by you.
Not global per user, per action. A hospital pins Authoritative to dangerous-drug dispensing and Passive to reading a record. A bank pins Authoritative to transfers and Explicit to balance lookups. Routine work is never interrupted.
Passive
Device-state attestation with no user interaction. Background risk scoring and silent agent-activity audit.
- Biometric
- None
- Server
- Query only
- Persists
- None
Silent
One biometric opens a short window. Low-friction in-session confirmations and low-risk reads.
- Biometric
- Session-cached
- Server
- Batch on session end
- Persists
- Signed session summary
Explicit
A fresh press for this action. Completes locally on success, so a bad network does not block a legitimate approval inside the grace window. Past it, the tier fails closed until the device syncs.
- Biometric
- Fresh, per action
- Server
- Async verify
- Persists
- Counter + hash
Authoritative
The server gate is the security boundary. Fund transfers, beneficiary add, dangerous-drug dispense, privileged agent actions.
- Biometric
- Fresh, per action
- Server
- Synchronous authorize
- Persists
- Full audit trail
Risk maps to tier by default, LOW to Passive, MEDIUM to Silent, HIGH to Explicit, CRITICAL to Authoritative, and your backend can pin any action anywhere on the ladder.
Ten surfaces. One control plane.
Every surface is shipped and in use, scoped to the tenant and isolated at the datastore layer. This is the operator's, the responder's, and the auditor's daily workspace.
Device forensics
A trust roster with per-device drill-down: action-ledger timeline, session history, grace-window countdown, revocation state, and a latency histogram at p50/p95 per phase. Revoke any device in one click.
Enrollment & attestation
Every enrollment snapshots the device posture, key-storage level (StrongBox / TEE / Software), security-patch date, boot state, and root / emulator / hooking flags. Enroll in person by QR, or over a remote video link.
Actions & approvals
The live action log plus a pending-approvals queue for push-driven Explicit-tier requests. Every row carries the tier, the verdict, the source, and the action count.
Trust-policy editor
A 15-signal matrix, set Approve, Step-up, or Deny per signal, autosaved with undo. Dry-run any scenario before you commit, diff the version history, or drop to raw JSON. Start from a preset bundle.
Anomalies & fraud
Security alerts by severity, from Low to Critical, over the underlying signal events, screen-mirror, rooted, hooking, emulator, accessibility injection, each with its verdict and reason codes.
Evidence & proof ledger
The verified action ledger: JWS-signed proofs with nonce and signature-verification status, alongside authoritative-tier outcomes and their policy decisions. Export a proof bundle for audit.
Analytics & latency
Tier counters (lifetime and monthly), action volume over time, and per-phase latency at p50 / p95 / p99 with an outcome and error-code breakdown. Toggle sandbox and production.
Webhooks
Self-service configuration for five event types, a signing secret you rotate yourself, and a delivery table with HTTP status and retry count. Five exponential-backoff retries per event.
Access & roles
Per-seat access with owner / admin / developer / viewer roles. Invite and revoke teammates; every read stays scoped to the tenant, dual-gated at the datastore.
Usage & entitlements
Your contracted rate against what you are actually spending, editable alert thresholds, and your enterprise add-ons. The bill is a fixed annual price set by that rate; volume is recorded for the ledger and never meters your invoice.
Built to be checked by the people who'll challenge it.
Auditors, regulators, courts. The ledger is designed so they can verify it without taking Yuthent's word for anything, or calling a Yuthent API.
Externally timestamped
Every authoritative action is threaded through an RFC 3161 Time-Stamping Authority. The token is signed by a key the operator does not hold, so nobody, Yuthent included, can backdate or reorder the ledger. Choose your TSA (freetsa, DigiCert, GlobalSign) or bring your own.
Hash-chained
Each action chains to the one before it and rolls into a daily anchor. Alter a single entry and every entry after it breaks. The ledger stores only hashed identifiers, no PII.
Verify without calling us
The ACK public key is published at a /.well-known endpoint with rotation. Your backend, a regulator, or a court can verify any proof and the whole chain against a pinned root, offline, independent of Yuthent.
What an operator sees on day one.
enrolled devices
12,847
approvals (24h)
94,210
declined (24h)
412
revoked (24h)
7
recent activity
Illustrative. The tenant portal UI is scoped to the tenant and shown under NDA during first deployments.
Plugs into the stack you already run.
Outbound events to your SIEM. Inbound decision hooks from your fraud stack. Audit export to your storage. Revocation by API. No vendor lock at the operational layer.
Webhooks
Outbound events, device.registered, proof.verified, proof.rejected, fraud.alert, trust.signal.reported, into your SIEM or event bus, with five exponential-backoff retries.
External decision callback
Your fraud engine injects a verdict at verification time, step-up, downgrade, or soft-block, without any SDK change. Authenticated with your callback secret.
BigQuery audit export
A daily export to your own Google Cloud Storage bucket. You own the retention policy, the encryption, and the access control.
Published verification keys
The ACK signing key is served at a /.well-known endpoint as SPKI and a rotating JWKS keyset. Your backend, an auditor, or a court verifies proofs without ever calling Yuthent.
Revocation API
Revoke a device by identity or hash; the revocation propagates to the endpoint by push. The device cannot produce a valid proof at any tier, at any later time.
We block on cryptography. You decide everything else.
The SDK refuses on exactly four cryptographic failures. Every other signal is collected, signed and reported to your policy engine, which returns the verdict. Banks own fraud policy under PSD2 and DORA, so the SDK does not overrule them.
The SDK refuses
Four signals · non-negotiable
- Biometric binding integrity
- Attestation chain validity
- Hardware-backed key integrity
- Monotonic counter / replay
If any of these fail, the chain of custody is broken and no proof can be honest. There is no policy override.
Your policy decides
Collected · signed · reported
Evaluated by your tenant policy, a tree of AND / OR / NOT over signal atoms, edited in the portal and versioned per tenant.
APPROVE
Signals inside policy. The action proceeds.
STEP_UP
Escalate the tier and require a fresh human press.
DENY
Refused, with the evaluated signals recorded.
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. A tenant cannot see another tenant, and the Yuthent team cannot see tenant data without explicit support consent, logged.
The control plane is architected for DORA operational resilience and designed for PSD2 SCA Dynamic Linking. EU AI Act Article 14 (meaningful human oversight) is satisfied by construction through per-action biometric-bound signatures. Article 14 carries exposure of up to €15M or 3% of global turnover. Full compliance posture is published on the Security page.
The Security Architecture Whitepaper covers the datastore model, authentication tiers, and data-retention policy in full. Available on request to senior security contacts.
The control plane, answered.
What is the Yuthent control plane?
It is the operational surface over every deployment: device forensics, enrollment and attestation, the trust-policy editor, an anomaly/fraud view, the evidence and proof ledger, analytics and latency, webhooks, access and roles, and billing. Operators revoke a device in one click and export a proof bundle that verifies against a published public key.
Who operates it?
Three roles from one surface: the tenant administrator configures and operates, security operations triages anomalies and revokes devices, and compliance/audit exports the immutable ledger. Access is owner / admin / developer / viewer, and every read is scoped to the tenant, dual-gated at the datastore.
How do devices enroll?
Two paths, both issuing a signed, device-bound grant to prevent relay: in person by QR code, or over a remote video link. Enrollment verifies Play Integrity / App Attest, binds a hardware key, and snapshots the device posture, key-storage level, boot state, and root / emulator / hooking flags.
Is the action ledger tamper-evident?
Yes. Every authoritative action is hash-chained to the previous one, rolled into a daily anchor, and threaded through an RFC 3161 Time-Stamping Authority. The timestamp token is signed by a key the operator does not hold, so nobody, Yuthent included, can backdate or reorder the ledger. You can choose your TSA or bring your own.
Can we verify proofs without calling Yuthent?
Yes. The ACK signing key is published at a /.well-known endpoint as SPKI and a rotating JWKS keyset. Your backend, an auditor, or a court can verify any proof's signature and the ledger's hash chain against a pinned root, offline, without calling a Yuthent API.
Does it replace my SIEM or fraud stack?
No. Webhooks stream approvals, declines, revocations, and fraud verdicts into your SIEM or fraud platform, and the external-decision callback lets your fraud engine inject a verdict at verification time. It composes with what you run; it does not replace it.
Is tenant data isolated?
Yes, enforced at the datastore, not the UI. Every read and write carries the authenticated tenant identity. A tenant cannot see another tenant, and the Yuthent team cannot see tenant data without explicit, logged support consent.
Want to see it operate on your data?
First deployments begin with a scoping call and ship a working integration on one critical flow. The control plane is live from day one. The first proofs you see will be your own.