Microsoft Entra ID Protection for Small Business in Berlin

Stolen credentials remain the most common initial access vector in enterprise incidents. Phishing, password spray, credential stuffing, and malware-based credential theft all result in the same outcome: a valid username and password in an attacker’s hands. Multi-factor authentication significantly raises the bar, but MFA alone does not evaluate whether a sign-in is coming from a known device, a trusted location, or a behavioral pattern consistent with the legitimate user. Microsoft Entra ID Protection adds a risk signal layer to every authentication in your Entra ID tenant — assessing user risk (indicators that an account’s credentials have been compromised) and sign-in risk (indicators that a specific authentication attempt is not coming from the legitimate user) in real time and feeding those risk scores into Conditional Access policy decisions.

Entra ID Protection is included in Microsoft Entra ID P2, which is available in Microsoft 365 Business Premium. The feature requires no agents, no network sensors, and no configuration to begin generating risk signals — it operates on every sign-in from the moment it is licensed.

User risk vs. sign-in risk

ID Protection operates on two independent risk dimensions:

• Sign-in risk: The probability that a specific authentication attempt was not made by the legitimate account owner. Signals include anonymous IP address, atypical travel (signing in from Berlin and then Tokyo within two hours), unfamiliar sign-in properties (new device, new ASN, new country), malware-linked IP, and leaked credentials detected in real time. Risk is scored Low, Medium, or High.
• User risk: The probability that a user’s credentials have been compromised, accumulated over time from multiple signals. Signals include leaked credentials found in underground marketplaces (Microsoft monitors these and cross-references against Entra ID tenants), confirmed compromise from security operations, and high-risk sign-in history. User risk persists until remediated or dismissed.

Risk-based Conditional Access policies

ID Protection generates the risk signals; Conditional Access enforces the response. Risk-based CA policies are the operationally correct way to respond to risky sign-ins — automatic, proportionate, and reversible — rather than manual investigation of every alert.

The standard deployment is two policies:

• Sign-in risk policy: When sign-in risk is Medium or High, require MFA to complete the authentication. This forces the legitimate user to prove possession of the second factor at the moment of the risky sign-in, which blocks most credential-based attacks that do not also control the user’s registered MFA device. Configure as a Conditional Access policy targeting all users, all cloud apps, sign-in risk condition set to Medium and above, grant control: require MFA.
• User risk policy: When user risk is High, require the user to change their password using a secure MFA-backed reset. This remediates the underlying compromise condition rather than just blocking the current session. Configure similarly, user risk condition set to High, grant control: require password change.

Both policies should exclude the break-glass emergency access account from their scope to prevent lockout scenarios.

Risky users and risky sign-ins reports

Navigate to Entra admin center › Protection › Risky users and Risky sign-ins to review the current risk state of your tenant. The risky users report shows all accounts with elevated user risk and the contributing detections. The risky sign-ins report shows individual authentication events flagged as risky, including the detection type and risk level.

These reports are the primary operational interface for ID Protection. Security teams use them to review automated CA policy decisions, confirm or dismiss risk detections, and manually remediate accounts where the automated policy did not fully resolve the situation (for example, an account where the user changed their password but additional investigation is warranted).

Leaked credentials detection

Microsoft continuously monitors underground forums, paste sites, and dark web marketplaces for credential leaks and cross-references discovered username/password pairs against Entra ID tenants. When a match is found, user risk is elevated immediately — no waiting for a security team to discover and act on the breach manually. For a small Berlin business without a dedicated SOC, this detection represents external threat intelligence applied to the environment automatically, without requiring any configuration or subscription to external threat feeds.

Workload identity risk

ID Protection also evaluates risk for workload identities (service principals and managed identities), not just user accounts. Anomalous service principal behavior — such as a service principal authenticating from a new IP address, accessing unusual resources, or demonstrating credential exposure — is flagged as workload identity risk. This is particularly relevant for small businesses that use custom applications or automation scripts authenticated via Entra app registrations, where compromise of a service principal credential can be as damaging as a user credential compromise.

Integration with Microsoft Sentinel

The Entra ID connector for Microsoft Sentinel forwards the ID Protection risk events table (AADRiskyUsers, AADUserRiskEvents, AADRiskyServicePrincipals) into the Sentinel workspace. This enables correlation of identity risk signals with other data sources: if a user shows high sign-in risk and simultaneously generates an unusual DNS query logged in a network firewall, a Sentinel analytics rule can create a fused incident. For small businesses running both Sentinel and ID Protection, this integration turns identity risk signals from an isolated alert stream into part of a correlated detection picture.