SSH key lifecycle
Key pairs are stored, rotated and pushed through the Change Secret engine. Private keys stay encrypted inside the vault and are never exposed outside it, with a self-service reset workflow for the user.
Nobody holds the secret. Not even the vault administrator.
A privileged credential is only as safe as the number of people who can read it. OmniPriv vaults every secret and hands out access to the resource, never the password itself.
Rotation, validation, reconciliation and SSH key lifecycle run on a policy you configure rather than on somebody remembering. When a stored credential drifts out of step with the live asset, the platform notices and corrects it.
Credential vault · rotation policyLive
root @ prod-db-01
Password
••••••••••••••••••v11
- DiscoverFound on the asset
- VaultEncrypted, never shown
- RotateNew secret by policy
- PushAsset updated, no outage
- root@prod-db-01in progress
- deploy@linux_prod_01rotated 7h ago
- billing-api@Billing servicerotated 2h ago
- svc-backup@postgres_prodrotated 5h ago
Access to the resource, never the passwordillustrative
- users who ever see a raw privileged password
- 0users who ever see a raw privileged password
- lifecycle stages automated: discover, vault, rotate, push
- 4lifecycle stages automated: discover, vault, rotate, push
- credential lifecycle controls in this module
- 10credential lifecycle controls in this module
- encryption key hierarchy: KEK, DEK and SEK
- 3-tierencryption key hierarchy: KEK, DEK and SEK
The lifecycle, without the manual steps
Four stages, each automated, each with the handover between them handled by the platform rather than by a runbook.
- 1. Discover
Know what you are rotating
Privileged accounts are discovered across on-prem, cloud and hybrid environments, so the estate you rotate is the estate you actually have.
- 2. Vault
Nobody reads the password
Secrets are stored in an encrypted vault with layered key protection. No user ever sees a raw password, they authenticate through OmniPriv.
- 3. Rotate
On your schedule, not ours
Policy-driven rotation with configurable recurrence, rotation period and daily start time, applied globally, or per platform and per policy.
- 4. Push
No step left to a human
Updated credentials are pushed out to target assets after rotation, so dependent services keep running without a manual step or an outage window.
When a credential drifts, the platform notices
Out-of-sync credentials are the quiet failure mode of every vault. A password changes on the asset, the vault does not hear about it, and the next administrator to need it finds out the hard way.
- Credential validation, stored secrets are actively tested against the live asset rather than assumed to be correct
- De-sync resolution, a corrected password is pushed automatically the moment a mismatch is found
- Scheduled reconciliation plans detect and repair out-of-sync or lost passwords without external utilities
- MFA required before an updated credential can be viewed
- Full password history, versioned and available to approved users for a configured retention period
Reconciliation · root@prod-db-01illustrative
In the vault
••••••••a91f
On the asset
••••••••7c2e
Validating against the live asset
ValidateResolve de-syncReconcile on schedule
Keys, one-time passwords and shared groups
Three cases the simple rotate-and-store model does not cover well, and how OmniPriv handles each.
One-time passwords
Single-use credentials that rotate the moment they are used, so a password observed in transit is worthless by the time anybody could try to reuse it.
Password groups
Where several accounts genuinely must share one value, they are grouped, an update propagates instantly to every linked account instead of being applied one at a time.
Bulk onboarding
Mass enrollment of privileged entities, with built-in accounts, privileges, rights and permissions provisioned to your organisational standards rather than left at defaults.
Reachable from anywhere, including offline
Credentials are not much use if the person who needs one cannot reach the vault. Neither are the ones on hardware that is rarely plugged in.
Mobile client
No app to install
A built-in mobile browser client with TOTP two-factor authentication, ticket approvals and role-based vault access.
Offline devices
Credentials for hard-to-reach kit
Devices that rarely connect to the corporate network still have their credentials managed, maintained and kept ready for the day they do.
Account lifecycle
Provisioned to deprovisioned
Privileged accounts are provisioned, modified and deprovisioned from one control plane, so a leaver does not leave a working credential behind.
Put the secrets somewhere nobody can read them
- Vaulted
- Rotated
- Validated
- Never handed over
OmniPriv vaults, rotates, validates and reconciles every privileged credential, and hands out access instead of passwords.
We will walk through rotation policy, SSH key lifecycle and de-sync handling 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 DemoIt is the scheduled replacement of privileged passwords, SSH keys and API tokens by the platform itself, rather than by an administrator working through a list. OmniPriv applies a policy with a configurable recurrence, rotation period and daily start time, globally or per platform and per policy.
OmniPriv tests stored secrets against the live asset rather than assuming they are correct. When a mismatch is found, the corrected password is pushed back automatically. Scheduled reconciliation plans also detect and repair out-of-sync or lost passwords without needing external utilities.
No. Credentials are held in an encrypted vault with layered key protection, and users authenticate through OmniPriv rather than being shown the secret. Where a credential has been updated, viewing it requires MFA first, and history is versioned for a configured retention period.
Key pairs go through a full lifecycle rather than a simple rotation: they are stored, rotated and pushed through a dedicated Change Secret engine. Private keys remain encrypted inside the vault and are never exposed outside it, and there is a self-service reset workflow for the user.
Those are handled as password groups. When several accounts must hold the same value, grouping them means an update propagates instantly to every linked account instead of being applied one by one, which is where shared passwords usually fall out of step.
