How Cloud Web App and SaaS Usage Affect Employee Onboarding and Offboarding for Organizations

Managing identities for HR and GRC/Compliance departments is a challenging task, even for locally managed applications. Huge IDM, IAM, PAM and LDAP services span across the organization to allow every employee to access what they need, but nothing more. When an employee leaves the organization, these rights and roles should be revoked as quickly as possible.

“Ghost accounts” (or Shadow IT accounts) that are not removed or deactivated have led to serious breaches. If a disgruntled employee exploits this it may lead to a nightmare revenge story.

As difficult as it may seem for local accounts, they are governed via administrators and IT Security staff, so it is “only” a matter of right processes and tools to onboard employees, manage their identity lifecycle and revoke their rights once they leave.

What about Shadow IT?

Accounts created in third-party web applications and SaaS apps, using corporate emails and locally generated passwords (regardless if it’s user- or password manager-generated) are invisible to the corporate IT departments, so can not be managed. In the best-case scenario they might be kept safe within a local storage by employees, but their lifecycle is entirely at the mercy of individual employees.

These third-party apps may belong to important suppliers, such as the CRM, ERP, banking, social media, hosting environments, or other customer- or business-related SaaS applications that are key to an organization. Remember that only a handful of large SaaS providers allow integration via Azure AD or other identity providers, and they need to be implemented individually, requiring granular controls and rules. When such integrations are not in place or available, employees rely on using their business emails and passwords (and sometimes, even when integrations are complete).

Onboarding such accounts is quite difficult unless you share the same account among employees, which is usually a terrible practice because it makes offboarding someone nearly impossible. Thus, new employees are forced to create their own identities, new accounts, and new passwords for all apps they need to work with.

And this individual self-onboarding ad-hoc process is already placing a dent in IT security, zero-trust, and compliance efforts, as no central inventory is generated automatically about the existing accounts of such applications. This can only be solved using proper Shadow IT discovery.

Similarly, offboarding is quite a nightmare, as an average employee of several years of tenure probably doesn’t hold an airtight inventory of their own accounts, so even well-intended colleagues may leave behind ghost or Shadow IT accounts to live on forever. And if they mean harm or leave without a note, no one is there even to assess what they had access to, not to mention what exact credentials had been used (check out our password hygiene use case to see why this alone is crucial).

So, what can you do about all of this?

First of all, an inventory of applications and accounts must be maintained for every business unit and every department. Unsanctioned or unintegrated apps may still hold tremendous business value, but access to these may have an unforeseeable impact. Every compliance framework and industry recommendation starts with assessing your inventory. Scirge enumerates applications and accounts using a transparent, continuous, and centrally governed Shadow IT discovery. When someone joins the organization, Scirge can keep track of the lifecycle of all the accounts, not just the ones created or sanctioned via internal tools. Once an employee leaves, accounts that hold any value may be delegated to someone else, and may lead to ghost accounts haunting you after every employee leaves.

Remember that maybe only a few percent of these third-party apps and accounts are of very high value, but you have to multiply that for every single employee. Remember, your organization is only as secure as your weakest link, which in this case happens to be the same as the cheapest attack vector.