Single sign-on (SSO) is undeniably great. Having a centralized place to manage employees’ access to enterprise SaaS applications is a huge advantage for any IT organization. SSO helps to streamline employee onboarding and offboarding efforts as well as least-privileged access management.
In short, single sign-on (SSO) is an authentication method that permits a user to use one set of login credentials to access multiple applications. And to be sure, SSO is an integral part of any modern SaaS identity and access governance program. But…is it the be-all and end-all solution for managing SaaS identities and protecting assets? I often hear IT and security leaders remark, “Well, once we get SSO fully deployed I won’t have to worry about that anymore.” While it’s a worthy endeavor, it feels like we might be chasing some mythical end state of SSO nirvana.
For anyone pursuing an SSO deployment, it’s important to understand some of the most common myths and misconceptions of SSO.
When teams begin their SSO enrollment journey, often there’s a hopeful naïveté that there is some future state where all applications are managed by SSO. Then, reality starts to sink in. Support for SSO widely varies, even among mainstream applications, and organizations often find themselves with business-critical applications that have limited SSO support. Further frustrating this future state is that organizations sometimes find themselves (understandably) unable or unwilling to pay the SSO tax for applications.
In discussing the employee offboarding process, many look to SSO as the “easy button.” (If 100% deployment was possible, this might be the case—see myth #1.) It’s absolutely true that kicking off deprovisioning workflows in SSO makes it easy to disable large swaths of accounts with little effort. But there is still work to be done! Simply disabling the account does not mean that critical resources associated with the account are migrated, that API keys or OAuth integrations are disabled, or that expensive SaaS licenses are necessarily freed up. Once you’ve disabled an account in your SSO provider, there is still essential work to be done within each app to ensure that you have fully and effectively offboarded the user.
In the world of IT security, rarely is there such a thing as a silver bullet, and SaaS identity and access governance is no exception. While SSO can help automatically create new accounts and aids in deprovisioning, there are a number of operational tasks to handle between those bookends of onboarding and offboarding. Regular access reviews and least-privileged access sanity checks are beyond the scope of most SSO solutions—or cost more money to integrate. When it comes to managing authorization, in terms of what role, entitlements, or data a user can access, this must be handled within each SaaS application itself, which requires additional administrative bandwidth for each application.
Only kind of. Rolling out SSO does take a few months—but then you are just getting started. Identifying and enrolling your critical apps into SSO and migrating the accounts can take a couple of months. But your SaaS footprint is constantly changing, as new apps are being adopted at breakneck speed. (In fact, we found that at midsize organizations, a new SaaS asset is added every 20 minutes on average.)
Once you have your essential enterprise applications onboarded, you still need a way to identify new SaaS apps that are being introduced into your organization, and need to be onboarded to SSO. Of course, the sooner you can get new apps onboarded to SSO the better—but most IT organizations struggle to keep up with the pace of employee-led SaaS adoption.
Often organizations prioritize their SSO onboarding efforts based on which applications have the most number of accounts. It stands to reason that the more people use a SaaS application, the more important it should be to onboard it to SSO. But that’s not necessarily the case. Instead, organizations would benefit from prioritizing SSO onboarding based on the criticality of the application. For example, a developer tool with five users that’s in scope of compliance should be onboarded before a graphic design tool like Canva, with 100 users.
In order to prioritize appropriately, organizations need to start with a complete and accurate inventory of all of their applications, including context regarding the criticality and classification of each application, not just the number of people using it.
There is a lot to be gained from using SSO at scale, but there are a number of gotchas to consider if you are going to use it as the sole control for identity governance. When using SSO, you need to keep in mind that there will always be more to do. Whether it’s deprovisioning or access reviews that are outside of the functionality of SSO or the continuous SSO onboarding process, it is important to allocate time for this consistent management.
More importantly, SSO gives you visibility into the applications you know about—not the ones that you don’t. When planning your next app to onboard into SSO, you need some insight into what is important and what is being used in your organization. Similarly, when you are deprovisioning accounts, you need to cover all of your users’ accounts, regardless of whether they are managed with SSO.
Nudge Security was built to solve these challenges. Our product continuously discovers and tracks SSO status for all of the cloud and SaaS applications your workforce uses—managed or unmanaged. That means you’ll know the full extent of your SSO onboarding effort, and you’ll be able to track new apps as they’re added. Further, our purpose-built playbook helps you automate the tedious parts of SSO onboarding, initiating workflows with a simple nudge.
Start a free 14-day trial today to get a snapshot of our SSO onboarding status, and see how Nudge Security can complement and streamline your SSO initiatives.
