Terms of Use and Authentication Strengths

Terms of Use in Microsoft Entra ID are custom documents (PDF, text, or HTML) that organizations can present to users during sign-in. Users must accept the terms before accessing the application or resource. This is commonly used for legal compliance, such as requiring acknowledgment of privacy policies, acceptable use policies, or consent to data handling. Administrators can create multiple terms of use, each with its own display name, document, and requirements.

When a user signs in and is directed to a Conditional Access policy that requires Terms of Use, the following sequence occurs:

Key properties of a Terms of Use object: - Name: A unique identifier for the terms. - Display name: Shown to users. - Document: The actual terms file (PDF, DOCX, or HTML). - Require re-acceptance: Can be set to expire after a specific number of days, or the user can be required to re-accept every time they sign in. - Require consent per user: When enabled, each user must accept individually. - Block access if declined: If enabled, users who decline are blocked from accessing the resource. - Conditional Access policy: The terms are assigned to one or more Conditional Access policies.

Portal:

PowerShell: Use the Microsoft Graph PowerShell module. Example:

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
$termsOfUse = New-MgIdentityConditionalAccessAuthenticationContextClassReference -DisplayName "My Terms" -Description "Acceptable Use Policy" -IsAvailable $true

Authentication Strengths (also called Authentication Context) allow administrators to define a minimum set of authentication methods required to access a resource. Instead of just requiring MFA, you can specify which types of MFA are acceptable. For example, you can require 'Phish-Resistant MFA' (FIDO2 keys or Windows Hello for Business) for highly sensitive apps, while allowing 'Password + SMS' for less sensitive ones.

Authentication Strengths are built-in or custom. Built-in strengths include: - MFA: Requires any combination of MFA methods (password + SMS, password + authenticator app, etc.). - Passwordless MFA: Requires passwordless methods like Windows Hello for Business, FIDO2, or Microsoft Authenticator. - Phish-Resistant MFA: Requires methods that are resistant to phishing, such as FIDO2 security keys or certificate-based authentication.

Authentication Strengths are evaluated during Conditional Access policy evaluation. The process:

Administrators can create custom Authentication Strengths by combining allowed authentication methods. For example, you might create a custom strength called 'High Security' that requires FIDO2 or certificate-based authentication, but not SMS.

Portal:

PowerShell:

$params = @{
    displayName = "High Security"
    description = "Requires FIDO2 or WHfB"
    allowedCombinations = @("fido2", "windowsHelloForBusiness")
}
New-MgPolicyAuthenticationStrengthPolicy -BodyParameter $params

Both Terms of Use and Authentication Strengths are used within Conditional Access policies. A single policy can include both a Terms of Use requirement and an Authentication Strength requirement. For example, a policy might require:

A hospital network must ensure that all employees accessing patient records have read and agreed to the HIPAA privacy policy annually. They create a Terms of Use document containing the policy and assign it to a Conditional Access policy targeting all users accessing the Electronic Health Records (EHR) application. The policy requires re-acceptance every 365 days. Additionally, to comply with security standards, they require Phish-Resistant MFA (FIDO2 keys) for EHR access. They create a custom Authentication Strength called 'HIPAA Access' that allows only FIDO2 and Windows Hello for Business. The Conditional Access policy uses both grant controls. In production, this works well but requires user training on FIDO2 keys. A common issue is users losing their security key, requiring a temporary exception policy. Performance is not impacted because terms are served from Azure's CDN.

A large corporation onboards external contractors who need access to a limited set of internal tools. To ensure contractors agree to the company's acceptable use policy, they create a Terms of Use document specific to contractors. They assign it to a Conditional Access policy that applies only to guest users (external identities) accessing the contractor portal. They set the terms to require re-acceptance every 30 days. Additionally, they require MFA (any method) for these contractors. The Authentication Strength is set to 'MFA' (built-in). A misconfiguration scenario: if the Terms of Use is not assigned to the correct policy, contractors might bypass the consent step. Monitoring via sign-in logs helps detect such gaps.

A bank uses Authentication Strengths to enforce tiered access. For online banking customers, they require MFA (SMS or authenticator app). For internal employees accessing the core banking system, they require Phish-Resistant MFA. They create two Conditional Access policies: one for customers with built-in 'MFA' strength, and one for employees with custom 'Banking Internal' strength requiring FIDO2. Terms of Use are used for employees to accept a code of conduct annually. A common problem is that users with older phones cannot use FIDO2, so the bank issues hardware security keys. Misconfiguring the Authentication Strength could allow employees to use SMS, which is less secure. Regular audits of sign-in logs ensure compliance.