Your team signs in once. They never see the password.
Shared portal logins end up in spreadsheets. Secure Vault keeps them encrypted, hands them out by group, and fills them in through a browser extension — masked the whole way, and recorded every time.
Built by Technomate IT-Solution.
However they reach the portal
The same credential, the same masking and the same record, whichever door they come through.
Sign in to the vault, and every portal assigned to you is on one page.
One click from the toolbar, on any tab, without opening the vault at all.
Names only, drawn where the site cannot read it
Already on the portal? The vault offers the login that belongs to that site, and fills it there.
Filled in front of them, still unreadable
No eye icon, anywhere. A credential can be used by someone who could not repeat it if they were asked.
They never even opened the vault
Reached the portal from their own bookmark? The badge appears in the field, offers the logins that belong to that site, and signs them in there.
Access you grant, not access you send
Group portals and people, or assign one straight to a person. Nothing to redistribute, nothing to rotate when somebody leaves.
Every sign-in, on the record
Each launch written down with the person, the portal, the address and the browser. Filterable, and exportable.
The second factor, handled for them
Authenticator codes from a stored secret, emailed codes read over IMAP. Nobody reaches for a phone.
Generated from the stored secret. Nobody reaches for a phone.
Read over IMAP from a mailbox you nominate.
Rules you set once
Network restrictions, enforced Microsoft sign-in, session lifetimes and idle limits — across the organization, a group, or one person.
Network rules apply to password sign-in, Microsoft SSO, the API and extension pairing alike.
What Secure Vault does
The credentials, the people who may use them, the rules around both, and the record of what happened.
Portal catalogue
Every portal you use, credentials encrypted at rest.
Groups and access
Group portals and people, then assign in bulk.
Authenticator codes
Generated from the stored secret at sign-in.
Emailed codes
Read over IMAP from a mailbox you nominate.
Microsoft Entra SSO
Sign in with a Microsoft work account.
Enforced MFA
Require Microsoft sign-in for an organization.
IP allow and block
Per organization, group or person.
One browser at a time
A new pairing revokes the old one.
Session and idle limits
How long a sign-in and an open portal last.
Walk-away protection
Cookies, local storage and databases cleared.
Audit timeline
Recorded per organization as it happens.
Login report
Filterable, and exportable as CSV.
Bulk import
Users from CSV, portals from Excel.
Self-service password
Changed without an administrator.
Your branding
Your logo across dashboard and console.
Licences and validity
Seats and dates enforced at sign-in.
SSO portals
Followed through the identity redirect.
Audited reveals
Time-limited, and written to the log.
Encryption, described honestly
Three things, protected three ways. The differences matter more than the word encrypted.
Your organization's catalogue
AES-256-GCM under a data key belonging to your organization alone, itself wrapped by the deployment master key. A leaked master key opens nothing on its own.
Stated plainly: because the service unwraps those keys to fill a portal for you, this catalogue is not zero-knowledge. That is the trade for credentials nobody has to know.
A person's own vault
Encrypted in the browser under a master password that is never stored or sent. PBKDF2 at 600,000 iterations; the server holds ciphertext it cannot read.
Account sign-in passwords
Hashed with scrypt at a high work factor and never recoverable — not by an administrator, not by us. Wrong attempts are throttled per account, not per address.
Wherever your team already works
One codebase, a build per browser, each installed the way that browser expects.
Chrome, Edge, Brave, Opera
A packaged build downloaded from your vault and loaded from the extensions page.
Firefox
Signed by Mozilla, so it installs in one click and keeps itself up to date.
Each person connects their browser once. A new pairing ends the previous one, so access never quietly accumulates across machines.
Questions, answered
Can our people see the portal passwords?
No. There is no reveal control in the dashboard or the extension, fields stay masked after they are filled, and copying out of them is blocked. An administrator can reveal a stored credential when they genuinely need to; that reveal is time-limited and written to the audit log.
What happens when somebody leaves?
You remove them, or deactivate them. Every browser and paired extension they used is signed out at once. Nothing has to be rotated, because they never knew the password.
Does it work with portals that ask for a code?
Yes, both kinds. Authenticator codes are generated from a secret you store once. Codes sent by email are read from a mailbox you nominate over IMAP, and entered automatically.
Which browsers are supported?
Chrome, Edge, Brave and Opera install a packaged build from your own vault. Firefox installs in one click from a Mozilla-signed build and keeps itself up to date.
Can we restrict where people sign in from?
Yes. Allow and block rules by network apply to password sign-in, Microsoft SSO, the API and extension pairing alike, and can be set for the whole organization, one group, or one person.
Is it zero-knowledge?
A person's own vault is: it is encrypted in their browser and the server cannot read it. The shared organization catalogue is not, because the service has to unwrap those keys to fill a portal on someone's behalf. We would rather say so than let you find out later.
Stop sending passwords around
We will set up your portals, import your people, and show you the audit trail on your own data.