SaaS management is challenging from many perspectives. One of the challenges that IT teams face is whether to use a shared IT account to manage the various SaaS applications.

What is a Service Account?

A shared IT account, also known as a Service Account, revolves around the creation of a dedicated user that is not associated with any employee. This service account is shared among several team members, usually the IT team, to manage their SaaS tools. The name of the account usually looks like [email protected] or something similar.

In many cases, the service account credentials are shared among several IT team members using a password manager.

The motivation behind a shared service account is to manage integrations between two SaaS applications in which the integration is tied to a specific user.

In these scenarios, when the user that connected the SaaS application leaves, the integration will break. A service account creates a system user, that is never deleted, as it is not a real employee account, ensuring that those integrations are still up and running even when an employee leaves your IT team.

For example, if you decide to integrate Zoom with Hubspot, you would have to use a Zoom account with admin permissions to install this integration. If the user who installed the integration leaves and their G-Suite user is either suspended or deleted, the integration would break.

While this might sound like a silver bullet, you must understand the pros and cons of having a shared IT account.

Pros:

  1. Not dependent on a single employee – This is the main reason for creating this user. Since the account is not associated with any single employee, it removes the dependency on certain individuals for the continuity of critical systems or integrations.
  2. Shared with other IT team members – A service account can easily be shared with other team members. In most cases, the account password will be stored in a password manager. The account can also be created as a Group Account (or a Distribution List) allowing other IT employees to receive notification of emails received to that account.

Cons:

  1. Multi-Factor Authentication (MFA) not supported – Shared accounts don’t work well with MFA. MFA works only with a device associated with an employee. This may force you to disable MFA for this specific user.
    Considering the fact that this user has high privileges and is connected to critical systems, this is a big drawback.
  2. No audit trail – An Audit trail is important, especially for accounts with high privileges. Now, that a single account is shared by multiple employees, the value of the audit trail is lost since with a shared account you lose the information on which user took the service actions.
    A good audit trail is not to be taken lightly. In case of a security incident or human error, that audit trail could contain your only clue as to what happened.
  3. Larger attack surface – This one seems counterintuitive at first as fewer accounts with high privileges should result in a narrowing of the attack surface. However, service accounts, which are also often easily identified just by their names are the jackpot of hackers. An open browser session of the same account may now live simultaneously in multiple browsers making it easier for attackers to run XSS attacks or similar.
  4. The shared password must be changed when the employee leaves – Even when using a password manager to share the credentials of the service account among your IT team members, you should change the password once one of the employees who had access to that account leaves.
  5. Diffusion of responsibility – Diffusion of responsibility is a socio-psychological phenomenon where a person is less likely to take responsibility for any action or inaction when others are present. This also applies to shared accounts. People may lack accountability because the service accounts are associated with a group of people rather than with them personally.
  6. Risk of violating the ToS – Some teams see the value of using a shared service account from a cost-saving perspective. When using a pay-per-seat type of service, reducing the number of accounts you need saves money. Be aware that you might be violating the terms of service by doing this. Before doing this you should read the service’s terms and conditions.

Conclusion

Make sure you are aware of the security compromise you are taking when choosing a shared service account.

We recommend that a service account should only be used to integrate between two SaaS applications and not as a shared IT account.

If you’d like to gain better visibility into all users, whether individuals or service accounts, consider Torii—a SaaS Management Platform—designed to provide visibility, automation, and cost-savings in a cloud-first environment.

Manage your Saas with Torii