The challenge
A regulated utility runs its case-management platform on SharePoint and wants its own people to sign in with corporate credentials through Okta. That much is ordinary.
The part that is not ordinary is who else uses it. Regulatory case work involves outside counsel and contractors: people who need real access to real case files, who are not in the utility's directory, will never be issued a corporate identity, and cannot be put on the corporate VPN.
So the platform has to serve two populations whose security requirements point in opposite directions. Employees should be behind everything: corporate identity, conditional access, the VPN. External parties need to reach the same application from the open internet. Designing for one of those and bolting on the other is how you end up either locking out the lawyers or putting the case files on the internet.
The solution
Two URLs, chosen deliberately over the alternatives. One address federated to Okta for utility staff, and a second for external parties authenticating against shadow accounts. That is not a workaround: the two access models are enforced at different layers, and one web application cannot hold both.
The network question was answered by testing, not by assuming. Employees signing in through Okta have to be on the VPN. External parties reach their URL over the public internet on SSL and require no VPN. Both were confirmed before the design was committed rather than discovered by users afterwards.
The assumption that would have derailed the schedule was proven false. The open question was whether a site-to-site VPN would be needed for SharePoint's people picker to resolve identities, which would have pulled a second organisation's network team onto the critical path. Testing showed it was not: SharePoint authenticates to Okta with an API token, and through that connection can see users and groups in the enterprise directory.
A skeletal farm carried the risk. Rather than integrate against anything that mattered, a bare SharePoint 2016 farm was built for integration testing and nothing else. Federation breaks sign-in, which means it breaks everything at once for everybody, so the cheapest thing to get wrong is a farm nobody depends on.
The results
In May 2023 the utility began implementing Azure AD and opened the question of moving off Okta. The conversion to Microsoft Entra ID did not begin in earnest until January 2026, nearly three years later. That gap is what identity migrations look like inside a regulated business: the intent forms when a strategic platform decision is made elsewhere, and the work happens when dependencies, external users and change windows line up. Keeping the Okta configuration documented and current in the meantime is why the conversion began with sequencing questions rather than archaeology.