Practical Survival Guide to Okta Lifecycle Management

If you’ve searched for this article, chances are you’re already familiar with Okta LCM: Okta Lifecycle Management (and perhaps with Crosswire’s take on why Your Okta Groups Should Be (Mostly) Empty). While you may have followed some initial steps to get started with Okta LCM, there’s no real technical usability guide as it stands.

Introducing Crosswire’s “Practical Survival Guide to Okta Lifecycle Management.”

1) New Employees (Onboarding): When setting up lifecycle management, make sure that API keys don’t expire and that they’re regularly rotated

The first step in any new employee/user’s life cycle is onboarding. When setting up Okta LCM, you can use API keys to bind access to Application Programming Interfaces and their methods — Okta has a whole blog post on how to obtain and use API keys here. If these keys are set to expire, this translates to broken onboardings (and offboardings), which defeats the purpose of using Okta LCM in the first place.

However, API keys are a risk if exposed because they can be used by whoever sees them, so regular rotation is part of risk reduction. While many suggest rotating your API keys every 90 days (or once a quarter), this number will depend on the security needs of your company. For example, you should have an established process for rotating these keys when offboarding an Okta admin or deprovisioning someone’s access. You often know your company best, and we strongly advise finding a rotation timeline that suits your needs.

💡 Note: If you do have expirations on your API keys, ensure they don’t expire between invocations. If you use the integration frequently, the expiry will become immediately apparent because it will break, and you will notice (and hopefully fix it). On the other hand, it can be hard to spot an expired API key with infrequent integrations (ones used less than quarterly), and you may not notice it until too late. If you have to use expirations, you should have a periodic test enabled for your integrations that sends an alert when it fails to prevent the expiration from going unnoticed.

Whether through periodic tests or eliminating expirations and switching to rotation-based mechanisms — as we suggest above — it’s important to prevent an integration from breaking when you most need it. Once you reduce the safety risks from your API keys, it’s important to continue implementing other measures to safeguard Okta API integrations — namely, securing your profile source and using dedicated system accounts).

2) Provision: Make sure your profile source is not Google and use dedicated system accounts

The next step in an employee’s lifecycle tends to be provisioning, starting with establishing the profiles you’ll need for your new employee(s). In that vein, we at Crosswire recommend that your profile source for these is not Google. The problem is that you want complete control over the source of your profile information to prevent accidental suspensions that would disrupt your business. With Google, this kind of control is difficult to achieve because it may automatically suspend accounts it deems “spammy,” which would propagate downstream and cause the person to be offboarded entirely. For example, if you have a Google admin account that sends numerous recruiting and sales emails, Google may suspend the account for spreading “spam.” Suspension can severely inhibit the organization, particularly if that admin is the only admin at your company. There are often numerous hoops to jump through to unsuspend the account, and meanwhile, progress has come to a halt. If you want to maintain control over your profiles but still want to be able to use Google workspace, you can easily use Okta as a profile source and propagate that information to Google!

In addition to securing your profile source, using dedicated system accounts for all Okta API integrations is paramount. Regular/personal user accounts are risky for a few reasons. For one, personal accounts, as the name suggests, are linked to a person. So, if that person leaves your company, you may lose access to the integration, or the integration may break. Likewise, that person likely actively uses their regular account for day-to-day work. Thus, the user has a higher risk of being phished or otherwise compromised, which will extend to all integrations the account utilizes (including your organization’s). The security risks involved with profile creation make it vital to safeguard your employee’s user profiles and extend this security to any third-party companies that have access to your company’s profile source/Okta (including MSPs).

3) Enforce: If you are working with an MSP, ask about their security practices to make sure your organization is safe

After safeguarding your user profiles through sound API practices and account creation, you should constantly enforce your access needs and security measures. These measures include continually implementing every user’s access needs (perhaps through an identity tool like Crosswire) and securing third-party companies that have access to your Okta instance — like MSPs.

Often when a company has more limited in-house IT capacity, it will hire an MSP (Managed Service Provider) to manage its IT infrastructure remotely. When working with an MSP, your company takes on the same risks your MSP does since it will usually have admin access to your Okta instance. For example, suppose your MSP isn’t taking adequate safety measures, and a staff account is compromised on their end. In that case, the compromise may extend to your company through the Okta accounts that the staff account can access. Hence, you should be comfortable with whatever steps they take to prevent this kind of account takeover. Ask your MSP about their general security practices, the measures taken to safeguard staff accounts, and their plan in case of a compromise. By enforcing these security measures, you can be confident in your organization’s infosec posture, even when you must update your users’ access needs over their tenure.

4) Update: Ensure the failsafe Import Safeguard option is checked (so you don’t accidentally deprovision the entire company)

While enforcing your original security plans is necessary, your user and company access needs will inevitably change later on. Whether it’s due to a user changing positions, leaving a project, joining/leaving a group, or taking leave, the access you provisioned at the beginning may need to be updated or deprovisioned at some point. You can deprovision a user through your AD (Active Directory) or directly within Okta, but when you do, it’s crucial to make sure that the failsafe “Import Safeguard” option is activated.

Without this checked, if you have an error in your Lifecycle Rules or a misconfiguration, you could accidentally deprovision your entire company without a way to “Ctrl+Z.” Enabling the failsafe option mitigates that risk and helps protect your organization’s information and productivity.

💡 You can follow these step-by-step instructions from Okta for more guidance on enabling this feature for yourself!

These updates are critical, especially when deprovisioning access for users that no longer need it but continue to be a part of your organization. However, if you’re deprovisioning access because a user is no longer a part of your organization, you should go beyond just deprovisioning access and move into true offboarding.

5) Offboarding: Do more than deprovision, release licenses!

Offboarding is the final step in any employee’s lifecycle when leaving your organization. This process will look different for every company, but it’s important to remember that only deprovisioning access is often insufficient. For instance, deprovisioning only suspends the account when integrating with Google Workspace and does not release licenses by default. Therefore, you must make sure you have a mechanism in place to actually terminate the licenses by deleting the account or manually switching them to the Archived User license types.

“When an assignment is removed (deprovisioned) from a user in Okta, Okta does not delete the user’s account. The account is put into a deactivated state in the external application and the user’s access to the app integration is removed from Okta. Some external applications may support deleting the user’s account in the external application.” -Okta Provisioning Guide

From onboarding new employees to offboarding them, Okta’s automated LCM is a great tool once you get a solid grasp on the best ways to use it. In addition to the advice offered in this article, another way to make the most of your Okta LCM is through Crosswire, where users can be automatically granted the correct permissions without overcomplicating management systems. For further guidance on securing your organization, reach out to us! You can stay up to date with / join Crosswire below.