A financial organization is implementing Access Context Manager to restrict access to sensitive production APIs. The security team defines the following security posture requirements: Access must be restricted to requests originating from designated corporate IP ranges. Users must authenticate specifically using phishing-resistant hardware security keys (such as Titan Security Keys or FIDO2 tokens). The authentication posture must be continuously enforced across sign-in sessions without falling back to password-only assertions. Which Access Context Manager configuration and identity management adjustment should the security engineer implement?

Create a Custom Access Level in Advanced Mode using Common Expression Language (CEL) evaluating request.auth.claims.crd_str.hwk == true and inIpRange(request.ip, ['...']), and disable the trusted device feature in 2-Step Verification settings.: What Custom Access Levels and Credential Strength Claims Are Access Context Manager (ACM) allows administrators to define fine-grained contextual access rules using either Basic Mode (attributes selected via GUI) or Advanced Mode (expressions written in Common Expression Language (CEL)). Custom Access Levels enable inspection of deep identity claims such as the specific credential strength (crd_str) used during user authentication, including passwords (pwd), SMS (sms), push notifications (push), software OTPs (otp), or hardware keys (hwk). How it meets the requirements Hardware key enforcement (request.auth.claims.crd_str.hwk == true): Advanced CEL expressions allow direct evaluation of whether the user completed 2-Step Verification using a physical hardware security key (hwk), fulfilling the phishing-resistant authentication mandate. IP boundary enforcement (inIpRange): CEL functions like inIpRange(request.ip, ['...']) enforce network perimeter checks alongside identity assertions within a single unified access level. Disabling trusted devices: Google 2-Step Verification includes a feature allowing users to mark devices as trusted to skip second-factor challenges on subsequent logins. If enabled, subsequent logins without a 2SV prompt cause Google to report credential strength as password-only (pwd) rather than hwk or mfa. Disabling trusted devices ensures hardware keys are presented on every sign-in, maintaining valid hwk assertions. Key advantages and capabilities Phishing resistance: Mandating hwk strictly prevents session hijacking through credential harvesting or SIM swapping. Granular logical combinations: Advanced Mode enables rich boolean logic (&&, ||, !) across identity, device, and network contexts. Consistent policy enforcement: Eliminating device-level factor caching guarantees that session assertions accurately reflect the real-time presentation of multi-factor hardware tokens. Why this is optimal Basic Access Levels only support coarse criteria such as IP subnets, geographic regions, and basic device state (such as OS version or encryption status). They cannot inspect authentication method claims or differentiate hardware keys from SMS or OTPs. Combining a CEL-based Custom Access Level with disabled trusted devices is the only way to enforce strict hardware-key compliance.

Require Hardware Keys With CEL and No Trusted Devices

Enforcing Hardware Key Authentication With CEL Access Levels

A financial organization is implementing Access Context Manager to restrict access to sensitive production APIs. The security team defines the following security posture requirements:

Access must be restricted to requests originating from designated corporate IP ranges.
Users must authenticate specifically using phishing-resistant hardware security keys (such as Titan Security Keys or FIDO2 tokens).
The authentication posture must be continuously enforced across sign-in sessions without falling back to password-only assertions.

Which Access Context Manager configuration and identity management adjustment should the security engineer implement?

Create a Basic Access Level with IP conditions and configure an Organization Policy constraint to enforce hardware security keys across the resource hierarchy.

Create a Custom Access Level evaluating request.auth.claims.crd_str.mfa == true in Advanced Mode, while keeping the trusted device feature enabled to streamline user sign-ins.

Create a Basic Access Level specifying the corporate IP subnets and device policy requirements, and enable the trusted device feature in 2-Step Verification settings to cache hardware key assertions.

Create a Custom Access Level in Advanced Mode using Common Expression Language (CEL) evaluating request.auth.claims.crd_str.hwk == true and inIpRange(request.ip, ['...']), and disable the trusted device feature in 2-Step Verification settings.

Explanations

Create a Basic Access Level with IP conditions and configure an Organization Policy constraint to enforce hardware security keys across the resource hierarchy.

What Basic Access Levels and Organization Policies Do

Basic Access Levels restrict resource access based on IP ranges and basic endpoint metadata. Organization Policies provide centralized governance over resource configurations, constraints, and service usage across projects and folders in a Google Cloud Organization.

Why it doesn't meet the requirements

Improper enforcement layer: Organization Policies govern Google Cloud resource behaviors and API settings (such as disabling external IP addresses or restricting resource locations); they do not inspect user authentication tokens, evaluate 2-Step Verification methods, or enforce hardware token presentation per request.
Basic mode limitations: Basic Access Levels cannot combine network boundaries with user authentication claims (request.auth.claims), which requires Advanced Mode CEL expressions in Access Context Manager.

Key limitations

Organization Policies do not evaluate user session credential strength at request time.
Basic Access Levels lack the expression engine needed to inspect authentication claim headers.
This approach fails to address the credential downgrade caused by the trusted device setting.

This answer would be correct if

The requirement was to enforce static configuration guardrails on cloud infrastructure (e.g., restricting which regions resources can be deployed to) combined with basic IP filtering, rather than evaluating live authentication claims.

View source documentation

Create a Custom Access Level evaluating request.auth.claims.crd_str.mfa == true in Advanced Mode, while keeping the trusted device feature enabled to streamline user sign-ins.

What the crd_str.mfa claim and Trusted Devices Do

The request.auth.claims.crd_str.mfa attribute evaluates whether a user authenticated with any supported multi-factor authentication method except password-only (pwd). This includes SMS codes, mobile push prompts, software OTPs (swk/otp), and hardware keys (hwk).

Why it doesn't meet the requirements

Broad MFA scope: The crd_str.mfa claim is satisfied by weaker, phishing-susceptible authentication methods such as SMS or mobile push notifications, failing the requirement to mandate physical hardware security keys specifically.
Broken enforcement via trusted devices: When trusted devices remain enabled, users who log back in without a 2SV prompt are reported as pwd (password-only). Under this condition, legitimate users on trusted machines would have request.auth.claims.crd_str.mfa == false, resulting in unexpected access denials.

Key limitations

crd_str.mfa does not isolate phishing-resistant FIDO2/Titan hardware keys (hwk).
Trusted device caching invalidates MFA claims on recurring sessions by suppressing second-factor prompts.

This answer would be correct if

The organization accepted any standard multi-factor authentication method (including SMS and push notifications) and did not have workflows strictly dependent on continuous hardware-key verification.

View source documentation

Create a Basic Access Level specifying the corporate IP subnets and device policy requirements, and enable the trusted device feature in 2-Step Verification settings to cache hardware key assertions.

What Basic Access Levels and Device Trusting Do

Basic Access Levels provide GUI-based configuration for standard attributes like IP subnet ranges, client regions, and device policy attributes managed by Endpoint Verification (such as screen lock, disk encryption, and OS versions). The trusted device feature in 2-Step Verification allows users to bypass second-factor prompts on recognized machines.

Why it doesn't meet the requirements

No credential strength evaluation: Basic Access Levels cannot parse or evaluate authentication assertions such as crd_str.hwk. They only inspect device management states and network attributes, leaving authentication method strength unverified.
Incorrect assertion caching: Enabling trusted devices does not preserve or cache strong credential assertions. Instead, it bypasses the second-factor prompt, causing Google's identity system to classify subsequent logins as password-only (pwd), which would fail any strict MFA or hardware-key security requirement.

Key limitations

Basic mode lacks Common Expression Language (CEL) support for inspecting request.auth.claims.
It cannot distinguish between phishing-resistant hardware keys, software OTPs, or SMS authentication.
Trusted devices degrade the reported credential strength claim to pwd upon session renewal.

This answer would be correct if

The organization only required managed device health attributes (such as OS version and full-disk encryption) and static IP restrictions without enforcing specific phishing-resistant authentication methods or claims inspection.

View source documentation

Create a Custom Access Level in Advanced Mode using Common Expression Language (CEL) evaluating request.auth.claims.crd_str.hwk == true and inIpRange(request.ip, ['...']), and disable the trusted device feature in 2-Step Verification settings.

What Custom Access Levels and Credential Strength Claims Are

Access Context Manager (ACM) allows administrators to define fine-grained contextual access rules using either Basic Mode (attributes selected via GUI) or Advanced Mode (expressions written in Common Expression Language (CEL)). Custom Access Levels enable inspection of deep identity claims such as the specific credential strength (crd_str) used during user authentication, including passwords (pwd), SMS (sms), push notifications (push), software OTPs (otp), or hardware keys (hwk).

How it meets the requirements

Hardware key enforcement (request.auth.claims.crd_str.hwk == true): Advanced CEL expressions allow direct evaluation of whether the user completed 2-Step Verification using a physical hardware security key (hwk), fulfilling the phishing-resistant authentication mandate.
IP boundary enforcement (inIpRange): CEL functions like inIpRange(request.ip, ['...']) enforce network perimeter checks alongside identity assertions within a single unified access level.
Disabling trusted devices: Google 2-Step Verification includes a feature allowing users to mark devices as trusted to skip second-factor challenges on subsequent logins. If enabled, subsequent logins without a 2SV prompt cause Google to report credential strength as password-only (pwd) rather than hwk or mfa. Disabling trusted devices ensures hardware keys are presented on every sign-in, maintaining valid hwk assertions.

Key advantages and capabilities

Phishing resistance: Mandating hwk strictly prevents session hijacking through credential harvesting or SIM swapping.
Granular logical combinations: Advanced Mode enables rich boolean logic (&&, ||, !) across identity, device, and network contexts.
Consistent policy enforcement: Eliminating device-level factor caching guarantees that session assertions accurately reflect the real-time presentation of multi-factor hardware tokens.

Why this is optimal

Basic Access Levels only support coarse criteria such as IP subnets, geographic regions, and basic device state (such as OS version or encryption status). They cannot inspect authentication method claims or differentiate hardware keys from SMS or OTPs. Combining a CEL-based Custom Access Level with disabled trusted devices is the only way to enforce strict hardware-key compliance.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Enforcing Hardware Key Authentication With CEL Access Levels

A financial organization is implementing Access Context Manager to restrict access to sensitive production APIs. The security team defines the following security posture requirements:

Access must be restricted to requests originating from designated corporate IP ranges.
Users must authenticate specifically using phishing-resistant hardware security keys (such as Titan Security Keys or FIDO2 tokens).
The authentication posture must be continuously enforced across sign-in sessions without falling back to password-only assertions.

Which Access Context Manager configuration and identity management adjustment should the security engineer implement?

Create a Basic Access Level with IP conditions and configure an Organization Policy constraint to enforce hardware security keys across the resource hierarchy.

Create a Custom Access Level evaluating request.auth.claims.crd_str.mfa == true in Advanced Mode, while keeping the trusted device feature enabled to streamline user sign-ins.

Create a Basic Access Level specifying the corporate IP subnets and device policy requirements, and enable the trusted device feature in 2-Step Verification settings to cache hardware key assertions.

Explanations

Create a Basic Access Level with IP conditions and configure an Organization Policy constraint to enforce hardware security keys across the resource hierarchy.

What Basic Access Levels and Organization Policies Do

Why it doesn't meet the requirements

Improper enforcement layer: Organization Policies govern Google Cloud resource behaviors and API settings (such as disabling external IP addresses or restricting resource locations); they do not inspect user authentication tokens, evaluate 2-Step Verification methods, or enforce hardware token presentation per request.
Basic mode limitations: Basic Access Levels cannot combine network boundaries with user authentication claims (request.auth.claims), which requires Advanced Mode CEL expressions in Access Context Manager.

Key limitations

Organization Policies do not evaluate user session credential strength at request time.
Basic Access Levels lack the expression engine needed to inspect authentication claim headers.
This approach fails to address the credential downgrade caused by the trusted device setting.

This answer would be correct if

View source documentation

Create a Custom Access Level evaluating request.auth.claims.crd_str.mfa == true in Advanced Mode, while keeping the trusted device feature enabled to streamline user sign-ins.

What the crd_str.mfa claim and Trusted Devices Do

Why it doesn't meet the requirements

Broad MFA scope: The crd_str.mfa claim is satisfied by weaker, phishing-susceptible authentication methods such as SMS or mobile push notifications, failing the requirement to mandate physical hardware security keys specifically.
Broken enforcement via trusted devices: When trusted devices remain enabled, users who log back in without a 2SV prompt are reported as pwd (password-only). Under this condition, legitimate users on trusted machines would have request.auth.claims.crd_str.mfa == false, resulting in unexpected access denials.

Key limitations

crd_str.mfa does not isolate phishing-resistant FIDO2/Titan hardware keys (hwk).
Trusted device caching invalidates MFA claims on recurring sessions by suppressing second-factor prompts.

This answer would be correct if

The organization accepted any standard multi-factor authentication method (including SMS and push notifications) and did not have workflows strictly dependent on continuous hardware-key verification.

View source documentation

Create a Basic Access Level specifying the corporate IP subnets and device policy requirements, and enable the trusted device feature in 2-Step Verification settings to cache hardware key assertions.

What Basic Access Levels and Device Trusting Do

Why it doesn't meet the requirements

No credential strength evaluation: Basic Access Levels cannot parse or evaluate authentication assertions such as crd_str.hwk. They only inspect device management states and network attributes, leaving authentication method strength unverified.
Incorrect assertion caching: Enabling trusted devices does not preserve or cache strong credential assertions. Instead, it bypasses the second-factor prompt, causing Google's identity system to classify subsequent logins as password-only (pwd), which would fail any strict MFA or hardware-key security requirement.

Key limitations

Basic mode lacks Common Expression Language (CEL) support for inspecting request.auth.claims.
It cannot distinguish between phishing-resistant hardware keys, software OTPs, or SMS authentication.
Trusted devices degrade the reported credential strength claim to pwd upon session renewal.

This answer would be correct if

View source documentation

Create a Custom Access Level in Advanced Mode using Common Expression Language (CEL) evaluating request.auth.claims.crd_str.hwk == true and inIpRange(request.ip, ['...']), and disable the trusted device feature in 2-Step Verification settings.

What Custom Access Levels and Credential Strength Claims Are

How it meets the requirements

Hardware key enforcement (request.auth.claims.crd_str.hwk == true): Advanced CEL expressions allow direct evaluation of whether the user completed 2-Step Verification using a physical hardware security key (hwk), fulfilling the phishing-resistant authentication mandate.
IP boundary enforcement (inIpRange): CEL functions like inIpRange(request.ip, ['...']) enforce network perimeter checks alongside identity assertions within a single unified access level.
Disabling trusted devices: Google 2-Step Verification includes a feature allowing users to mark devices as trusted to skip second-factor challenges on subsequent logins. If enabled, subsequent logins without a 2SV prompt cause Google to report credential strength as password-only (pwd) rather than hwk or mfa. Disabling trusted devices ensures hardware keys are presented on every sign-in, maintaining valid hwk assertions.

Key advantages and capabilities

Phishing resistance: Mandating hwk strictly prevents session hijacking through credential harvesting or SIM swapping.
Granular logical combinations: Advanced Mode enables rich boolean logic (&&, ||, !) across identity, device, and network contexts.
Consistent policy enforcement: Eliminating device-level factor caching guarantees that session assertions accurately reflect the real-time presentation of multi-factor hardware tokens.

Why this is optimal

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Enforcing Hardware Key Authentication With CEL Access Levels

Explanations

Create a Basic Access Level with IP conditions and configure an Organization Policy constraint to enforce hardware security keys across the resource hierarchy.

What Basic Access Levels and Organization Policies Do

Why it doesn't meet the requirements

Key limitations

This answer would be correct if

Create a Custom Access Level evaluating request.auth.claims.crd_str.mfa == true in Advanced Mode, while keeping the trusted device feature enabled to streamline user sign-ins.

What the crd_str.mfa claim and Trusted Devices Do

Why it doesn't meet the requirements

Key limitations

This answer would be correct if

Create a Basic Access Level specifying the corporate IP subnets and device policy requirements, and enable the trusted device feature in 2-Step Verification settings to cache hardware key assertions.

What Basic Access Levels and Device Trusting Do

Why it doesn't meet the requirements

Key limitations

This answer would be correct if

Create a Custom Access Level in Advanced Mode using Common Expression Language (CEL) evaluating request.auth.claims.crd_str.hwk == true and inIpRange(request.ip, ['...']), and disable the trusted device feature in 2-Step Verification settings.

What Custom Access Levels and Credential Strength Claims Are

How it meets the requirements

Key advantages and capabilities

Why this is optimal

Try 10 interactive questions like this one, free

Related questions

VPC Service Controls Perimeter Bridge

Violation Analyzer Organization Scope Live Policy

Binary Authorization Attestation Enforcement

Private Google Access with Restricted VIP

Alias IP Ranges and Multi-NIC VMs

BigQuery Reservations and Idle Slot Sharing

Enforcing Hardware Key Authentication With CEL Access Levels

Explanations

Create a Basic Access Level with IP conditions and configure an Organization Policy constraint to enforce hardware security keys across the resource hierarchy.

What Basic Access Levels and Organization Policies Do

Why it doesn't meet the requirements

Key limitations

This answer would be correct if

Create a Custom Access Level evaluating request.auth.claims.crd_str.mfa == true in Advanced Mode, while keeping the trusted device feature enabled to streamline user sign-ins.

What the crd_str.mfa claim and Trusted Devices Do

Why it doesn't meet the requirements

Key limitations

This answer would be correct if

Create a Basic Access Level specifying the corporate IP subnets and device policy requirements, and enable the trusted device feature in 2-Step Verification settings to cache hardware key assertions.

What Basic Access Levels and Device Trusting Do

Why it doesn't meet the requirements

Key limitations

This answer would be correct if

Create a Custom Access Level in Advanced Mode using Common Expression Language (CEL) evaluating request.auth.claims.crd_str.hwk == true and inIpRange(request.ip, ['...']), and disable the trusted device feature in 2-Step Verification settings.

What Custom Access Levels and Credential Strength Claims Are

How it meets the requirements

Key advantages and capabilities

Why this is optimal

Try 10 interactive questions like this one, free

Related questions

VPC Service Controls Perimeter Bridge

Violation Analyzer Organization Scope Live Policy

Binary Authorization Attestation Enforcement

Private Google Access with Restricted VIP

Alias IP Ranges and Multi-NIC VMs

BigQuery Reservations and Idle Slot Sharing