4-Eyes
Two independent approvers, minimum
Access is granted only once a minimum of two independent approvers sign off. The requester is excluded from the approval path by design, so a privileged request can never be self-approved.
Nobody approves their own access.
The 4-eyes principle is the floor here, not a feature. A minimum of two independent approvers is required before privileged access is granted, and no user can approve their own request.
From that starting point the workflow bends to how your organisation actually approves, multi-level chains, decisions made from a phone or an email link, and rules that change with the time of day, while privileged accounts are handed out with an expiry date attached.
Access request · 4-eyes workflowLive
j.rahman requests dba
on prod-db-01 · for 2 h
j.rahman cannot approve their own request
1s.khan approves from mobile
2m.ortiz approves from an email link
Waiting for both levels to complete
Access window2 h
Two independent approvers, every timeillustrative
- independent approvers, minimum, on every request
- 2independent approvers, minimum, on every request
- self-approvals possible: the requester is excluded
- 0self-approvals possible: the requester is excluded
- credential locations cleaned, config files to IIS App Pools
- 6credential locations cleaned, config files to IIS App Pools
- API access controls: RPS, IP/CIDR, time and usage limits
- 4API access controls: RPS, IP/CIDR, time and usage limits
Approval, not assumption
Approval is a step the platform enforces, not a convention teams are trusted to follow voluntarily.
Anywhere
Approvals from mobile or email
Requests, approvals and credential retrieval all work from a mobile device. Approvers can act through the web GUI, a mobile client, or an email link directly, no login into the console required.
Multi-level
Chains that finish each step
Approval chains are configurable and multi-level, with multiple approvers supported at each step. Every level has to complete before the request progresses, so no stage can be short-circuited.
Privilege with an expiry date
Standing privilege is the thing most organisations regret. OmniPriv grants account authorisation for a defined timeframe and a specific target asset, which turns revocation from an administrative task into an automatic consequence.
Because the entitlement is expressed as an ACL-based mapping rather than a note on a ticket, expiry is enforced in permissions, the account reverts to its standard restricted state the moment the window closes.
- Account authorisation scoped to a specific timeframe and a specific target asset
- ACL-based mapping, so the entitlement is enforced in permissions rather than described in text
- Automatic reversion to the standard restricted account when the window expires
- Workflows, policies and approval rules that respond to time-of-day and calendar-based conditions
Temporary assignment · prod-db-0108:00
Approved window, 10:00 to 15:00
08:0013:0018:00
ACL: j.rahman → dba @ prod-db-01
Standard restricted account
Rule: business hours onlyTarget: one assetAuto-revert on expiry
Credentials that stop living in config files
Hard-coded application passwords are the ones no rotation policy ever reaches. OmniPriv takes them out of the places they hide and rotates what replaces them.
Credentials removed from
Config filesDatabasesRegistriesWindows ServicesScheduled tasksIIS App Pools
Applied to every token request
RPS limiterClient IP / CIDR allowlistTime limitUsage limit
app/config/database.ymlHard-coded secret
production: host: orders-db.internal user: app_orders password: "Summer2019!"password: omnipriv.get("orders-db/app") # rotated automatically, retrieved with zero added latency
Application credential management
Hard-coded credentials are eliminated from configuration files, databases, registries, Windows Services, scheduled tasks and IIS App Pools, with automated rotation replacing manual change windows.
Zero-latency retrieval
Critical applications retrieve credentials without added latency and without relying on a remote repository, so removing hard-coded secrets does not cost performance.
Applications are authenticated too
Every application that requests credentials is authenticated, and protected against unauthorised changes, so the credential cannot be intercepted by tampering with the caller.
API rate and access controls
Application token requests can be constrained by an RPS limiter, a client IP or CIDR allowlist, a time limit and a usage limit, applied to every request rather than sampled.
Put two approvers between the request and the credential
- Approved by two
- Granted for a window
- Reverted on expiry
Approved by two independent people, granted for a defined window, then reverted automatically, with application secrets rotated instead of hard-coded.
We will walk through the approval model and the temporary assignment rules against your environment.
Frequently Asked Questions
Have a question that is not here?
Talk to the OmniPriv team about your identities, systems and AI agents.
Request a DemoAccess is granted only after a minimum of two independent approvers have signed off, and no user can approve their own privileged access request. The requester is kept out of the approval path entirely, so the separation of duties is structural rather than something the system merely discourages.
Yes. Privileged access requests, approvals and credential retrieval are all supported from mobile devices, and an approver can act through the web GUI, a mobile client, or an email link without logging into anything. That matters because an approval queue that only works at a desk becomes the bottleneck that gets bypassed.
Approval chains are configurable and can run several levels deep, with more than one approver permitted at each step. Each level has to complete before the request moves to the next, so an approval cannot skip ahead of a stage that is still outstanding.
Authorisation is granted for a specific timeframe and a specific target asset, and the mapping is ACL-based. When the window expires the account automatically reverts to its standard restricted state, the revocation is enforced in permissions, so it does not depend on anyone remembering to remove it.
OmniPriv eliminates hard-coded credentials in configuration files, databases, registries, Windows Services, scheduled tasks and IIS App Pools, and rotates them automatically instead. Applications retrieve credentials with zero added latency and no reliance on a remote repository, and every application requesting one is authenticated and protected against unauthorised change.
