Standing
Admins keep permanent access “just in case”. Every such account is an open door for as long as it exists, whether or not anyone needs it.
Solution · By Challenge
Uncontrolled Privileged Access
Standing admin rights, shared passwords and sessions nobody recorded are how a small mistake becomes a breach. Securita360 vaults every credential, opens access only when it is approved, and records what happens, so privilege is temporary, controlled and provable.
- Vaultevery credential
- Approveevery request
- Recordevery session
admin@prod-db-01Privileged access over 30 days · sample data
Hours with live privilege720
Approvals0
Recorded sessions0
The problem
Privilege goes wrong in three ways
The most powerful accounts in your estate are often the least controlled.
Shared
Root and service passwords live in spreadsheets, chat threads and people's heads. They are copied freely and rarely changed.
Invisible
When something breaks or leaks, nobody can say who logged in, why they did, and what they did once inside.
How privilege goes wrong
Six gaps, and how each one is closed
Passwords in spreadsheets and heads
How it goes wrongRoot and service passwords live in spreadsheets, chat threads and memory. They are copied freely and rarely changed.
Closed withAn envelope-encrypted vault (AES-256-GCM). The plaintext is never returned by an API, logged or shown. Safes, versioned credentials, and dual control on the safes that need it.
Admins with permanent access
How it goes wrongStanding rights kept “just in case”. The door stays open whether or not anyone needs to walk through it.
Closed withTime-boxed requests with a reason and an optional ticket reference, approval chains, auto-expiry checked again at launch, and live sessions ended when a grant expires or is revoked.
Passwords nobody changes
How it goes wrongThe same shared password for years, because changing it means breaking something.
Closed withOn-demand rotation: change on the target, verify the new password works, then commit it to the vault, with a history of every attempt. Linux and Unix over SSH today.
Passwords people can copy
How it goes wrongOnce someone has seen a password they can keep it, paste it and share it.
Closed withBrowser-based SSH and RDP sessions. The gateway injects the credential server-side, so there is nothing to install on the target and no password for the user to copy.
Risky commands run unchecked
How it goes wrongOne typo or one bad intention on a production server, and nothing stops it.
Closed withA command policy for SSH sessions that allows, warns on, denies or terminates by rule, records every command, and alerts your webhook, email or SIEM.
No proof of who did what
How it goes wrongWhen something breaks or leaks, nobody can say who logged in, why, or what they did.
Closed withEncrypted session recordings with playback behind a fresh authorization, and a hash-chained audit trail exported to your SIEM in CEF format.
How Securita360 closes them
Identify. Secure. Control. Prove.
Four steps on one platform, from the person asking for access to the evidence of what they did with it.
Step 1 · Identify
Know exactly who is asking
- Role-based access control keeps every user to the permissions they need.
- Sign in through your LDAP directory, with authenticator-app (TOTP) multi-factor authentication.
- Sign-in, MFA and logout events go into the audit trail.
Step 2 · Secure
Take credentials out of people's hands
- Every credential is envelope-encrypted with AES-256-GCM. The plaintext is never returned by an API, logged or shown.
- Safes and versioned credentials, and dual control on safes that need two distinct approvers.
- On-demand rotation changes the password on the target, verifies it, then commits it to the vault.
Step 3 · Control
Give access when it's needed, and only then
- Users request time-boxed access with a reason and an optional ticket reference. Approvers decide, and the grant expires on its own.
- Browser-based SSH and RDP sessions, with the credential injected server-side.
- Session policy limits protocols, source networks, time windows and concurrent sessions, and can show an access banner.
Step 4 · Prove
Show what happened
- Sessions are recorded and envelope-encrypted, and played back only through a fresh, per-request authorization.
- Every action is written to a hash-chained audit trail, checked on a schedule, with an alert if it breaks.
- Events export to your SIEM in CEF format over syslog or a webhook.
Just-in-time access
Request it, approve it, and watch it expire
Choose an approval chain, then try to break the rules: edit a request after it is approved, revoke a live session, or go around approval with break-glass.
Access request
Alex wants admin access to prod-db-01
What happens
Each step is enforced by Securita360, not by convention.
Request submitted
Approval
Grant issued
Session launched
Session live
Access ends
Illustrative. Approval chains, durations and caps are configured in Securita360. Sample data.
Command control
Stop the risky command, not the whole team
Run commands in a sample SSH session against a sample policy. Rules are checked in order, and the first match wins.
Sample command policy
Evaluated when Enter is pressed in an SSH session
- REGEX
^rm\s+-rf\s+/TERMINATE - EXACT
cat /etc/shadowDENY - REGEX
^systemctl\s+stop\s+firewalldTERMINATE - EXECUTABLE
sudoWARN
No rule matches: ALLOW The command runs and is still recorded.
Pick a command to run it against the policy.
Illustrative. Command control covers SSH sessions, and violations alert your webhook, email or SIEM. Sample data.
Tamper-evident audit trail
Try to change history
Every event is chained to the one before it. Pick an event, tamper with it, and see whether the chain notices.
Hash-chained eventsScheduled integrity checkAlert on a breakSIEM export · CEF over syslog or webhook
Illustrative. The hashes shown use a simple stand-in to demonstrate how chaining works. Sample data.
What changes
When privilege is temporary and provable
Privilege that expires
Access exists only inside an approved window, so there is no standing door to leave open.
Nothing to copy or share
Credentials stay in the vault and are injected server-side, so there is no password to paste into a chat.
Faster investigations
Every session is recorded and every action is in one audit trail, so “who did that?” has an answer.
Evidence on demand
Hash-chained audit events and SIEM export give auditors something they can check.
Built with
The platforms behind this solution
Securita360
Privileged access management
Vault, just-in-time access, browser-based sessions, command control, recording and a tamper-evident audit trail.
ITDesk
IT service management
Access requests can carry a ticket reference, for example an ITDesk incident or change, so every grant points at the work it was for.
Questions
Frequently asked
Do users ever see the password?
No. Credentials are stored envelope-encrypted (AES-256-GCM), and the plaintext is never returned by an API, logged or shown. Only launching a session or rotating a credential ever touches it, and both happen server-side.
Do we need to install anything on the target systems?
No. Sessions run through the Securita360 gateway from the browser, so SSH and RDP targets need no agent.
What if an approver isn't available?
Break-glass gives immediate access capped at 60 minutes, with a mandatory reason. It is audited as an emergency, and someone else must review it afterwards.
Can someone approve their own request, or change it after approval?
No to both. Nobody can approve their own request, and editing a request after approvals have been collected invalidates them, so approvers must approve again. Approval chains can run in parallel or in sequence, with delegation.
How does password rotation work, and what does it cover?
Rotation is on demand. Securita360 changes the password on the target, verifies the new one works, and only then commits it to the vault. If the change can't be verified, the job is flagged for reconciliation instead of reporting success. It covers Linux and Unix accounts over SSH today. Windows, database and network-device rotation are not covered yet, and rotation is not scheduled automatically.
Does command control cover every session?
It covers SSH sessions, evaluated when Enter is pressed, and every command is recorded even if no policy exists. Rules run in order and the first match wins. There are two blind spots: shell history recall and tab completion, and full-screen programs such as vim. RDP has no text command channel to inspect.
Can the audit trail be altered?
Events are hash-chained, so changing or deleting an older event is detectable. The chain is checked on a schedule and a break raises an alert. The chain can't vouch for the very newest event by itself, which is why events can also be exported to your SIEM in CEF format.
Which sign-in methods are supported?
Role-based access control, sign-in through your LDAP directory (configured at deployment) and authenticator-app (TOTP) multi-factor authentication.
Can it run in our own environment?
Yes. Securita360 is built to run on your own infrastructure, in containers, so credentials, recordings and audit data stay with you.
See it on your own systems
Find out who really holds the keys
Tell us about your environment and we'll show you Securita360 controlling access to it. No commitment required.