# How companies manage sign-ins to cloud apps

Companies choose by account type among single sign-on, password managers, privileged access management, managed browsers, and tools that never show passwords.

Updated: October 16, 2026

There's no single method for managing how people sign in to cloud apps. Companies combine several, and choose by type of account.

## What a company is trying to control

The goal is to decide who signs in to which account from which device, and to be able to check afterward who did what. NIST SP 800-53 Rev. 5, NIST's catalog of security controls, covers the account side of this under AC-2, account management. You define which account types are allowed, create and remove accounts by a set procedure, and get notified when someone leaves or changes jobs. When a person leaves a group that shares an account, you change that account's password. Enhancement AC-2(9) says to allow shared accounts only when they meet conditions you define, and its discussion warns of "the lack of accountability" they bring. CISA's Cybersecurity Performance Goals (CPG 2.0) cover related ground in goal 3.D, on revoking access for departing staff, and goal 3.H, on least privilege.

## Why one method doesn't cover every account

Some cloud app accounts can be issued one per person, and some can't. An identity provider, such as Okta or Microsoft Entra ID, keeps your staff's accounts in one place. When each person gets their own account and the app connects to the identity provider, [single sign-on (SSO)](/guides/access-basics/what-is-sso) handles it. Microsoft describes single sign-on as signing in once and reaching many apps, and lists SAML and OpenID Connect as the standards that connect them.

Several kinds of account don't fit that. Some apps don't support those standards, and some allow only one admin login. Social media and ad accounts may be used by a whole team. Short-term staff and contractors may have no account in the identity provider. For apps that don't connect, both Microsoft and Okta offer a separate feature that stores a password and fills it in. That's why one company ends up with accounts handled in different ways.

## The methods and what each one handles

| Method | What it handles | What it doesn't |
| --- | --- | --- |
| Identity provider and single sign-on | Your staff list, the sign-in check, and sign-in to apps that connect by SAML or OpenID Connect | Apps that don't connect |
| Identity provider fill-in (Okta SWA, Entra ID password-based SSO) | Entering a stored password on the sign-in page of an app that doesn't connect | People with no account in the identity provider |
| Password manager | Storing logins, filling them in, sharing them | Letting people use a login without being able to get the password |
| Privileged access management (PAM) | Requests and approval for admin rights, time limits, a record of use | Everyday work accounts |
| Managed browser (such as Chrome Enterprise) | Browser settings, extensions, limits on data leaving, reports | The sign-in itself |
| SaaS management tool | A list of the apps and accounts in use, adding and removing people as they join and leave | Checking who is signing in each day |
| Tool that fills in the password without showing it | Signing in for a verified person, and a record per person | The password the app still keeps |

The table leaves out some limits. Single sign-on doesn't reach people outside the identity provider. With a fill-in feature, the app's password doesn't go away. With a password manager, people you share a vault with can use what's in it; 1Password's vault permissions, for example, include viewing and copying passwords. The app's own log still shows the shared account's name, not the person. PAM tools differ in reach. Microsoft Entra Privileged Identity Management covers Entra ID, Azure and other Microsoft online services. So check whether a product covers the admin consoles you open in a browser. A managed browser doesn't track who knows a shared password. A tool that fills in the password without showing it works with any app that has a sign-in page, and can include people who aren't in your identity provider.

On managed browsers, Google's help center says Chrome Enterprise Core lets admins enforce Chrome policies, block extensions and view reports from a cloud console. Users don't have to sign in to a Google Account for the policies to apply. Chrome Enterprise Premium adds controls on copy and paste, uploads, downloads and printing. It also adds access rules that weigh the user, the device's state and location. On SaaS management, BetterCloud's site, for example, lists finding apps IT doesn't know about, cutting unused subscriptions, and automating onboarding and offboarding.

More on each method:

- [What is an identity provider (IdP)?](/guides/access-basics/what-is-idp)
- [How to get SSO-like sign-in for SaaS apps without SAML](/guides/access-basics/sso-like-operation-for-non-saml-saas)
- [What is a password manager?](/guides/shared-accounts/what-is-password-manager)
- [What is privileged access management (PAM)?](/guides/privileged-access/what-is-pam)
- [What is a secure browser (enterprise browser)?](/guides/access-basics/what-is-secure-browser)

## Options for personal devices

When people use their own devices, device-side options come into play. Microsoft Intune's documentation separates two modes. Mobile device management (MDM) enrolls and manages the whole device. Mobile application management (MAM) covers just the work apps and their data. Microsoft calls MAM typical for personal devices, and says that when someone leaves you can wipe the company's data without touching personal content. A virtual desktop runs the desktop or apps in the cloud and shows them on the person's device. Azure Virtual Desktop users connect through an app or a web browser.

NIST SP 800-46 Rev. 2 sorts remote access into four types: tunneling (a VPN), portals, remote desktop access, and direct access to an app. A web app opened in a browser is the last kind. It notes that data can end up on a device by accident, through browser caches for example. It asks each organization to make its own risk-based decision about which devices get how much access. One example it gives is letting company PCs reach many resources and personal phones only one or two low-risk ones, such as webmail.

## Where to start

Start by listing the cloud apps and accounts you use. For each, note whether it can be one account per person and whether it connects to your identity provider. Also note whether it stays shared, whether everyone who uses it is in your identity provider, and whether people use it from personal devices. With that list, you can see which row of the table fits each account. [How to take inventory of shared accounts and what to record](/guides/shared-accounts/shared-account-inventory) covers what to record.

Next, move the accounts that can be one per person and that connect to your identity provider onto single sign-on. Then decide how to handle the ones that don't connect and the ones that stay shared. For shared accounts, choose how you'll meet the conditions you set under AC-2(9), and how you'll show who used each one. Choices include the identity provider's fill-in feature, a checkout log that records who took the login and when, or a tool that fills in the password without showing it. [Shared admin logins that remain when you use Okta or Microsoft Entra ID](/guides/privileged-access/idp-and-remaining-shared-admins) covers what's left with an identity provider in place. [How to handle admin logins for domain, DNS and payment consoles](/guides/privileged-access/non-saml-admin-consoles) covers consoles that can't connect.


## Articles in this guide

- [What's the difference between an audit log and audit evidence?](/guides/access-basics/audit-log-vs-evidence): An audit log is what a system records. Audit evidence is a log you can rely on: tied to a person, protected from change, kept for a set period, and reviewed.
- [What a browser extension can and can't control in access management](/guides/access-basics/browser-extension-access-control-scope): An extension works inside the browser it's installed in, on the sites it's allowed to run on. Other apps, other browsers and other devices are out of its reach.
- [What work data stays on a personal computer, and how to keep it off](/guides/access-basics/byod-leave-no-business-data): History, cookies, saved passwords, password manager copies and downloads. Pair company browser settings with logins that don't show people the password.
- [Options for letting staff use personal devices for work systems](/guides/access-basics/byod-options-mdm-vdi-browser): Device management (MDM), app management (MAM), a virtual desktop, a managed browser, or sign-in that hides the password. They differ in what they control.
- [How to choose a way to record work on screen](/guides/access-basics/choosing-session-recording): Decide first what the records are for, such as reports, incident reviews or audits. Then check scope, format, retention, viewers, notice and cost for that use.
- [Types of tools for managing SaaS accounts, and how they differ](/guides/access-basics/comparison-of-access-management-tool-categories): Identity providers, password managers, PAM, enterprise browsers, SaaS management tools, and access management tools, compared on five points.
- [How Microsoft Entra ID and Junify differ, and when password-based SSO is enough](/guides/access-basics/entra-id-and-junify): If everyone using a shared account has an Entra ID account, guests included, and you need no control after sign-in, Entra ID is enough. Junify covers the rest.
- [Applying least privilege to shared SaaS accounts](/guides/access-basics/least-privilege-for-shared-saas-accounts): A shared login gives everyone with the password the same rights. Split roles in the service first. Where sharing stays, limit who and how long, and log use.
- [How Okta and Junify differ, and when Okta's SWA is enough for shared accounts](/guides/access-basics/okta-and-junify): If everyone who uses a shared account has an Okta account and you don't need control after sign-in, Okta's SWA is enough. Junify covers the other cases.
- [QR code sign-in and how well it resists phishing](/guides/access-basics/qr-code-login-and-phishing-resistance): You scan the computer's QR code with a phone app that's signed in, then approve. No password is typed, but approving someone else's QR code lets them in.
- [Which work can move from a virtual desktop to the browser](/guides/access-basics/replacing-vdi-for-web-work): Work done entirely in web apps moves most easily. Decide how files are handled before moving work that uses local files, and keep desktop-app work on VDI.
- [How to block or limit file downloads from SaaS apps](/guides/access-basics/saas-download-restriction): Block downloads in app permissions, only on unmanaged devices, or in the browser. Cover the rest with rules on who may export, where files go, and a record.
- [Why people can stay signed in to SaaS apps after you disable them in your identity provider](/guides/access-basics/saas-sessions-after-offboarding): Disabling someone ends the identity provider's own sign-in and blocks new ones. Each app's own sign-in lasts until it expires or that app ends it.
- [How to get SSO-like sign-in for SaaS apps without SAML](/guides/access-basics/sso-like-operation-for-non-saml-saas): Use your identity provider's password fill-in, a password manager vault, or a tool that signs in for people. They differ on who knows the password.
- [What is an identity provider (IdP)?](/guides/access-basics/what-is-idp): An identity provider (IdP) keeps staff accounts in one place, checks who is signing in, and sets who may use each connected app. Okta and Entra ID are examples.
- [What is the principle of least privilege?](/guides/access-basics/what-is-least-privilege): Least privilege means each person, and each program acting for a person, gets only the access their assigned work needs. NIST lists it as control AC-6.
- [What is multi-factor authentication (MFA)?](/guides/access-basics/what-is-mfa): Multi-factor authentication (MFA) checks who you are with two or more types of factor (something you know, have or are), so a password alone isn't enough.
- [What is passwordless sign-in?](/guides/access-basics/what-is-passwordless): Passwordless sign-in proves who you are with a key on your device, not a password. Passkeys are the main example. Fill-in tools still use a password.
- [What is a secure browser (enterprise browser)?](/guides/access-basics/what-is-secure-browser): A secure browser, which vendors such as Island call an enterprise browser, is a browser your company manages so it can block downloads, printing and copying.
- [What is session recording?](/guides/access-basics/what-is-session-recording): Session recording keeps what someone did between sign-in and sign-out, as video, text or events. Coverage varies by product, and some states require notice.
- [What is single sign-on (SSO)?](/guides/access-basics/what-is-sso): Single sign-on (SSO) lets you sign in once and open all the apps you may use. It works only with apps that connect to your identity provider.
- [What is zero trust?](/guides/access-basics/what-is-zero-trust): In zero trust, being on the company network earns no trust. Each request is checked for who is asking and from what device, then gets only the access it needs.

## Frequently asked questions

**If we set up single sign-on, can we stop managing passwords?**

For apps that connect to your identity provider through standards such as SAML, yes. Apps that don't connect, and shared accounts, still need a fill-in feature or another method.

**How is a password manager different from an identity provider?**

A password manager stores logins and fills them in, and people you share a vault with can use what's in it. An identity provider checks who is signing in and handles sign-in to the apps that connect to it.

**How do we let people use cloud apps on their own devices?**

Options include managing the whole device, managing only work apps, a virtual desktop, or a managed browser. NIST SP 800-46 Rev. 2 asks each organization to decide which devices get how much access.

**Where should a small company start?**

List the cloud apps and accounts you use. Then sort them into ones that can be one per person, ones that stay shared, and ones that connect to your identity provider.

## Sources

- [NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (AC-2, AC-2(9))](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf)
- [CISA: Cybersecurity Performance Goals 2.0 (CPG 2.0)](https://www.cisa.gov/cybersecurity-performance-goals-2-0-cpg-2-0)
- [Microsoft Learn: What is single sign-on in Microsoft Entra ID?](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/what-is-single-sign-on)
- [Microsoft Learn: Add password-based single sign-on to an application - Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-password-single-sign-on-non-gallery-applications)
- [Okta Help Center: SWA app integrations](https://help.okta.com/oie/en-us/content/topics/apps/apps-about-swa.htm)
- [Okta Help Center: Configure Single Sign-On options](https://help.okta.com/oie/en-us/content/topics/apps/apps_overview_of_managing_apps_and_sso.htm)
- [1Password Support: Create, share, and manage vaults in your organization](https://support.1password.com/create-share-vaults-teams/)
- [Microsoft Learn: What is Privileged Identity Management? - Microsoft Entra ID Governance](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure)
- [Chrome Enterprise and Education Help: Chrome Enterprise Core](https://support.google.com/chrome/a/answer/9116814?hl=en)
- [Google: Chrome Enterprise Premium](https://chromeenterprise.google/products/chrome-enterprise-premium/)
- [BetterCloud official site](https://www.bettercloud.com/)
- [Microsoft Learn: What is Microsoft Intune?](https://learn.microsoft.com/en-us/intune/intune-service/fundamentals/what-is-intune)
- [Microsoft Learn: What is Azure Virtual Desktop?](https://learn.microsoft.com/en-us/azure/virtual-desktop/overview)
- [NIST SP 800-46 Rev. 2, Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security (July 2016)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-46r2.pdf)

## How Junify handles this

**Doing this by hand** Single sign-on and multi-factor authentication don't reach apps that can't connect to your identity provider, or accounts that stay shared. Those are left to manual work, and you have to track for yourself which accounts the tools cover.

**With Junify** Junify is the last row of the table, a tool that fills in the password without showing it. An admin adds each login and assigns it to people, who confirm who they are on their own phone and click to sign in. Junify works alongside your identity provider and covers shared accounts and apps without single sign-on. On a personal computer, only the browser extension is installed.

Junify is an access management service for handing work in your web accounts to employees, contractors and outside teams without giving them the password. Each person verifies on their own phone and clicks a card to sign in. The password is never shown, and Junify records who used which account and when.

- [Try the demo](https://www.junify.com/bpo/try?lang=en&from=guide&cluster=access-basics)
- [Book a 30-minute demo](https://www.junify.com/bpo/demo)