BeyondTrust: Building a Zero Trust Identity Framework

In the realm of modern beyondtrust security, the fundamental error most architectures make is treating zero trust identity as a binary state: authenticated or not. BeyondTrust resolves this by decoupling the strength of the authentication event from the strength of the identity verification, creating a dynamic assurance model. This approach relies on two distinct metrics defined in NIST SP 800-63-3: Authentication Assurance Level (AAL) and Identity Assurance Level (IAL). While AAL measures the confidence that the current user is the person claiming to be at the moment of access, IAL measures the confidence that the entity exists and is who they claim to be over time. BeyondTrust combines these into a real-time risk calculation rather than a static permission check.

This article is Part 4 of the Zero Trust & Modern Security Architecture series.

The Mechanics of AAL and IAL

To understand how this works, we must separate the "who" from the "how." IAL is established during the enrollment phase. If an employee is verified via a physical HR visit with government ID, their IAL is high (IAL-2 or IAL-3). If they are onboarded via a remote video call, their IAL might be lower. This value is a static property of the user profile in the directory, typically stored in the identity provider or the PAM vault.

AAL, conversely, is ephemeral. It is calculated per session. AAL-1 might be a simple password. AAL-3 requires hardware-bound multi-factor authentication (FIDO2) and device attestation. In a traditional firewall model, you log in once with AAL-1 and walk away. In the BeyondTrust framework, the system constantly re-evaluates the required AAL based on the action being attempted. If a user with IAL-3 attempts to view a file, a low AAL might suffice. If that same user attempts to execute a script on a production database, the system demands a higher AAL.

The mechanism here is the "Composite Risk Score." While NIST SP 800-63-3 defines the AAL and IAL levels, the calculation of a Risk = f(UserContext, DeviceContext, ResourceSensitivity) score and the resulting "Adaptive Challenge" are proprietary implementations by BeyondTrust, not standard NIST definitions. If the calculated risk exceeds the threshold for the requested resource, the system triggers an "Adaptive Challenge." This is not a pre-defined rule but a dynamic calculation. For example, if the user's device posture changes (e.g., a new malware signature detected on the endpoint) while they are already logged in, the system determines that the current state no longer meets the threshold for the resource. This triggers a re-evaluation, forcing a re-authentication before the next privileged command is executed.

The Real-Time Telemetry Loop

Consider a scenario involving "Alice," a senior engineer with IAL-3, attempting to access the "Core-Billing-DB" server.

1. Initiation: Alice initiates an SSH connection from her laptop.
2. Telemetry Ingestion: The BeyondTrust agent on Alice's laptop and the network sensor immediately report data to the Policy Engine. This data includes:
   • Device Posture: Is the OS patched? Is the disk encrypted?
   • Geolocation: Is the login occurring from the corporate subnet or an unknown IP?
   • Behavioral Baseline: Does this login time and location match Alice's historical pattern?
3. Calculation: The engine calculates the current AAL. If the device is unpatched, the effective AAL drops. If the location is anomalous, the risk score spikes.
4. Decision: The resource "Core-Billing-DB" requires an AAL-3 equivalent for write operations. The engine sees Alice's current session has an effective AAL-2 due to the unpatched device.
5. Enforcement: Instead of blocking the connection outright (which causes downtime), the system presents an adaptive challenge. It demands a second factor (e.g., a push notification to a verified mobile app) to elevate the session AAL to 3. Only after the second factor is validated does the tunnel open.

This flow demonstrates that trust is not granted at the start of the session; it is earned continuously. The "trust" is a function of the telemetry loop, not the initial handshake.

Decision Logic and Enforcement

The final layer of this framework is the enforcement point. BeyondTrust utilizes a policy engine that maps the calculated AAL/IAL against the specific security requirements of the target resource. This is distinct from Role-Based Access Control (RBAC), which assigns permissions based on job titles. In Zero Trust, permissions are assigned based on the current assurance of the identity.

The logic follows a strict hierarchy:

1. Identity Verification (IAL): Is the user real? (Static, high confidence).
2. Session Authentication (AAL): Is the user currently who they say they are? (Dynamic, variable confidence).
3. Contextual Risk: Does the environment support this action? (Telemetry-driven).

If any of these inputs fail to meet the minimum threshold defined for the resource, the decision is "Deny." There is no "maybe" or "warn only" in the critical path. However, while IAL is static, resources requiring high IAL may still be accessible if the system policy allows high AAL (strong MFA) to satisfy the identity verification requirement, or explicitly states that the specific resource policy mandates a minimum IAL threshold that cannot be bypassed. For instance, if a user attempts to access a system requiring IAL-2 but only possesses IAL-1 credentials, the system denies access regardless of the AAL provided during login. This prevents lateral movement where an attacker might compromise a low-assurance account to access high-assurance resources.

Furthermore, BeyondTrust integrates this with Just-In-Time (JIT) access. Even if Alice has a permanent role with high privileges, she does not hold the keys until the specific request is made, the AAL is verified, and the session is time-boxed. This limits the "blast radius" of a compromised credential. The identity assurance is not a permanent key in a pocket; it is a temporary, context-aware ticket that expires the moment the risk profile changes.

This architecture ensures that the "Zero Trust" premise—never trust, always verify—is operationalized through measurable assurance levels. By forcing the AAL to align with the IAL and the contextual risk, organizations move beyond static passwords to a model where trust is a calculated variable, not an assumption. The integration of robust authentication protocols ensures that every access decision is backed by verified identity verification.

Conclusion

The result is a framework where the identity is the perimeter, and the perimeter is constantly moving. By rigorously applying AAL and IAL calculations to every access decision, BeyondTrust transforms identity from a static gatekeeper into a dynamic, risk-aware security control. While this model adds latency to the login process due to the continuous telemetry checks, the tradeoff is necessary for high-value assets. The cost of a false positive (blocking a legitimate user) is generally lower than the cost of a false negative (allowing a breach). Modern implementations mitigate this by using passive background checks to avoid friction for low-risk actions.

Common Pitfalls

Implementing this framework often leads to misconceptions that can undermine security. Be aware of these common pitfalls:

1. Confusing Static IAL with Dynamic AAL: Organizations often treat IAL (who you are) and AAL (how you are logging in) as interchangeable. Remember that IAL is a historical fact about enrollment, while AAL is a momentary assessment of the session.
2. Assuming High IAL Guarantees Security: A high IAL (e.g., verified in-person) does not protect against a compromised session. If the device posture is poor or the location is anomalous, the AAL drops, and the high IAL alone is insufficient to authorize sensitive actions.
3. Ignoring Device Posture: Focusing solely on user credentials while ignoring the device context is a critical failure. A compromised endpoint can invalidate the trust of even the highest-assured identity if the telemetry loop is not actively monitoring the device state.

Practical Takeaways

To successfully deploy this architecture, focus on these key implementation steps:

• Map Resources to Assurance Levels: Define specific AAL/IAL requirements for every critical asset, moving away from blanket "admin" permissions.
• Integrate Real-Time Telemetry: Ensure your policy engine has access to up-to-the-second data on device health, location, and behavior to drive accurate risk scores.
• Design for Adaptive Challenges: Configure the system to request additional factors (like MFA) rather than blocking access outright when risk increases, maintaining user experience while securing the perimeter.

FAQ

Q: What is the primary difference between AAL and IAL? A: IAL (Identity Assurance Level) measures the confidence in the identity's existence and ownership established during enrollment and remains static. AAL (Authentication Assurance Level) measures the confidence that the current user is the claimed entity at the moment of access and changes dynamically with every session.

Q: How does BeyondTrust handle "Adaptive Challenges"? A: When the calculated risk score exceeds the threshold for a resource, BeyondTrust triggers an adaptive challenge. This is a dynamic request for additional verification (like a second factor) to elevate the current session's AAL to meet the resource's requirement, rather than simply denying access.

Q: Is this framework compliant with NIST SP 800-63-3? A: Yes, the framework uses NIST SP 800-63-3 definitions for AAL and IAL levels. However, the specific implementation of the "Composite Risk Score" and the logic for triggering adaptive challenges are proprietary enhancements by BeyondTrust that apply these standards in a dynamic, context-aware manner.