An organization is implementing token protection in Microsoft Entra ID Conditional Access for users accessing Azure AI Foundry. Token protection binds the token to the device. Which scenario is prevented by enabling token protection?
Select an answer to reveal the explanation.
Short Explanation
Token protection binds the access token to the device that received it, so if someone steals it, they can’t replay it from another device against Azure AI Foundry. You’re protected because the resource checks the proof-of-possession key and rejects the token when it doesn’t match.
Full Explanation
The correct scenario is the one where an attacker replays a stolen access token from a different device to call Azure AI Foundry APIs. Token protection, also called token binding, cryptographically binds an access token to the specific device on which it was issued. If an attacker steals the token via an AiTM proxy or malware, they cannot use the token from a different device because the Azure AI Foundry resource will reject it—the token signature does not match the new device's proof-of-possession key.
The scenario involving a user signing in from an unregistered device is wrong because token protection does not prevent sign-ins from unregistered devices; device compliance is enforced through 'require compliant device' or 'require hybrid Entra joined device' grant controls. The scenario involving an attacker using a compromised password to sign in with MFA bypass is wrong because token protection secures issued tokens; it does not prevent credential compromise or MFA bypass—those are addressed by phishing-resistant MFA and risk-based policies. The scenario involving a user accessing Azure AI Foundry from an unmanaged network is wrong because network-based access restrictions are enforced through Named Locations in Conditional Access, not through token protection.