How to accelerate onboarding and achieve full app coverage in your IGA program

In this article:

When modern, automated identity governance and administration (IGA) systems work well, it's a dream — fast, efficient, and safe.

With a few clicks of an administrator's mouse, a new employee quickly gains access to the systems and applications they need to do their job. If the employee moves to another position, the IGA system reconfigures their access profile to fit the new role.

And when the employee leaves the company, IGA smoothly logs them out of the email system, revokes access to apps and makes sure their domain login no longer works.

But some 40% of applications aren't compatible with the application-program interfaces (APIs) or protocols that make this possible. IT teams instead have to manage those apps with cumbersome, clunky workarounds. These manual, error-prone processes lead to higher risks of security compromise and compliance failure.

However, there are solutions that make it possible to extend automated lifecycle management and the other benefits of IGA to all applications, even those lacking the proper APIs and connectors. Here's what these solutions provide and how they work.

Why IGA tools don't work with all apps

The applications most likely to work with modern IGA systems are newer, cloud-based and enterprise-focused. Those least compatible with IGA tend to be consumer-focused, older, and/or installed on-premises.

For example, many online social-media services can't interface with IGA systems because they were designed for single users as personal services. That's great for the consumer, but a huge hassle for an organization that uses social media for marketing and publicity.

Marketing teams must share a single set of credentials for each app, passwords and password updates may be stored on unsafe spreadsheets or cloud-based text files, and multi-factor authentication becomes a needless complication rather than a necessary safeguard.

"One account holder tends to share access by sharing those credentials directly with other employees or perhaps a third-party partner like an ad agency or a social media partner," says Bora Repishti, Vice President of Marketing at Cerby.

"One thing we want to make IT and security teams aware of is that these apps are business-critical and they present real risks, even though they don't have sensitive data that hackers might want to get to."

Many modern applications use one or more of four common standards to interact with IGA and IAM systems:

"The standards make it much easier to integrate," says Aaron Yee, Head of Product Marketing at Cerby. "If the apps themselves do not support standards and every single app is a one-off, it becomes very expensive for identity providers and IGA vendors to try to build custom connections, if they can at all, to those apps."

Speaking of expensive, there's also what identity professionals call the "SSO tax" — the extra fees than some application providers charge clients so that their apps will work with the single sign-on schemes offered by modern identity and access management (IAM) systems, as well as with IGA systems.

"These vendors realize that they can charge a premium for having SAML and SCIM support," says Repishti. "The premium is oftentimes upwards of five figures, sometimes six figures."

Those extra charges may deter many smaller organizations from opting for the more expensive, but safer, versions of applications.

Beyond those protocols, individual application developers and providers may include specialized APIs to interact with Okta, Microsoft Entra ID, or other widely used identity-management systems. But again, there may be an upcharge, even if the APIs or connectors are part of a larger bundle of options.

"What the vendors typically do is they're not charging just for SAML and SCIM," says Repishti. "They're bundling in other features as well that may not even be security-related."

The risks of leaving apps out in the cold

If your organization, like most, has some applications covered by IGA and others not, it can be quite a mess. First, as mentioned in the social-media example above, the IT team will spend much more time administrating the "disconnected" apps than the properly connected ones.

"If the app doesn't support a standard such as SCIM," says Matt Chiodi, Chief Strategy Officer at Cerby, "then it makes it very difficult for the IGA vendors and the identity providers to send over a standard message to the app to say onboard an account, offboard an account, or update the account."

Each time a new employee joins the company, someone from IT will have to manually set up the new employee with each disconnected app.

If that's done properly, IT will issue the employee a set of passwords to use. If it's done improperly, the employee will be free to choose their own passwords, which may be weak or reused, and IT may also not have direct access to the accounts.

When the employee moves to a new position within the company, another whole set of app provisioning and deprovisioning, which could all have been done automatically with IGA, must instead be performed manually by IT staffers.

In the best-run companies, there's a fourth scenario: each employee's access will be periodically reviewed, often for compliance purposes, regardless of how long they've been in a particular job. That can be tough to do manually.

"What tends to happen is the application administrator has to extract a CSV file, basically an Excel file, from the application, clean it up and then go through it line by line trying to understand it, parse it and say, 'Yeah, this character should not have these five roles,'" explains Chiodi.

There's always the risk that the manual process overlooks a little-used app and the employee retains access despite no longer needing it, violating the principle of least privilege and creating an opening for an attacker to exploit.

The highest risks come when an employee leaves. Ever left a job and noticed that you still received company emails for a few weeks?

Many companies are slow to deprovision leaving users, but that creates huge security risks. For example, a disgruntled former employee might exploit the extended access to attack the company, or a third-party attacker could break into a dormant email account.

"You don't want to have to have your team manually deprovision access," says Repishti. "Automate that as much as possible. That's what IGA tools and identity providers with lifecycle-management capabilities do."

The risks get even higher as companies use SaaS, cloud and online services that can be accessed from anywhere. You'd better hope that your marketing team changes the passwords on its social-media accounts when a member quits in a huff.

This tangled spectacle doesn't get any better when the auditors come around. If you work in a highly regulated industry like finance or healthcare, or if your company sells things online, humorless people clutching clipboards will be asking your IT and security operations teams difficult questions at least once per year.

"You want to have a good record of who has access to which applications and what sort of access," says Bel Lepe, CEO and Co-Founder of Cerby. "When you tie that in to a centralized identity tool like an IGA tool or an access management tool, you can see all of that access and you can govern it very cleanly."

If many of your applications aren't compatible with IGA and instead must be manually managed, good luck finding the logs that document every change and access made to those apps. You might fall out of compliance as a result.

How to bring all your apps into your IGA program

Ideally, what you want to do is bring all your applications, old and new, cloud and on-prem, enterprise and consumer-focused, under the protective umbrella of your IGA system.

You want to be able to quickly, securely and smoothly provision and deprovision joiners, movers and leavers regarding every application and service, and generate automatic logs of every access.

What do you do when an application doesn't support SCIM, OIDC or WS-Fed, or doesn't come with APIs to link up with the major IGA providers? You turn to a company that provides third-party APIs and connectors.

Cerby has hundreds of custom APIs to connect disconnected apps to IGA systems (and IAM systems) provided by Microsoft, Okta, Ping Identity, SailPoint, Saviynt and others. If necessary, it will create processes that can log in to the app themselves.

"If the app doesn't support APIs, we will look at the UI, do UI automation," explains Chiodi. "We'll simulate a user, an administrator, logging into the app, clicking through a series of buttons to the point where they deactivate the user or maybe onboard the user or make changes to the account."

The benefits of putting all your apps under the control of your IGA system are readily apparent. Not only will you greatly increase your security posture and improve your compliance, but your overworked IT team will be able to focus on more important things than manually configuring access for every new hire.

"When you've tied that into a centralized system that can control that, you offload your identity teams and your IT teams from having to manually log into an app every single time someone new joins the organization," says Lepe.