Elevated once.
Trusted for hours.
Privileged access management gets a person into the session. Everything after that is inherited. Yuthent holds the consequential action until it carries authority the named operator signed, on their bound device.
The session identifies. The signature authorizes.
One phone call to a help desk. Domain admin in forty minutes.
An attacker calls the service desk, passes the knowledge-based checks, and has an MFA factor reset onto a device they control. No malware. No exploit. From that point every control in the stack is working exactly as designed, and every action it permits is indistinguishable from the real administrator's.
Privileged access management vaults
Brokers the credential and opens the session. Once the session is live, the vault is not consulted again for the actions taken inside it.
Just-in-time elevation
Narrows the window but not the granularity. Inside an approved two-hour elevation, every action is equally permitted and equally unattributed.
MFA at login
Proves possession of a factor at one moment. Adversary-in-the-middle kits relay one-time codes inside their validity window; help-desk resets bypass the factor entirely.
Session recording and SIEM
Produces a description of what happened, written by the system that was fooled. It shows the action. It cannot prove who was at the keyboard.
Elevation stops being a state. It becomes a per-action fact.
Your existing PAM, IdP and RBAC stay. Yuthent adds a verification step your infrastructure calls before the consequential subset executes.
Classify the action
Your policy marks which operations require proof: production writes, secret access, permission grants, break-glass. Read-only and routine work is untouched.
Challenge the operator
At execution time the platform issues a challenge carrying the specific command and target to the operator's enrolled device.
Sign in hardware
Biometric verification runs in the secure element. A non-exportable key signs the challenge. A stolen session, a reset MFA factor and a relayed code all produce nothing here.
Chain the proof
The verified proof is appended to a hash-chained ledger, linked to this operator's previous entry. Retroactive editing breaks the chain visibly.
An artifact that survives the operator disputing it.
operator_key_id
The hardware key of the named individual. Not a shared account, not a role, not a jump-box session. A key that cannot leave the device it was generated on.
command_hash
The exact operation and target signed for. Approval of one command is not approval of a broader class.
user_verification
OS attestation that a live biometric was verified for this signature. Cannot be produced remotely, cannot be replayed from a prior press.
prev_hash
Links to this operator's preceding action. The ledger is append-only; altering one entry invalidates every entry after it.
server_ack
At the Authoritative tier, a synchronous server co-signature, so the record does not rest on device-side claims alone.
The operations worth proving.
Production and break-glass
Schema changes, data deletion, emergency access. The highest-consequence actions get the highest tier.
Secrets and key material
Retrieval, rotation and export. The proof shows which human pulled which secret, and when.
Permission and role changes
Privilege escalation is the attacker's second move. Requiring proof for the grant itself removes the quiet path.
Answered plainly.
Our engineers will revolt if they press their phone all day.
They will not be asked to. Tiering is the whole design. Passive covers routine reads with no interaction at all, Silent opens a short window for repeated low-risk work. In practice the Explicit tier lands on a small fraction of daily operations, the ones where an engineer would want the record to exist.
What happens during an outage, or when the device is unavailable?
You define the fallback and it is recorded as such. Low and medium tiers verify offline. For the top tier you can require a second enrolled operator rather than degrade to an unproven path, so the break-glass route still produces evidence.
How does this coexist with our PAM?
It sits behind it. PAM continues to broker credentials and sessions. Yuthent is called at the point of execution for classified actions. Nothing about your vault, IdP or directory changes.
Can an administrator suppress their own proofs?
No. The ledger is append-only and hash-chained. Deleting or editing an entry breaks every subsequent entry for that operator, which is detectable on verification. That property is what makes insider denial untenable rather than merely unlikely.
Put it on one flow first.
Tell us the action you need proof for. We come back with a working integration proposal and a signed sample you can verify yourself. First call within five business days.