When Okta is a good fit
Okta works well when employees, contractors and admins need one place to sign in, and the company uses many applications that each have their own passwords and their own way of creating accounts. Another good sign is onboarding and offboarding that take days because accounts have to be created and removed by hand in every application.
If your problem is how customers sign in to your SaaS product, you need a different class of solution. See CIAM with Auth0 in practice.
Implementation stages
Discovery
Together with you we list your applications, identity sources and current sign-in methods, so we know what moves first and what can wait for a later phase.
Directory and HR source of truth
We decide where user data in Okta comes from: the HR system, Active Directory, Entra ID or both. That choice determines whether a change in HR can automatically trigger account changes.
SSO and SCIM for applications
We connect applications to Okta with SSO and, where the application supports it, with SCIM provisioning, so account creation and deactivation can be automated. We start with the applications that have the most users.
MFA and policies
We configure global sign-in, app sign-in and MFA enrollment policies in Okta for each group. For privileged accounts we plan phishing-resistant factors, which we cover in the guide Phishing-resistant MFA and NIS2.
Account lifecycle (joiner, mover, leaver)
We define rules for people who join, change roles or leave, so that everyone has only the access their current role calls for, and when someone leaves their account is deactivated in Okta, sessions and tokens are revoked, and provisioning deactivates it in connected apps.
User rollout (cutover)
We roll out the change group by group rather than for everyone at once, to limit risk and leave time to react to support requests. For each group we agree with you on a date, a message to users and a rollback plan.
Handover
We hand the documentation and configuration to your IT team, or agree on ongoing operations with you. Your team should know who owns the applications, the policies and changes in Okta.
Common mistakes we watch out for
Turning on MFA for the whole company at once.
−The change reaches everyone on the same day and the help desk cannot keep up with tickets.
+We roll out MFA group by group, starting with admins, and leave time to adjust policies.
Connecting applications before cleaning up user data.
−Accounts in Okta copy the errors from the directory and the HR system, so access is granted based on outdated data.
+Before connecting applications we check which fields in the HR system and the directory are reliable, and build access rules on those.
No owner once the project ends.
−After go-live nobody is responsible for new applications and policy changes, and the configuration slowly drifts out of shape.
+Before handover we agree on owners for applications and policies on your side, or arrange ongoing operations with us.
Admin accounts and service accounts left outside the policies.
−The rollout covers regular users, while privileged and service accounts stay without extra protection.
+We bring admin accounts under policy in the first pilot group, and we inventory service accounts and assign them to owners.
What to prepare before kickoff
- A list of the applications used in the company, noting which of them support SSO (SAML or OIDC) and SCIM.
- The source of employee data (HR system, Active Directory) and the person who owns it.
- A list of user groups and privileged accounts, including service accounts.
- A decision on who on your side approves access policies and changes to them.
- Information about user devices, including whether the company manages them.
- A help desk and a channel for communicating with users that can take requests during the rollout.
Running Okta after go-live
After the rollout, the Okta configuration needs ongoing care: connecting new applications, changing policies, reviewing new Okta releases and working with the vendor's support when something goes wrong. You can do this with your own team or hand it to us. We describe the scope on the Okta managed services page.
CEO
Jan Czajkowski is the CEO and co-founder of Zelto, an official Okta partner that helps organizations design, deploy and run identity and access management.
More from Jan →Let's talk about your Okta implementation
Tell us about your applications and how people sign in today, and we will point out where to start. If you prefer email, write to hello@zelto.id.