For fifteen years, our identity and access management was built on Active Directory, VPNs, and network perimeter security. Employees connected to the office network or VPN. Once inside the perimeter, they had access to internal systems. Authentication was mostly username and password with some systems requiring VPN client certificates.

This model worked when most systems were on-premises and most employees were in offices. It breaks down in a world of cloud services, remote work, and SaaS applications. We spent the last year modernizing our IAM architecture, and the project was more complex than anticipated.

The Problems with the Old Model

Network perimeter security assumes that anything inside the network is trustworthy. This was always questionable, but it’s completely broken now. Most of our systems are in the cloud, not behind a network perimeter. SaaS applications are accessed directly over the internet. Employees work from home, coffee shops, and coworking spaces.

VPNs are slow and annoying. They require client software that breaks in unpredictable ways. Split-tunnel versus full-tunnel VPN creates security versus usability tradeoffs. VPN capacity becomes a constraint when everyone’s working remotely. And VPNs don’t work for mobile devices or third-party contractors easily.

Active Directory is on-premises infrastructure that requires management and maintenance. When systems moved to the cloud, we needed to either maintain hybrid AD integration or find alternatives. The complexity of hybrid AD with Azure AD synchronization was substantial.

Password-based authentication is weak. Employees reuse passwords. Phishing attacks steal credentials. We implemented multi-factor authentication, but that just added friction without fully solving the problem. Users still had passwords that could be compromised.

And we had no consistent access control across systems. Each application had its own user database or AD integration. Provisioning and deprovisioning was manual. When someone joined or left the company, we had a checklist of 20 systems to update. This was error-prone and created security risks.

The Modern IAM Architecture

The solution is centered on identity provider (IdP) as the single source of truth, single sign-on (SSO) for all applications, zero-trust network access instead of VPN, and multi-factor authentication enforced universally.

We chose Okta as our identity provider. Azure AD was the alternative, but Okta had better integration with non-Microsoft applications and more flexible policy controls. This was controversial because it meant paying for external IdP instead of using Azure AD which we were already paying for. But the integration and usability benefits justified the cost.

SSO means employees authenticate once with Okta and get access to all applications without separate passwords. This is better security (no password reuse, no credentials stored in multiple places) and better usability (one login for everything).

Zero-trust network access means we don’t assume network location determines trust. Instead, every access request is authenticated and authorized based on identity, device health, and context. This replaced our VPN with identity-aware proxies and application-level access controls.

We implemented hardware security keys for MFA instead of SMS or authenticator apps. This provides stronger security against phishing and is more user-friendly once people have the keys set up. Employees get two Yubikeys, one for regular use and one as backup.

The Migration Process

Moving from the old architecture to the new one required migrating every system to use Okta SSO, replacing VPN access with zero-trust alternatives, and transitioning from password-based to passwordless authentication where possible.

The SSO migration took about eight months. We prioritized high-value systems first: email, collaboration tools, cloud infrastructure consoles. Then moved to business applications. Then finally the long tail of internal tools and admin systems.

Some applications supported SAML or OpenID Connect natively and integrated with Okta easily. Others required custom integration work or couldn’t be migrated at all. We ended up with about 85% of systems using SSO, with the remainder requiring separate authentication.

The zero-trust transition was harder. We couldn’t just turn off the VPN because some systems still depended on it. We gradually moved systems to internet-accessible services behind identity-aware proxies. For systems that couldn’t be moved, we implemented application-specific VPN gateways rather than network-wide VPN.

The passwordless transition is still ongoing. Okta supports WebAuthn for passwordless authentication with hardware keys. But only for the Okta login itself. Many applications still require passwords even with SSO because they don’t support modern authentication standards. This is frustrating but there’s no easy solution.

The User Experience

Overall, the new IAM architecture is better for users. One login gets them into everything. No VPN required for most work. Hardware security keys are faster and easier than typing codes from authenticator apps.

But the transition was rocky. Users had to learn new authentication flows. Hardware keys required training and support. Some applications broke during migration because of SSO configuration issues. And there’s still complexity where not everything works the same way.

The elimination of VPN was controversial. Some users preferred VPN because it felt more secure. Others appreciated not needing it but worried about accessing systems over the internet. We had to invest significant effort in communication explaining why zero-trust is more secure than VPN, not less.

Hardware security keys created support burden. Keys get lost or damaged. Users travel without their backup key and get locked out. The admin processes for key management and account recovery needed to be developed from scratch.

The Cost

The old architecture wasn’t free, but costs were mostly embedded in infrastructure we had anyway. Active Directory required servers and management, but those were shared costs. VPN appliances needed capacity upgrades occasionally but were capital expenses absorbed into general IT budget.

The new architecture has explicit, recurring costs. Okta licensing is about $8 per user per month. Hardware security keys are about $50 per user (two keys). Zero-trust access platform (we use Cloudflare Access) adds another $7 per user per month. For 200 employees, that’s about $30K annually plus initial hardware costs.

This doesn’t include migration labor. Engineering time to integrate applications with SSO, configure zero-trust policies, test everything, train users, and handle support issues was probably six months of senior engineering time spread across multiple people.

But the security improvement and operational efficiency gains justify the cost. Provisioning new users takes minutes instead of hours. Deprovisioning is centralized and immediate. We have visibility into application access that we never had before. Security posture is measurably better.

The Security Benefits

The security improvements are substantial. With SSO, we can enforce consistent authentication policies across all systems. MFA is mandatory. We can detect unusual access patterns centrally. When someone leaves, disabling their Okta account immediately revokes access to everything.

Hardware security keys are phishing-resistant. Unlike SMS or authenticator app codes, you can’t trick someone into giving you their key. This dramatically reduces credential theft risk.

Zero-trust architecture means compromised devices or credentials don’t provide network-level access. Every request is authenticated and authorized. We can enforce device health checks, ensuring only compliant devices access sensitive systems.

We have comprehensive audit logs through Okta showing who accessed which applications when. This visibility didn’t exist with our previous architecture where each system had its own logs.

And we can implement conditional access policies. Require additional authentication for sensitive operations. Block access from risky locations or compromised devices. Allow limited access for contractors without full employee privileges. This granularity was impossible with the old perimeter model.

The Remaining Challenges

Not everything is solved. Some legacy systems can’t integrate with modern IAM. We still have a few applications requiring separate passwords. This creates user frustration and security gaps.

Privileged access management is still complex. Systems administration and infrastructure access need more stringent controls than regular user access. We’ve implemented jump boxes and session recording for critical systems, but the integration with Okta is imperfect.

Third-party and contractor access is better than it was but still needs work. We can provision Okta accounts for external users, but the lifecycle management and access scoping isn’t as clean as for employees.

Mobile devices are complicated. iOS and Android have improved support for hardware security keys, but it’s not seamless. Many users prefer biometric authentication on mobile, but that’s less secure than hardware keys. We’re accepting this tradeoff for now.

The Cultural Shift

Modern IAM requires a shift from perimeter security thinking to identity-centric security. This means trusting identity verification more than network location, which feels uncomfortable to security teams trained on traditional models.

It also requires accepting that not everything can be locked down perfectly. Some applications don’t support modern authentication standards. Some systems can’t be migrated off legacy infrastructure. Perfect security is impossible, so we focus on risk-based prioritization.

And it requires user education. Employees need to understand why hardware keys matter, why we don’t use VPN anymore, and how to operate securely with the new model. Security training shifted from “connect to VPN before accessing company resources” to “verify you’re authenticating to the right service, protect your hardware key, report suspicious authentication requests.”

Was It Worth It?

Absolutely. The modernization project was expensive and disruptive, but it solved real problems and positioned us for the future. The old architecture wasn’t sustainable as more systems moved to the cloud and remote work became standard.

The security improvements alone justify the project. We’re much better protected against credential theft, phishing, and unauthorized access. The operational efficiency from centralized identity management and SSO saves time and reduces errors.

And the user experience is mostly better. Despite transition friction, employees appreciate not dealing with VPN and having single sign-on for most systems. The complaints have mostly subsided.

If you’re still running traditional perimeter security with VPNs and AD, you should be planning IAM modernization. It’s not optional. The world has changed, and identity management architecture needs to change with it. Better to do it deliberately over 12-18 months than to be forced into it by a security incident or system failure.