Applying least privilege to shared SaaS accounts

Least privilege means each person gets only the access their work needs, for as long as they need it. On a shared account, that can’t be done person by person. The rights belong to the login, and everyone who knows the password gets all of them. What a shared account is, and why companies keep them, is in What is a shared account?

Why a shared login defeats least privilege

The definitions in NIST’s glossary narrow access for a user or an entity. CNSSI 4009-2022 limits each user’s privileges to their assigned tasks. NIST SP 800-53 Rev. 5 gives each entity only the resources and authorizations its function needs. Either way, the unit you narrow is the person or program doing the work.

A SaaS tool attaches rights to a login. When each person has their own login, narrowing the login narrows the person. A shared login has one set of rights and several people behind it. Whoever only needs to read reports still gets everything the login can do, including admin rights if it has them.

Microsoft’s Entra ID documentation lists what goes wrong with the traditional way of sharing, where the username and password are handed out. You can’t tell who has access, or who used it. To take someone’s access away, you change the password and send the new one to everyone else.

NIST doesn’t ban shared accounts. Control AC-2(9) allows them when they meet conditions you set, after weighing the “lack of accountability” they bring. IA-2(5) asks that people sign in individually before they get to a shared account. AC-2 k asks for a process to change a shared account’s password when someone leaves the group.

Split roles in the service first

So the first step is to move whatever you can off the shared login. Give each person their own login in the service and pick a role for it. Many business SaaS tools let you assign roles per person. Google Analytics, for example, has five:

Each role also has everything the role below it can do.

You give these roles per person at the account or property level, and a role given higher up carries down by default. Separate data restrictions hide cost or revenue metrics from someone regardless of role. For each person, write down what they do, give the lowest role that covers it, and keep Administrator to a few people. Platform-by-platform guidance is in the guides on Google Analytics 4 and Google Tag Manager, Google Ads manager accounts, Meta business portfolios and Shopify or BigCommerce stores.

Some logins can’t be split. A service may allow only one account, a company social profile is a single login by design, and some tools have exactly one admin. Those cases are covered in When shared accounts can’t be split into personal ones.

Three limits for accounts that stay shared

Where a login stays shared, you narrow three other things in place of its rights.

Who may use it

Name the people allowed to use the account and keep the list. Make the group of people who know the password no bigger than that list. You can’t narrow the login’s rights, but you can narrow how many people hold them. CISA’s goal 3.H, least privilege, covers every account in the organization, so shared ones count too.

For how long

Give access for the length of the assignment and remove it the day it ends. For a contractor, that’s the last day of the contract. CISA’s goal 3.D asks for a defined process to revoke all access when staff leave, contractors and vendors included.

What gets recorded

Record who used the account and when, separately from the service’s own log. The service’s log shows only the shared login’s name. IA-2(5) asks each person to sign in individually first, which also gives you a record that can name them.

The first limit has a catch. If people can use the account only by knowing the password, then the people allowed and the people who know it are the same list. Then every time someone leaves, you change the password and send it to everyone who stays. Some tools separate the two lists by filling in the password without showing it. Microsoft Entra ID, an identity provider (a company login service), does this with password-based single sign-on for people who sign in with their work account. Other tools do the same for people who have no account there. How the options compare is in Comparing ways for several people to use one shared account.

How to review access

NIST AC-6(7) asks you to review privileges at a frequency you set, and to remove or reassign the ones that are no longer needed. CISA’s goal 3.H recommends doing it every quarter. For SaaS accounts, the review has four steps:

1. For each service, list the personal logins and their roles, and the shared logins with the people allowed to use each. How to build that list is in How to take inventory of shared accounts and what to record.
2. For each person, check whether the role or shared login still fits their current work, and remove what doesn’t.
3. Use the record of who used what. A person who hasn’t used an account in months is a candidate for removal. CISA’s goal 3.D suggests disabling accounts that sit inactive for a set period, such as 30 days.
4. Update the list whenever someone joins, leaves or changes work, and review the whole list on the schedule you set.

Admin accounts get the strictest version of these steps; see What is a privileged account?