This article follows my previous post, "Phased Implementation of Zero Trust: Prioritizing Pre-Authentication for Applications and APIs." Here, I'll explore how we achieved pre-authentication using Microsoft Azure Services, drawing from my firsthand experience implementing these solutions for a large customer (more than 50k users). This is a Zero Trust Network Access 2.0 implementation where the scope is to protect hosted services and APIs.

We rolled out the functionality described in this article back in 2019, and I've since overseen a major iteration of the implementation in 2024. Throughout this article, I'll address existing gaps, necessary trade-offs, and the challenges encountered when integrating zero trust principles with legacy applications and APIs.

This implementation is what several vendors would call ZTNA 2.0
A big benefit of our implementation is that it extends the Microsoft Azure architecture, as opposed to many vendors trying to replace the Microsoft Zero Trust components.

Our implementation do not requires any agent or client installed on end user devices except standard Microsoft Intunes client "Company Portal" to enable device posture as part of the per application and per api conditions and requirements.

Microsoft Azure's Zero Trust Security Implementation

Microsoft Azure provides comprehensive security services aligned with the Zero Trust security model's key principles. Below is how Microsoft Azure's services map to a Zero Trust Architecture implementation:

1. Never Trust, Always Verify

Microsoft Azure implements this principle through:

• Entra ID - Provides identity verification for every access request regardless of where the request originates
• Conditional Access - Evaluates multiple signals (user location, device health, risk detection) before granting access
• Entra ID Identity Protection - Uses machine learning to detect and remediate identity-based risks
• Multi-factor Authentication (MFA) - Requires multiple forms of verification before access is granted

2. Least Privilege Access

Azure enables least privilege through:

• Role-Based Access Control (RBAC) - Granular permission assignment based on specific roles
• Privileged Identity Management (PIM) - Provides just-in-time and just-enough-access through time-bound role activation
• Entra ID Entitlement Management - Manages access packages and reviews to ensure users have only necessary permissions
• Managed Identities - Eliminates the need for credentials in code by using Entra ID managed identities

3. Explicit Verification

Azure implements explicit verification via:

• Entra ID B2C - Customer identity verification and management
• Azure Resource Manager - Requires explicit authentication for resource access
• Continuous Access Evaluation - Real-time policy evaluation for continued session access
• Device Management (Intune integration) - Verifies device compliance before allowing access
• Microsoft Defender for Cloud - Continuously assesses security posture and verifies compliance

4. Enable Detailed Access Logging

Azure provides comprehensive logging through:

• Azure Monitor - Collects and analyzes telemetry data from Azure resources
• Azure Sentinel - SIEM solution for security monitoring and threat detection
• Azure Log Analytics - Centralizes log data for analysis and visualization
• Azure Activity Logs - Records subscription-level events for audit purposes
• Diagnostic Settings - Captures resource-specific logs for detailed analysis

Each of these components works together to create a comprehensive Zero Trust security framework within the Azure ecosystem, ensuring that all access requests are verified, limited, explicitly granted, and thoroughly logged.

Implementation Approaches for Pre-Authentication

Our Azure-Based Zero Trust Architecture

In this phased implementation, we achieved our goals by utilizing:

• Microsoft Entra ID with OIDC and the OAuth2.0 MSAL Endpoint
• Microsoft Entra ID App Registrations
• Microsoft Entra MFA
• Microsoft Entra ID Protection
• Microsoft Intune
• Microsoft Sentinel
• Conditional Access Policies
• Netscaler Identity Aware Proxy
• YubiKey 5 Series security keys (FIDO2)

Implementation Considerations

Our preferred solution would have been Azure Application Gateway. However, our requirements proved incompatible with its current capabilities:

• Providing pre-authentication for all legacy applications
• Providing per App and API "Entra ID App Registration" for granular policies
• Protecting legacy APIs with no built-in authentication or authorization
• Implementing continuous validation and authorization
• Solving token revocation needs for applications
• Implementing triggers for risk-based user behavior analytics
• Supporting both cloud and on-premises hosted services
• Rewriting HTTP body content of legacy services to ensure full TLS protection with no HTTP leakage

Protect Your Assets for Measurable Positive Outcomes: Understanding the Legacy Application Challenge

A critical aspect to understand is that legacy applications are usually not designed for internet exposure or secure delivery. However, with knowledge and planning comes opportunity. Ensure your staff, vendors, partners, and consultants can protect legacy services without implementing proprietary overlay technology.

Any attacker today needs next to no knowledge to map your organization's entire digital footprint. Your weakest service or application will be identified in minutes without specialized expertise. If you expose services such as web applications or APIs that aren't protected with Zero Trust principles, attackers will easily identify all software components. With some knowledge it is easy to uncover lack of hardening and secure software design in each application , API or service.

Mapping your business's risk profile is essential. Asking the right questions during this mapping process is crucial.

Risk Evaluation and Patching Challenges

The assets powering your critical business applications should undergo thorough risk impact assessment by a security auditor. I strongly recommend software vendors adopt CI/CD pipelines to ensure they can patch services rapidly enough to address vulnerabilities in today's complex security landscape.
I practice what I preach: Read about why I recommend deploying and configuring using Infrastructure as Code (IaC) for better security outcomes.

Protecting applications with Zero Trust: When you cannot implement Zero Trust across all exposed applications, most organizations will see diminished outcomes. Non-Zero Trust assets require continuous monitoring through vulnerability scanners, alongside tracking the gap between vulnerability detection and complete patching. This evaluation is critical because your ROI on reactive protection tools like Tenable or Qualys becomes distorted when patching can't keep pace with discoveries. Moreover, these reactive approaches fail to identify fundamental insecure software design issues.

A documented security deviation won't help your business risk profile—it merely diffuses accountability. Zero Trust is a proactive protection mechanism giving you time to patch and secure your services. Zero Trust will also help shield you while implementing secure software design

Our Implementation Solution

For this project, we selected Netscaler as our Identity Aware Proxy because PaaS reverse proxies couldn't protect legacy services according to our requirements. With Netscaler IAP, we successfully protected almost our entire application portfolio (100+ services) without implementing any proprietary overlay technology. An additional advantage is the ability to easily migrate this design between public cloud vendors or move in-house to either private cloud or traditional on-premises platforms.

There was only one exception in our implementation, a non-conforming application that couldn't be protected due to its use of HTTP tunneling to embed proprietary code. Our strategic ZTNA approach allows us to focus our reactive monitoring resources on this single application rather than the 100+ services we previously had to monitor before implementing Zero Trust Pre-Authentication. (Of course, all services should still be regularly patched and scanned.)

Netscaler performs exceptionally well in cloud environments or on VMware/Hyper-V using modest hardware, as it was designed as software infrastructure-as-code from day one, unlike many vendors that initially built ASIC/hardware-based solutions. Several other reverse proxy vendors are also suitable for this task.

Deploying Identity Aware Proxy (IAP) for Applications and APIs

Implementation Steps

1. Implement authentication mechanisms with OIDC using MSAL endpoints to provide comprehensive conditional access capabilities through your IAP. You need separate Entra ID App Registration for each Application and for each API.
2. Configure access policies based on user identity and request characteristics with Microsoft Entra ID Conditional Access Policies on a per-application or API basis
3. Establish monitoring and logging to track application authentication events using solutions like Azure Monitor, ELK Stack, Splunk, or similar technology feeding data to Azure Sentinel or other SIEM systems. You can also send all log data directly to Azure Sentinel, but carefully evaluate how this affects Azure Sentinel pricing.

Our approach can be implemented without modifying existing web applications, APIs, and other HTTP-based services, making it an ideal first phase in a Zero Trust journey.

Our chosen Identity-Aware Proxy gains these essential capabilities:

1. Authenticate users before allowing access to applications (Azure Entra ID)
2. Apply app specific context-aware access policies based on user, device posture, and several other attributes (Azure Conditional Access Policies on App Reg)
3. Provide detailed access logs for security analysis (IAP)
4. Provide enhanced security using advanced AI/ML IP Reputation databases, Botnet Detection including behavioral analysis (mouse and keyboard interaction analytics), WAF with more granular implementation of OWASP Top 10, and TLS Hardening ensuring proper encryption (IAP)

Phase 1: Pre-Authentication Implementation

The organization

• Deployed a reverse proxy with pre-authentication capabilities
• Integrated with their existing identity provider
• Implemented MFA for all users
• Deployed PIM for administrative tasks combined with MFA
• Created detailed authentication logs
• Implemented FIDO2 keys for session hijacking protection and compliance with legal requirements, but only for sensitive services
• Enrolled all user machines into Azure combined with Intune for device management and compliance
• Created individual Conditional Access policies for each API and each applications, and services.

Results: Within months, the organization achieved a 92% reduction in authentication-based attacks and eliminated several classes of vulnerability exploitation attempts entirely. Applications are no longer being probed with tools such as Metasploit and Burp Suite. Vulnerability scanners like Tenable and Qualys cannot reach services without performing a session hijack (leaked credentials alone are insufficient due to MFA implementation).

Phase 2: Policy Refinement and Expansion

Building on this foundation, they:

• Implemented more granular access policies based on user roles
• Extended pre-authentication to internal applications
• Added device posture checks for sensitive operations.

Subsequent Future Phases

Later phases should include:

• Network micro-segmentation
• Data access controls
• Continuous validation mechanisms

Each phase built upon the security foundation established by pre-authentication.

Measuring Success

Effective metrics for evaluating your pre-authentication implementation include:

1. Reduction in authentication-based attacks
2. Decrease in successful application/API exploitation
3. Improved detection of credential abuse attempts
4. Increased visibility into access patterns
5. Reduced time to respond to suspicious authentication events

Planning Your Phased Implementation

Step 1: Asset Inventory and Prioritization

Begin by:

• Identifying your most critical applications and APIs
• Determining which resources contain sensitive data
• Assessing current authentication mechanisms
• Prioritizing resources based on risk and value

Step 2: Select Initial Pre-Authentication Mechanism

Choose an approach that:

• Integrates with your existing identity infrastructure
• Scales to your application/API footprint
• Provides comprehensive logging and monitoring
• Minimizes impact on user experience

Step 3: Implementation and Validation

During implementation:

• Start with less critical applications to refine the approach
• Validate that authentication policies work as intended
• Establish monitoring for authentication events
• Create incident response procedures for authentication failures

Step 4: Expansion and Enhancement

After initial success:

• Extend pre-authentication to additional resources
• Implement more sophisticated policies based on context
• Integrate with additional security controls
• Begin planning subsequent Zero Trust phases

Challenges and Tradeoffs

Continuous Validation and Authorization

Continuous validation and authorization is a core function within Zero Trust frameworks, enabling responses to events such as:

• Password changes or resets
• Multi-factor authentication enabling
• Administrator explicitly revoking all refresh tokens
• High user risk detection by Entra ID (Azure AD) Identity Protection
• User account deletion or disabling

In Microsoft Azure, this is implemented with Open ID Continuous Access Evaluation Protocol (CAEP). Continuous validation and authorization remains a significant challenge with today's Zero Trust solutions.

When evaluating Zero Trust vendors, those addressing continuous validation and authorization are commonly implementing proprietary technology, as the CAEP framework requires logic on both the Identity Provider and the Relying Party. Currently, CAEP is only supported for a subset of the M365 platform .
To my knowledge, no IAP proxy supports CAEP today. Furthermore, if you examine Microsoft Global Secure Access (GSA) details, CAEP support is limited to the subset of M365 services.

When implementing a Zero Trust solution, it's crucial to understand the long term effect of implementing a proprietary Continuous validation and authorization solution. I would advise careful consideration before implementing "non CAEP" solution due to the promising benefit of the "Shared Signals and Events" such as Risk Incident Sharing and Coordination (RISC). CEAP utilize Shared Signals and Events.

It also crucial to evaluate how the Open ID CAEP protocol immaturity affects you.

The issue extends beyond Access Token or Primary Refresh Token lifetime windows. Ensure you have a clean, straightforward strategy to address this. With our selected IAP, we can solve this problem using REST API calls to the IAP while waiting for CAEP protocol maturity.

Without CAEP support (or an implementation solving this gap), you will not be able to automatically force re-authentication or logging out users based on events.

Refreshing access tokens

The access token lifetime is usually set to 60 minutes in Azure. If you are to adhere to the access token lifetime you need to set the actual session cookies granting access, to match the access token lifetime, ensuring you will be able to "check in" with Microsoft Entra ID at the same interval.

If you have a vanilla Azure Entra ID configuration with 60 minutes access token lifetime including matching session cookie lifetime the OIDC Relaying Party (Netscaler IAP or reverse proxy) will:

• Inject a HTTP 301 Redirect every 60 minutes (for non CAEP Access Token) sending the user to login.microsoftonline.com
• Microsoft Azure Entra ID will issue a new Access Token to the users if the users session is still considered valid by Entra ID
• Microsoft Azure Entra ID will redirect back to the Application
• Netscaler IAP will verify the Access Token and set an updated session cookie to +60 minutes

The above process will for some legacy services cause problems for the user, affecting the user experience such as losing partial filled out forms etc.

CAEP enabled Access Tokens solves this problem since the Netscaler IAP no longer needs to check in with Azure Entra ID. The Netscaler would, if supported , receive Shared Signal Events directly as a live feed from Entra ID.
CAEP enabled Access Token has a 24 hour lifetme due to Shared Signal Events. This will increase security and user experience.

I have adopted several techniques to navigate around this issue but all of them includes a tradeoff. CAEP will solve all this. CAEP is a leap forward in security giving us near instant toke revocation or re-authenticate , step up authenticate or events based on risky userbehaviour.

Conclusion

A phased approach to Zero Trust that begins with pre-authentication for applications and APIs delivers significant security benefits while avoiding the pitfalls of attempting a comprehensive implementation all at once. By focusing first on how attackers actually target your organization—primarily through applications and APIs—you can achieve the greatest risk reduction for your investment.

Pre-authentication embodies core Zero Trust principles and creates a foundation upon which additional security controls can be built. Organizations that take this pragmatic approach will find themselves better protected against the most common attack vectors while positioning themselves for continued security maturation.

Remember that Zero Trust is a journey, not a destination. By starting with pre-authentication and building outward, organizations can make that journey more manageable, more cost-effective, and ultimately more successful in protecting their digital assets from increasingly sophisticated threats.