Expertise in Okta
Implementation &
Migration
Whether you’re integrating Okta with legacy systems, migrating from another platform, or embedding components like single sign-on (SSO) and multi-factor authentication (MFA), our consultants can help you transition with zero disruption.
Tailored Solutions for Any Business Environment
From large enterprises to small businesses, i3solutions offers Okta deployment solutions that fit. Our services range from strategic planning and architecture upgrades to deep system integration and post-implementation support.
Secure Collaboration & Identity Management
i3solutions helps you harness Okta’s full potential by integrating your workforce and business partners into a unified identity management system. Our consultants provide federated identity solutions that allow swift, secure collaboration without compromising your infrastructure.
Check out our case studies
Empower your organization with an identity management solution that grows with you. Whether you’re looking to streamline access, automate user provisioning, or enhance collaboration, i3solutions provides expert Okta consulting services tailored to your needs.
Most Okta rollouts in a Microsoft estate stall on sequence, not on the product. Move the applications that already support SAML or OpenID Connect and hold regulated data first, enroll users before you enforce, and enforce administrators and remote access before everyone else. Get that order wrong and the help desk absorbs the lockouts while the next assessment finds the gaps the rollout was meant to close.
Four decisions sit inside that order, and each fails in its own way: an application that cannot federate cleanly, a group enforced before it enrolled, a record the assessor asks for that no one kept, and a locked-out user with no named owner. The sections below take them in that order, then name the case where an Okta rollout is not the project to run.
The first wave is the applications that already speak SAML or OpenID Connect and hold regulated data, because they show audit value fastest and surface federation faults while the user population is still small. Take them from the Okta Integration Network catalog where a prepared integration exists. Anything that needs a custom integration goes to its own track with its own test plan, not into wave one.
Okta’s own admin guide sets out the two routes an application can take. Its Identity Engine topic Add existing app integrations says: “The Okta Integration Network (OIN) contains thousands of prepared app integrations.” For an application that is not there, the same topic says Create App Integration is the route: “This launches the Classic experience (formerly called the App Integration Wizard), which allows admins to create custom app integrations for their org.”
Protocol decides the wave, not the urgency of the application’s owner. Okta’s topic Configure Single Sign-On options states that “the Sign on methods available depend on the access protocols supported by the app integration”, and lists OpenID Connect and SAML 2.0 among them. An application that already speaks one of those can be moved, tested and rolled back inside a wave. One that needs a custom integration, or cannot federate at all, goes on a separate integration track with its own test plan, so its problems never hold up the first wave.
Enforce MFA in waves by risk, not on one date for everyone. Administrators, remote access and the applications holding regulated data go first; the general workforce follows once enrollment is measured and the help desk has a named owner for stragglers. The control baseline your contracts invoke decides who must be on MFA; the rollout plan decides only the order in which they get there.
A single enforcement date fails for a mechanical reason. Okta’s Identity Engine topic Okta policies and rules states: “If the policy applicable to the user requires a certain authenticator and the user hasn’t enrolled it, they’re prompted to enroll the authenticator when trying to access the org or an app.” Enforce for everyone at once and every user who has not enrolled meets that prompt at the same moment, and the ones who cannot complete it become the lockout queue. Enroll a group, measure it, then enforce it.
The waves are built in policy. Okta’s topic App sign-in policies says: “You can create a unique policy for each app in your org, or create a few policies and share them across multiple apps.” It also warns: “However, remember that the changes are applied to both new and existing apps that are assigned to the shared default policy.” A wave plan that edits the shared default policy moves every application on it at once. Give the first-wave applications and the administrator groups policies of their own, and widen them wave by wave.
Who must be on MFA, and for which access, is a question for the baseline and not for the rollout plan. That question is answered in MFA and NIST SP 800-53: Your Baseline Decides, Not the Catalog. Whether a given baseline applies to your contracts is for the contracting officer to decide.
An assessor reads records, not intentions. By go-live the rollout should leave four: an application inventory showing which apps sit behind SSO and which do not, the MFA policy per group with the date each wave was enforced, the enrollment exceptions with an owner and an expiry, and the sign-in and policy-change log the assessor will sample. Missing any one turns a finished rollout into a finding.
The log is the record most often assumed and least often kept. Okta’s Identity Engine topic System Log states: “The System Log contains details of all logged events for your org.” The events table can be exported (“Download the entire table by clicking the Download CSV file link.”), and its filters open on a short recent window by default. A default screen is not an evidence set. When each wave closes, export its policy-change and sign-in events and file them with that wave’s policy record.
Your inventory has to show the applications left out as clearly as the ones moved. An application that stays on its own sign-in, with a reason and a planned wave, is a documented decision. One missing from the list is a gap the assessor finds for you.
If most of your applications already federate to Microsoft Entra ID and your licensing already includes the Conditional Access you need, a fresh Okta rollout adds a second identity plane to govern and audit. Then the better project may be consolidating onto Entra ID. i3solutions has done hundreds of Okta to Entra ID conversions. Everything above assumes Okta is staying in your estate.
Check the license you already hold before adding a second policy engine. Microsoft Learn’s What is Conditional Access? (last updated April 27, 2026) states: “Using this feature requires Microsoft Entra ID P1 licenses.” It adds: “Customers with Microsoft 365 Business Premium licenses can also use Conditional Access features.” Running Okta and Entra ID side by side for the long term means two sets of sign-in policies, two logs and two exception lists to keep in step for every audit.
If that describes your estate, the move off Okta is covered in How Do I Hire Consultants to Migrate Us Off Okta Onto Microsoft Entra ID Without Breaking Access? This page does not cover the move itself.
An Okta rollout in a regulated Microsoft estate is identity work on two platforms at once, and it needs people who work in both. i3solutions delivers its full service portfolio into the healthcare vertical exactly as it does into defense manufacturing and finance, including identity work with Okta and Entra ID, AI work, Power Platform, and Dynamics 365 integration. Delivery is senior and US-based.
The method is the order on this page: inventory the applications and the protocols they speak, give first-wave applications and administrator groups their own policies, enroll before enforcing, keep the four records as each wave closes, and put a name against every exception. To test your own application list and enrollment position against that order, use the form at the top of this page.
Start with the applications that hold regulated data and already speak SAML or OpenID Connect. They show audit value fastest and expose federation faults while the enrolled population is still small. Applications with a prepared integration in the Okta Integration Network come before any that need a custom integration, which run on their own track with their own test plan.
In waves, by risk. In Okta Identity Engine, a user who has not enrolled an authenticator that policy requires is prompted to enroll when they next try to access the org or an app, so one date for everyone sends every unenrolled user to that prompt together. Enforce administrators, remote access and regulated-data applications first, then the wider workforce once enrollment is measured.
Four records: a list of which applications are behind SSO and which are not, with the reason for each one left out; the MFA policy for each group and the date its wave was enforced; every enrollment exception with its owner and expiry; and an export of the sign-in and policy-change events from the Okta System Log for each wave.
A named owner on the help desk side, agreed before the first wave is enforced, with an exception list that gives each straggler an owner and an expiry date. Without that name, lockouts go to whoever answers first, and exceptions stay open until the audit that samples them.
By Justin Bowen, Sr. Vice President, Delivery Services, i3solutions
Justin has spent more than 15 years at i3solutions and more than 25 years leading project, program, and product delivery across complex technology environments. His work centers on turning strategy into governed execution, aligning technical teams and stakeholders, managing delivery risk, and guiding Microsoft 365, SharePoint, Power Platform, cloud, data, automation, and custom application programs through measurable production outcomes.
Copyright i3solutions. All Rights Reserved.
Email aski3@i3solutions.com, Phone 703.652.8966
Privacy Policy | Sitemap
