Managing Accounts for Apps Without SSO

Even after adopting SSO, one problem remains. A good portion of the apps your company uses still do not support SSO. In particular, smaller SaaS at home and abroad, older work tools, and certain vendor portals often do not offer standard SSO integration. And it is exactly in these apps that account management gets the sloppiest.

The quiet danger of shared accounts

Apps without SSO are usually managed like this: a team shares one account, and the password circulates written in a messenger or a spreadsheet. This approach has three problems.

First, you cannot tell who accessed it. Because the account is shared, even looking at logs you cannot pin down the actual user. Second, you cannot revoke access. If a member leaves and the password is not changed, access persists; if it is changed, everyone who remains has to share the new password again. Third, passwords float around in plain text. Passwords left in chat histories and documents are a classic leakage path.

Even companies that have passed an SSO review often leave this area untouched, because there is no obvious way to handle apps that cannot be connected with a standard protocol.

The credential vault and auto-login approach

The way to handle this problem is a credential vault and auto-login, commonly called SWA (Secure Web Authentication).

The core idea is this: keep the app's ID and password not with people but in an encrypted vault, and let employees log in without ever seeing the password directly. Login is handled by a browser extension that receives the credentials from the vault and enters them on the employee's behalf. From the employee's side it is a one-click login, and from the company's side the password never passes through human hands.

The benefits are clear. Passwords are stored encrypted and do not circulate through chat. Who accessed which app is recorded centrally. And when an employee leaves, you only cut off their access to the credential in the vault, so the hassle of rotating passwords across every app disappears.

What to consider when adopting it

• Are credentials stored encrypted, and who can decrypt them
• Can access be granted and revoked per individual user (the key to moving past the limits of shared accounts)
• Are login and access events recorded in audit logs
• Is the browser extension's permission scope limited to only what is needed

The last point especially matters. Auto-login, as convenient as it is, makes it easy for the extension to hold broad permissions, so it is safer to choose a product that minimizes the permission scope.

How AxiPass covers this area

AxiPass's SWA keeps the credentials of apps without SSO under Lockbox column encryption and provides auto-login through a browser extension. Credentials can be granted and revoked per user, so you can turn a shared account into individual-level access, and auto-login runs and credential-use events are recorded in the audit log. In-app activity records can be turned on as an option when needed. On logout, session termination propagates to the extension and the SWA session as well. Managing apps that connect via standard SSO with OIDC/SAML, and those that cannot with SWA, lets you gather all your internal apps under a single console.

If you want to see for yourself how even non-SSO apps are managed, you can check it when you start for free, and if you need an approach suited to your internal app landscape, talk to us.