SC-900 Questions and Answers

When you register an application through the Azure portal, an application object and service principal are automatically created in your home directory or tenant.

In Microsoft guidance, network segmentation and isolation are core security principles. Azure virtual networks (VNets) are “a fundamental building block… that enable isolation and segmentation of resources,” and multiple VNets are commonly used to separate environments, business units, or security boundaries. This aligns with Zero Trust and SCI guidance that recommends isolating workloads to reduce blast radius and to apply least privilege and policy-based controls per boundary. Microsoft also emphasizes governance alignment, stating that enterprises should structure Azure resources so that policies, RBAC, and compliance requirements can be applied at appropriate scopes (management group, subscription, resource group, or network boundary). Deploying multiple VNets supports these goals by enabling per-environment policy assignment (for example, dev/test vs. production), differentiated security controls (such as NSGs, ASGs, and firewalls), and independent address spaces to prevent overlap across organizations or regions. Options A and D are not primary drivers: budgeting is handled at subscription/resource group scopes rather than VNet count, and a single VNet can already host and connect many resource types; creating multiple VNets is therefore primarily about governance and isolation that reduce risk and enforce organizational policies.

The Microsoft Service Trust Portal contains details about Microsoft's implementation of controls and processes that protect our cloud services and the customer data therein.

Yes

NO

NO

YES - As an administrator, you can lock a subscription, resource group, or resource to prevent other users in your organization from accidentally deleting or modifying critical resources. The lock overrides any permissions the user might have.

NO - The most restrictive lock in the inheritance takes precedence.

NO - If you delete a resource group with a locked resource, the portal UI will give you an error and no resources are deleted.

https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources?tabs=json

Microsoft states that Azure AD Multi-Factor Authentication “adds a second form of verification” to sign-ins and supports multiple verification methods. The documented methods include Microsoft Authenticator app notifications or verification codes, text message (SMS) codes, and phone call verification. In Microsoft’s description, users can approve a push notification in the Microsoft Authenticator app or enter a code from the app; they can receive a text message containing a verification code; or they can answer a phone call to complete the challenge. Email verification and security questions are not listed as supported MFA methods for Azure AD sign-ins and are not valid second factors in Azure AD MFA. Consequently, the correct methods from the options provided are Phone call, Text message (SMS), and Microsoft Authenticator app. These align with Azure AD’s core MFA capabilities used in Conditional Access and per-user MFA to strengthen authentication beyond the password and to meet compliance and security requirements for strong user verification.

In Microsoft Azure, an NSG consists of ordered security rules evaluated by priority. The Azure documentation specifies that every rule includes identifying metadata and must be uniquely named within the NSG: “Each security rule has a name that is unique within the network security group.” Rule evaluation is deterministic: “Security rules are processed in priority order… once a rule matches traffic, processing stops.”

Azure creates several default security rules in every NSG to provide a safe baseline. These defaults are protected: “You can’t remove the default security rules, but you can override them by creating rules with a higher priority.” This means deletion of default rules is not allowed; administrators add custom rules with lower priority numbers to supersede the defaults as needed.

Regarding protocols, NSG rules can target specific L4/L3 protocols. The platform guidance states that the rule Protocol field supports TCP, UDP, ICMP, or Any: “For Protocol, specify TCP, UDP, ICMP, or Any.” Therefore, configuring rules to check TCP, UDP, or ICMP traffic types is fully supported.

Putting this together: (1) unique rule names are required (Yes), (2) default rules cannot be deleted (No), and (3) NSG rules can indeed be configured for TCP/UDP/ICMP (Yes). These behaviors align with Azure’s prescribed NSG design and management model used across Microsoft Security, Compliance, and Identity learning content.

Microsoft describes Windows Hello for Business (WHfB) as replacing passwords with a device-bound credential: “Windows Hello for Business replaces passwords with strong two-factor authentication on devices. This authentication consists of a new type of user credential that is tied to a device and uses a biometric or a PIN.” WHfB authenticators are biometric gesture or PIN unlocking an asymmetric key stored on the device (typically in the TPM). Microsoft clarifies that the PIN is not a password and is “local to the device” and used to unlock the user’s private key. Consequently, Yes—a PIN is a supported WHfB sign-in gesture.

Conversely, the Microsoft Authenticator app is a separate Azure AD (Microsoft Entra ID) authentication method (push notifications, TOTP, passwordless phone sign-in). It is not the WHfB credential; WHfB relies on keys/certificates on the device, not on the Authenticator app.

Finally, WHfB credentials are per-device: Microsoft states the credential is “tied to a device” and the private key never leaves the device, which means it does not roam/sync across a user’s different devices. Each device enrolls and provisions its own WHfB key and gesture. These statements from Microsoft SCI documentation lead to the outcomes: No / Yes / No.

 Compliance Manager tracks only customer-managed controls. No

 Compliance Manager provides predefined templates for creating assessments. Yes

 Compliance Manager can help you assess whether data adheres to specific data protection standards. No

Microsoft Purview Compliance Manager is described as a feature that “helps you manage your organization’s compliance requirements” by giving you assessments, improvement actions, and a compliance score that “measures your progress in completing recommended actions” aligned to regulations and standards. The service does not track only customer-managed controls; Microsoft’s documentation clarifies that Compliance Manager includes “Microsoft-managed controls and customer-managed controls,” and it tracks both within each assessment to show overall posture. It also provides prebuilt (predefined) assessment templates for common regulations and industry standards so organizations can “create assessments from templates” such as GDPR, ISO/IEC 27001, and the Data Protection Baseline.

Importantly, Compliance Manager evaluates control implementation and improvement actions mapped to requirements; it does not scan or classify individual data to determine whether specific data items “adhere” to a standard. Instead, it helps you assess organizational compliance posture by tracking the status of controls, assigning actions, and recording evidence. Thus:

“Tracks only customer-managed controls” → No (it tracks Microsoft-managed and customer-managed).

“Provides predefined templates for creating assessments” → Yes (prebuilt templates are a core feature).

“Helps you assess whether data adheres to specific data protection standards” → No (it measures control/compliance posture, not data-level adherence).

Box 1: No

Compliance Manager tracks Microsoft managed controls, customer-managed controls, and shared controls. Box 2: Yes

Box 3: Yes

Microsoft Purview Data Loss Prevention (DLP) is designed to prevent the inadvertent or inappropriate sharing of sensitive data across Microsoft 365 services. Microsoft’s guidance states that DLP “helps you discover, monitor, and protect sensitive items across Microsoft 365,” and that with DLP policies you can “identify, monitor, and automatically protect sensitive items in Exchange Online, SharePoint Online, OneDrive for Business, and Microsoft Teams.” This directly supports option C, because DLP can detect sensitive info in OneDrive documents and automatically apply protective actions such as blocking external sharing, restricting access, or auditing the event.

DLP also provides end-user coaching through policy tips: “Policy tips are informative notices that appear when users are working with content that contains sensitive info … to help prevent data loss.” When a user is about to send or share sensitive data in violation of policy, these tips surface in Outlook and Office apps (including when files are stored in SharePoint/OneDrive), aligning with option A.

By contrast, enabling disk encryption (e.g., BitLocker) and applying device security baselines are endpoint/device management tasks handled through Microsoft Intune or Group Policy—not by DLP. Therefore, A and C are the correct tasks you can implement with Microsoft 365 DLP policies.

In Microsoft Sentinel, automation is delivered through playbooks, which are built on Azure Logic Apps. Microsoft’s Sentinel documentation explains that playbooks “help automate and orchestrate your response to threats” and can be triggered by analytics alerts or incidents to run predefined actions. Typical automated tasks include “enriching alerts with data, blocking IP addresses, disabling users, or creating tickets,” allowing security teams to standardize and speed up their response and remediation processes. Sentinel also uses automation rules to decide when a playbook should run (for example, on incident creation or update), enabling consistent handling of common SOC tasks.

By contrast, the other options are not intended for automation: deep investigation tools are used to investigate incidents and entities; hunting search-and-query tools (built on KQL) are for proactive threat hunting rather than automating responses; and workbooks provide dashboards and visualizations for monitoring and reporting. Therefore, when the requirement is to automate common tasks—such as triggering actions across Microsoft 365 Defender, Azure, or third-party systems—the correct Sentinel capability is playbooks powered by Logic Apps. This aligns with the SCI guidance that emphasizes using Sentinel playbooks to “automate common workflows and response actions” and reduce manual effort while improving consistency and speed in security operations.

In the Microsoft 365 security center (now Microsoft 365 Defender), incidents are used to triage and investigate threats across the tenant. Microsoft’s security documentation explains that “an incident is a collection of related alerts” that are automatically correlated to give analysts a single, end-to-end view of an attack. Within each incident, the portal surfaces impacted assets such as devices, users, mailboxes, and applications, enabling responders to quickly identify which endpoints are affected by a given alert and to take response actions (isolate device, collect investigation package, run AV scan, etc.). This design allows security teams to move beyond individual alerts and instead work a consolidated investigation that lists affected devices in the incident’s Evidence & Response/Assets sections, complete with alert timelines and device details.

By comparison, Secure Score measures the organization’s security posture and recommendations; policies are configuration/enforcement objects (e.g., Defender or compliance policies) and are not the investigative view for alerts; classifications relate to information protection labeling rather than alert investigation. Therefore, to identify devices that are affected by an alert, you use the Incidents experience in Microsoft 365 Defender, where correlated alerts show the devices involved alongside the entities and evidence connected to the threat.

In Microsoft’s SCI learning content, the core objective of protecting information is framed by the CIA triad. Microsoft explains that “confidentiality, integrity, and availability are foundational security principles.” Within this model, integrity is described as the assurance that information remains trustworthy and unchanged from its intended state. The SCI materials state that integrity means “preventing unauthorized modification and ensuring the accuracy and completeness of data.” When a requirement says, “ensuring that the data you retrieve is the same as the data you stored,” it directly maps to this integrity principle—verifying that data hasn’t been altered, corrupted, or tampered with during storage or transmission.

Microsoft’s guidance further highlights that integrity is supported by controls that “detect or prevent unauthorized changes,” including cryptographic hashes, checksums, and digital signatures that can “provide proof that content hasn’t been modified.” By contrast, confidentiality focuses on restricting access (for example, through least privilege and encryption), and availability focuses on “reliable and timely access to information and systems.” Because the scenario emphasizes that the retrieved data is identical to the stored data, it is not about access or uptime but about preserving correctness and detecting alteration—which is precisely the integrity objective in Microsoft’s Security, Compliance, and Identity guidance.

The recommended way to enable and use Azure AD Multi-Factor Authentication is with Conditional Access policies. Conditional Access lets you create and define policies that react to sign-in events and that request additional actions before a user is granted access to an application or service.

Azure Bastion is a managed PaaS service that provides secure and seamless RDP/SSH connectivity to your Azure virtual machines directly from the Azure portal over TLS/HTTPS. SCI and Azure security documentation summarize it as eliminating public IP exposure on VMs by using a fully managed bastion host deployed inside your virtual network. Users connect through their browser and the service brokers the RDP or SSH session, which “protects your VMs from exposing RDP/SSH to the Internet.” Bastion does not provide access to Azure Files, SQL Managed Instance, or App Service; it is specifically built to secure management access to VMs without requiring a VPN or public endpoints. Therefore, the resource type Azure Bastion securely connects to is Azure virtual machines.

Microsoft Learn explains that Azure Active Directory (now Microsoft Entra ID) is a Microsoft-managed identity and access management service delivered from the cloud. It does not require you to provision or host infrastructure such as virtual machines; the directory is operated as a service by Microsoft, and tenants are created and administered within Microsoft’s cloud environment. The official learning paths further clarify that administration is performed through the Azure portal (the Entra/Microsoft Entra admin center and Azure portal blades), PowerShell, and Graph—so managing a tenant in the Azure portal is fully supported.

Regarding licensing, Microsoft’s SCI study materials detail that Azure AD/Entra ID is offered in multiple editions (Free, Microsoft 365 apps edition, Premium P1, and Premium P2). Each edition unlocks different capabilities: for example, features like Conditional Access are in Premium tiers; Identity Protection and Privileged Identity Management (PIM) are P2 capabilities. Because capabilities vary by tier, the statement that all license editions include the same features is incorrect.

Putting this together: feature parity across editions is not the case (No); tenant management in the Azure portal is supported (Yes); and you do not need to deploy Azure VMs to host an Azure AD/Entra ID tenant (No).

For Azure data services such as Azure SQL Managed Instance, Microsoft provides threat detection and protection through Microsoft Defender for Cloud (via Microsoft Defender for SQL). Microsoft documentation states that Defender for Cloud “provides advanced threat protection for your SQL resources,” including Azure SQL Database and Azure SQL Managed Instance, by “continuously monitoring for anomalous activities and potential SQL injection, brute force, and exploitation attempts.” When enabled, the plan “generates security alerts when suspicious activities are detected,” and these alerts can be surfaced in Defender for Cloud, forwarded to Microsoft Sentinel, or integrated with workflows for response. Microsoft Secure Score is a security posture metric, application security groups are for network segmentation in Azure, and Azure Bastion provides secure RDP/SSH over TLS—none of these deliver database-specific threat detection. Therefore, to provide threat detection for Azure SQL Managed Instance, you use Microsoft Defender for Cloud (Defender for SQL).

In Microsoft Purview Compliance Manager, improvement actions are categorized by control type to reflect how they reduce risk and contribute to your compliance score. Microsoft’s SCI guidance explains that preventative controls are safeguards that “prevent a security or compliance incident from occurring by enforcing protections in advance (for example, enforcing encryption of data at rest and in transit, access restrictions, and configuration baselines).” This directly aligns with the task “Use encryption to protect data at rest”, which is a classic prevention mechanism intended to stop unauthorized disclosure before it can happen.

The guidance also states that detective controls are measures that “identify, log, and surface anomalous or non-compliant activities so they can be investigated and addressed (for example, continuous monitoring, alerting, audit logging, and analytics).” This maps to “Actively monitor systems to identify irregularities that might represent risks”, because the goal is to detect suspicious behavior or drift as it occurs.

By comparison, corrective controls are used to “remediate issues and restore a desired state after a problem is discovered (for example, patching, incident response, or configuration correction).” No corrective action is described in the two listed tasks, so Corrective is not selected. This mapping reflects how Compliance Manager classifies actions that contribute points to the compliance score based on their risk-reducing impact.

Microsoft states that Identity Protection is used to “detect potential vulnerabilities affecting your organization’s identities, configure automated responses, and investigate suspicious actions related to your organization’s identities.” It evaluates user risk and sign-in risk using detections such as “leaked credentials, anonymous IP address, unfamiliar sign-in properties, [and] impossible travel.” These built-in detections confirm that the service can detect whether valid user credentials have been found in public or criminal datasets—commonly referred to as leaked credentials—thereby reducing identity compromise risk.

Identity Protection includes policy controls that “automate the response to detected risks,” specifically the User risk policy and Sign-in risk policy. Microsoft describes that these policies can “require password change when user risk is detected” and “require multi-factor authentication when sign-in risk is detected.” Therefore, Identity Protection can invoke MFA based on risk as part of Conditional Access–backed risk policies.

However, Identity Protection does not perform group lifecycle management. Microsoft positions group membership automation under Azure AD dynamic groups/Identity Governance, not Identity Protection. Consequently, adding users to groups based on risk level is not a function of Identity Protection, which focuses on detection, risk evaluation, and policy-driven remediation (e.g., MFA or password reset), not group assignment.

Microsoft Purview Compliance Manager organizes improvement actions into control action subcategories that mirror core security control types used throughout Microsoft Learn’s SCI content: preventative, detective, and corrective. In the SC-900 security fundamentals guidance, Microsoft describes these control types as follows: “Preventive controls are intended to deter or stop an attack from occurring (for example, encryption and access controls). Detective controls are used to discover and detect attacks that are in progress or have occurred (for example, logging, auditing, and monitoring). Corrective controls are used to limit the damage caused by an incident and to return systems to normal operations (for example, configuration changes, incident response, and recovery activities).”

Applying those definitions to Compliance Manager actions: Encrypt data at rest is a preventative control because it deters exposure by protecting data before an event. Perform a system access audit is a detective action because auditing and reviewing access logs are used to discover and detect misuse or anomalies. Make configuration changes in response to a security incident is a corrective action because it remediates and restores the environment after detection, aligning with Compliance Manager’s corrective action guidance. These mappings reflect how Compliance Manager measures completion of improvement actions that reduce compliance risk through the right mix of preventative, detective, and corrective controls.

Microsoft defines hybrid identity as enabling a common identity across on-premises and cloud by integrating your directory services. Microsoft Learn states: “Hybrid identity is achieved by integrating your on-premises Active Directory with Azure Active Directory.” This integration is delivered through the synchronization and optional federation capabilities that connect AD DS to Azure AD so users can access both on-premises and cloud resources with one identity.

To implement this integration, Microsoft’s tooling is explicit: “Azure AD Connect is the Microsoft tool designed to meet and accomplish your hybrid identity goals.” Azure AD Connect (now Microsoft Entra Connect) synchronizes users, groups, and optionally passwords or hashes to Azure AD, providing the foundation for hybrid scenarios such as single sign-on and seamless sign-in.

Regarding tenants, Microsoft’s identity platform clarifies that “A Microsoft 365 organization is associated with a single Azure AD tenant.” Therefore, a hybrid identity deployment does not require two Microsoft 365 tenants; it typically links a single Azure AD (Microsoft Entra ID) tenant with one or more on-premises AD DS forests. In summary, Azure AD Connect enables hybrid identity, hybrid identity is the synchronization/integration of AD DS with Azure AD, and it does not necessitate multiple Microsoft 365 tenants.

Microsoft Entra ID Identity Protection is a risk-based conditional access capability that “automates the detection and remediation of identity-based risks” and enables admins to investigate risky users and sign-ins. SCI guidance explains that Identity Protection evaluates signals such as user risk and sign-in risk, raises risk detections, and can automatically remediate by enforcing actions like password reset or blocking access via risk-based policies. The portal provides rich investigation experiences for risky users, risky sign-ins, and risk detections, allowing security teams to review evidence and confirm/dismiss risks. In addition, identity risk data can be exported through Azure Monitor/diagnostic settings and integrated with SIEM/SOAR tools, enabling “export of risk detections and security alerts to third-party solutions” for correlation and response. Tasks such as configuring external access for partner organizations are handled by B2B collaboration features, and creating/assigning sensitivity labels belongs to Microsoft Purview Information Protection—not Identity Protection. Therefore, the tasks Identity Protection supports are: export risk detection (B), automate detection and remediation of identity-based risks (C), and investigate risks related to user authentication (D).

In Microsoft 365 compliance, sensitivity labels (Microsoft Purview Information Protection) are the feature designed to classify and automatically protect data. Microsoft states that sensitivity labels “let you classify and protect your organization’s data” and that a label “can apply protection settings such as encryption” to files and emails. Labels can be deployed so that protection is applied without user action: Microsoft explains that labels “can be applied automatically, recommended, or by users,” and that administrators can “auto-apply a sensitivity label to content in SharePoint, OneDrive, and Exchange based on conditions such as sensitive info types, keywords, or trainable classifiers.” When a label with protection is applied, “encryption settings travel with the content” and enforce usage rights like who can open, print, or forward, even outside the organization.

By contrast, Content Search and eDiscovery are discovery/investigative tools and do not enforce protection. Retention policies manage how long content is kept or deleted, but they don’t encrypt content. Therefore, the Microsoft 365 compliance capability that encrypts content automatically based on specific conditions is sensitivity labels with auto-labeling policies in Microsoft Purview.

In Microsoft Defender for Cloud (formerly Azure Security Center), Secure score is defined as “a measurement of an organization’s security posture; the higher the score, the lower the identified risk.” Microsoft states that Defender for Cloud provides security recommendations that “help you harden your resources and increase your secure score.” Among these recommendations is “Apply system updates” for virtual machines—Microsoft describes it as ensuring that “machines should have the latest security updates installed”, and completing this action adds points to your secure score because it remediates a vulnerability class (missing patches).

Defender for Cloud also supports wide scope evaluation: you can “view and manage the secure score across subscriptions and management groups,” allowing organizations with multiple Azure subscriptions to see an aggregated and per-scope score and track improvement actions consistently.

Identity protections are part of Defender for Cloud’s recommendations as well. Under the Azure Security Benchmark controls, Defender for Cloud includes the recommendation that “MFA should be enabled on accounts with owner permissions on your subscription.” Implementing this MFA control earns secure-score points because it mitigates high-impact identity risks.

Therefore, applying system updates (Yes), evaluating across multiple subscriptions (Yes), and enabling MFA (Yes) all increase or contribute to an organization’s secure score in Azure Security Center/Defender for Cloud.

When you register an application through the Azure portal, an application object and service principal are automatically created in your home directory or tenant.

In Microsoft Entra ID (formerly Azure AD), self-service password reset (SSPR) is the feature that explicitly supports email as an authentication method when users need to verify their identity to reset or unlock their password.

According to Microsoft’s identity and access documentation and the SCI learning content, SSPR lets administrators choose which verification methods are available to users, such as mobile phone, office phone, mobile app, security questions, and email. When email is enabled, a verification code can be sent to a registered alternate email address. The user proves their identity by entering this code, which is treated as an authentication step in the SSPR process.

By contrast:

Microsoft Entra Multi-Factor Authentication (MFA) does not support email as an MFA method; it focuses on methods like authenticator apps, phone calls, and text messages.

Microsoft Entra ID Protection detects and responds to risky sign-ins and users but does not provide email-based authentication.

Microsoft Entra Password Protection deals with banned and compromised passwords, not with email verification.

Therefore, the only option in the list that uses email as a supported authentication method is self-service password reset (SSPR).

In Microsoft identity and access management terminology, federation refers to the establishment of a trust relationship between identity providers, which enables single sign-on (SSO) across different organizations or platforms.

According to the Microsoft Security, Compliance, and Identity (SCI) learning path, particularly in the SC-900 and SC-300 certifications, the following definition is provided:

“Federation is a means of establishing trust between two identity systems. This trust allows users from one domain to access resources in another domain without needing to authenticate again, typically using SAML, WS-Federation, or OAuth protocols.”

This concept is essential in cross-organization SSO scenarios, such as enabling users from one enterprise (or identity provider) to authenticate with services hosted in another, using existing credentials.

SCI documentation further states:

“Single sign-on (SSO) between multiple identity providers is enabled through federation protocols, which delegate authentication and allow token-based identity propagation across systems.”

The other options are not accurate in this context:

Integration is a vague term and not specific to SSO configuration.

Password hash synchronization and pass-through authentication are Azure AD authentication methods used for hybrid identity with on-premises AD, not for federating with external identity providers.

✅ Therefore, SSO configured between multiple identity providers is best classified as an example of federation.

In Microsoft Purview (Microsoft 365 compliance), a retention policy applied to a SharePoint site keeps content for the specified period (e.g., 1 year) even if users delete it. Items are retained and recoverable until the retention period expires, meeting your preservation requirement.

Microsoft’s SCI learning content describes the Microsoft 365 Defender portal as a unified security operations experience that surfaces security posture and active threats on a card-based dashboard. In the overview of the portal, Microsoft explains that the home page “presents key security information in dashboard cards,” and that among these cards are summaries that highlight risky entities such as “Users at risk” and “Devices at risk.” These cards provide quick, actionable visibility for analysts by aggregating detections and exposure data across Microsoft Defender services (for identities and endpoints). The guidance emphasizes that the portal “correlates signals across identities, endpoints, email, and applications” and that security teams can use the dashboard cards to pivot directly into incidents and investigations from “Users at risk” or “Devices at risk” to take containment or remediation actions.

By contrast, Compliance Score is part of Microsoft Purview Compliance Manager, not the Microsoft 365 Defender portal; Service Health and User Management are functions of the Microsoft 365 admin center. Therefore, the cards you’ll find on the Microsoft 365 Defender portal that match the choices provided are Users at risk and Devices at risk.

Microsoft Azure Sentinel is a scalable, cloud-native, security information event management (SIEM) and security orchestration automated response (SOAR) solution.

Microsoft documents describe Microsoft Entra Privileged Identity Management (PIM) as the service that delivers approval-based, time-limited elevation to privileged roles. Official guidance states: “Privileged Identity Management (PIM) enables you to manage, control, and monitor access to important resources in Microsoft Entra ID, Azure, and Microsoft 365.” PIM specifically supports just-in-time and time-bound activations: “PIM provides just-in-time privileged access to Microsoft Entra roles and Azure resources” and “allows you to make access time-bound by setting start and end dates.” It also supports approval workflows: “You can require approval to activate privileged roles, and designate approvers to receive and approve requests.” Additional controls include “require multi-factor authentication to activate, provide a justification, and ticket number,” and auditing: “PIM records all activations and changes for review and alerting.”

By contrast, Microsoft Entra ID Protection focuses on risk detections and automated remediation, not role elevation workflows. Conditional Access enforces access policies at sign-in and session but does not provide approval-based role activation. Access Reviews help you “review and attest to continued access” but do not supply just-in-time elevation. Therefore, the Microsoft Purview/Entra feature that implements approval-based, time-bound role activation is Microsoft Entra Privileged Identity Management (PIM).

In Microsoft’s hybrid identity model, organizations keep their authoritative identities in Active Directory Domain Services (AD DS) and surface those identities in Microsoft Entra ID (Azure AD). Microsoft guidance explains that hybrid identity is implemented by synchronizing on-premises directory objects (users, groups, and selected attributes) into Azure AD using Azure AD Connect or Cloud Sync. Azure AD Connect is explicitly documented as the Microsoft tool that establishes and maintains synchronization between AD DS and Azure AD and is therefore used to implement hybrid identity—hence statement 1 is Yes. Hybrid identity does not require two Microsoft 365 tenants; the standard design is one Azure AD tenant connected to one or more on-premises AD forests, so statement 2 is No. For users to authenticate to Microsoft cloud resources with their on-premises identity, Azure AD must have a corresponding cloud identity object, which is achieved by directory synchronization; sign-in can then be handled by cloud authentication (Password Hash Synchronization or Pass-through Authentication) or by federation (e.g., AD FS). Because these sign-in options depend on synchronized identities being present in Azure AD, statement 3 is Yes. This aligns with SCI guidance that hybrid identity = synchronized identities + a chosen authentication method (PHS/PTA or federation).

In Microsoft Defender for Cloud, the metric that represents the overall security health of your Azure subscription is secure score. Microsoft’s documentation explains: “Secure score provides an aggregated view of your security posture across your subscriptions and resources. It’s based on security recommendations; addressing those recommendations improves your score.” Defender for Cloud calculates secure score by assessing controls and recommendations mapped to standards, then weighting them by risk and importance: “Each recommendation contributes to the secure score. Completing remediation steps increases the score and reduces risk.” This single percentage view lets security teams quickly gauge how well current configurations and protections align with Microsoft’s security best practices and regulatory mappings. Other elements surfaced in Defender for Cloud—like “resource health,” “status of recommendations,” or “completed controls”—are components and statuses that feed into or relate to the scoring model, but the overall subscription security health indicator presented and tracked over time is secure score.

Microsoft states that Azure Bastion is a fully managed PaaS service that provides “secure and seamless RDP/SSH connectivity to your virtual machines directly in the Azure portal over SSL” and “eliminates the need to expose public IP addresses on your VMs.” With Bastion, users open the VM blade in the Azure portal and launch an in-browser RDP or SSH session; no separate RDP or SSH client is required because the session is proxied through Bastion using HTTPS/TLS. The platform is designed to be agentless and browser-based, providing connectivity without VPN or jump hosts and enforcing least-exposure by keeping management ports off the internet. While traditional tools such as Remote Desktop Connection or an SSH client are common for direct access, Bastion’s prescribed access method in Microsoft guidance is to initiate the session from the Azure portal. PowerShell remoting is unrelated to Bastion’s web-based brokering. Therefore, to connect to an Azure virtual machine by using Azure Bastion, you use the Azure portal.

Microsoft 365 Insider Risk Management follows a clear operational flow: Triage → Investigate → Action. Microsoft’s guidance explains that the Alerts dashboard is used first to review and filter alerts, prioritize by severity, and decide what needs deeper review—this is the Triage stage. The documentation describes triage activities as reviewing alert details, applying filters, and determining whether an alert should be escalated for investigation.

When an alert warrants deeper inquiry, analysts move to Investigate, where they create cases, add relevant alerts and users, and examine activity timelines and related signals. Microsoft states that cases are the vehicle for structured investigations, allowing analysts to group evidence and manage workflow from the Case dashboard.

After investigation, organizations proceed to Action, where insider risk controls allow response steps such as sending user policy reminders, escalating to HR or legal, or taking other governance actions. Microsoft describes that actions can include notifying the user with a policy reminder to reduce future risk or applying stronger controls, all of which are part of the response phase.

Accordingly, the correct matches are: Triage → Review and filter alerts, Investigate → Create cases in the Case dashboard, and Action → Send a reminder of corporate policies to users.

Microsoft Entra self-service password reset (SSPR) supports multiple verification methods that users can register and use to prove their identity during a reset. Microsoft’s documentation lists the SSPR methods as: “Mobile app notification,” “Mobile app code,” “Email,” “Mobile phone (text message or call),” “Office phone,” and “Security questions.” Administrators choose which of these are allowed and how many methods are required. During the reset flow, SSPR “prompts the user to verify with the registered methods” before permitting a password change. Notably, certificates and picture passwords are not SSPR verification methods in Microsoft Entra ID. Therefore, among the options provided: a text message to a phone (mobile phone), a mobile app notification (Microsoft Authenticator), and security questions are valid SSPR authentication methods; certificate and picture password are not supported for SSPR. This aligns with SCI learning content that positions SSPR as a user-empowering capability to securely restore access using admin-approved methods without help-desk intervention.

Microsoft Purview Data Loss Prevention (DLP) is designed to “detect and protect sensitive items” across Microsoft 365 locations, endpoints, and cloud apps. Microsoft explains that Purview DLP policies use sensitive information types, exact data match (EDM), and machine learning–based trainable classifiers to identify content, and then automatically apply protective actions such as blocking or restricting sharing, notifying users with policy tips, auditing, or auto-quarantining/justifying activities. This fulfills the description “use machine learning algorithms to detect and automatically protect sensitive items.” While eDiscovery focuses on legal hold and content discovery, and Communication compliance monitors communications for policy violations (ethics/regulatory scenarios), they are not positioned to broadly and automatically protect sensitive data across services. “Information risks” is not a distinct Purview solution category. Therefore, the Purview capability that leverages machine learning classifiers and automatically enforces protections on sensitive data is Data loss prevention (DLP).

https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-configure

Privileged Identity Management provides time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions on resources that you care about. Here are some of the key features of Privileged Identity Management: Provide just-in-time privileged access to Azure AD and Azure resources Assign time-bound access to resources using start and end dates Require approval to activate privileged roles Enforce multi-factor authentication to activate any role Use justification to understand why users activate Get notifications when privileged roles are activated Conduct access reviews to ensure users still need roles Download audit history for internal or external audit Prevents removal of the last active Global Administrator role assignment

Azure Firewall is a managed, cloud-based network security service designed to secure traffic inside and across Azure Virtual Networks. Microsoft describes Azure Firewall as a stateful firewall that “protects Azure Virtual Network resources” by enforcing network and application rules, central logging, and threat intelligence–based filtering. Because it is deployed into a VNet/subnet (often as the hub in a hub-and-spoke), it directly governs East/West and North/South flows to workloads such as Azure virtual machines and platform services reachable through the VNet, using DNAT/SNAT and rule collections. Microsoft guidance highlights capabilities to “centrally create, enforce, and log application and network connectivity policies across subscriptions and virtual networks,” and to filter traffic for peered VNets, branch connections (VPN/ExpressRoute), and internet traffic. These capabilities explicitly map to protecting Azure virtual networks and the VMs and subnets inside them. In contrast, Azure AD users, Exchange Online inboxes, and SharePoint Online sites are SaaS/identity resources protected by Microsoft Entra controls, Exchange/SharePoint security, and Purview/Defender for Office 365—not by a VNet firewall. Therefore, the Azure Firewall–protectable resource types among the options are Azure virtual machines and Azure virtual networks.

Microsoft’s shared responsibility guidance explains that the customer’s responsibility decreases as you move from on-premises to SaaS. In an on-premises datacenter, “you own the whole stack—applications, data, runtime, middleware, OS, virtualization, servers, storage, and networking.” With IaaS, the cloud provider operates the physical datacenter and virtualization, while “you’re responsible for configuring and managing the guest OS, network controls, identity, applications, and data.” With PaaS, the provider operates more of the stack so that “the cloud provider manages the platform (OS, middleware, and runtime) and you focus on your applications and data.” Finally, with SaaS, responsibility is minimized for customers because “the service provider manages the application and underlying infrastructure; customers primarily manage identity, data, and access/usage.”

These Microsoft Learn statements map directly to the requested order—from most customer responsibility (on-premises) to least (SaaS)—with IaaS and PaaS in between, reflecting the progressive shift of operational and security controls from the customer to the cloud provider as the service model moves up the stack.

Microsoft Defender for Office 365 is the Microsoft 365 solution designed to protect users from threats delivered through email and collaboration workloads. SCI training material explains that Defender for Office 365 protects Exchange Online, Microsoft Teams, SharePoint Online, and OneDrive for Business by detecting and blocking malware, phishing, and other advanced attacks that use messages and shared content as the delivery channel.

A key capability is Safe Links, which specifically protects against malicious URLs. When a user receives an email, Teams chat message, or channel post that contains a hyperlink, Safe Links scans and rewrites that URL. At the moment the user clicks, the link is checked again; if it is identified as malicious or leads to a known phishing or malware-hosting site, access is blocked and a warning page is shown. This time-of-click protection is emphasized in Microsoft’s security documentation as a primary defense against weaponized links in email and collaborative communications.

By comparison, Microsoft Defender for Identity focuses on detecting identity-related threats in on-premises Active Directory, Defender for Endpoint protects devices and endpoints, and Defender for Cloud Apps secures SaaS applications and shadow IT. None of these are the primary solution for blocking malicious links in email, chats, and channels. Therefore, the correct choice is Microsoft Defender for Office 365.

In Azure networking, each Network Security Group (NSG) is created with a built-in set of default security rules. Microsoft’s documentation for NSGs explains: “Azure creates several default security rules within each network security group. You can’t remove the default security rules, but you can override them by creating rules with a higher priority.” The rule processing model is priority-based: “Security rules are processed in priority order, with lower numbers processed before higher numbers. Once a rule matches traffic, processing stops.” Because the defaults have relatively low precedence (high priority numbers), an administrator can create an explicit allow or deny rule with a lower priority number to supersede the default behavior.

This is why the correct completion is override rather than copy or delete. You cannot delete the default rules; they remain present to provide baseline behavior (such as denying inbound traffic from the internet by default and allowing virtual network traffic). Instead, you override the defaults by adding your own NSG rules—using lower priority numbers—to achieve the desired access control outcome while preserving Azure’s baseline protections and evaluation logic.

Microsoft 365 Endpoint Data Loss Prevention (Endpoint DLP) extends DLP controls to endpoints. Microsoft documentation describes Endpoint DLP as applying protections on “Windows 10/11 devices” (and, in current guidance, also macOS). The feature monitors and restricts actions like copying to USB, printing, or uploading to the web when sensitive items are involved. Importantly, Microsoft does not document Endpoint DLP support for iOS or Android; those platforms are governed through app protection policies in Intune and Microsoft Defender for Endpoint mobile capabilities, not Endpoint DLP. Given the answer choices provided, the only correct option that aligns with Microsoft’s Endpoint DLP platform support and excludes unsupported mobile OSs is Windows 10 only (noting that Microsoft also supports Windows 11 and macOS today, which are absent from the choices). Therefore, among the listed options, Windows 10 only is the correct selection because Endpoint DLP does not run on iOS or Android.

Box 1: Yes

The MailItemsAccessed event is a mailbox auditing action and is triggered when mail data is accessed by mail protocols and mail clients.

Box 2: No

Basic Audit retains audit records for 90 days.

Advanced Audit retains all Exchange, SharePoint, and Azure Active Directory audit records for one year. This is accomplished by a default audit log retention policy that retains any audit record that contains the value of Exchange, SharePoint, or AzureActiveDirectory for the Workload property (which indicates the service in which the activity occurred) for one year.

Box 3: yes

Advanced Audit in Microsoft 365 provides high-bandwidth access to the Office 365 Management Activity API.

multi-factor authentication (MFA)

In Microsoft Entra ID (formerly Azure AD), Security defaults are a baseline of recommended identity protections that, when turned on, automatically apply tenant-wide. Microsoft’s guidance explains that security defaults “help protect your organization with preconfigured security settings” and specifically require that “all users register for Azure AD Multi-Factor Authentication.” When enabled, the defaults enforce MFA challenges for users and admins during risky or sensitive operations, and they block legacy authentication protocols that can’t satisfy modern MFA requirements. Microsoft further notes that security defaults “provide basic identity security mechanisms… such as requiring multi-factor authentication for all users and administrators.” These controls are designed to raise the overall security posture without custom policy design, which is ideal for small and medium organizations or any tenant that hasn’t yet implemented Conditional Access. Therefore, when you enable security defaults, MFA is enabled for all Azure AD users, driving strong authentication as the default and reducing account-takeover risk stemming from password-only sign-ins.

In Microsoft 365 Defender, security signals from across Microsoft 365 services are raised as alerts. Microsoft’s documentation defines an incident as “a collection of correlated alerts” that represent the end-to-end story of an attack. The incident object aggregates the related signals, entities, and evidence so analysts can triage and remediate holistically rather than handling individual alerts in isolation. Microsoft further explains that incidents “group together related alerts, assets, users, and evidence” to reduce noise and provide context for investigation, and that automated correlation “helps SOCs focus on what matters most” by stitching alerts from Defender for Endpoint, Defender for Office 365, Defender for Identity, and Microsoft Defender for Cloud Apps into one case. Within an incident, analysts see a timeline, impacted assets and users, alert details, and recommended actions, and they can trigger response measures (for example, isolate device, block URL/file, or disable user). This contrasts with events (raw telemetry), vulnerabilities (exposure findings managed by Defender Vulnerability Management), and Microsoft Secure Score improvement actions (posture recommendations). Therefore, in the Microsoft 365 Defender portal, an incident is specifically a collection of correlated alerts, designed to streamline investigation and coordinated remediation across the Microsoft 365 security stack.

Microsoft’s Conditional Access (part of Microsoft Entra ID) evaluates multiple signals to make access decisions. The official description lists typical signals such as “user or group membership, IP location information, device state, application, and real-time risk.” The device state element explicitly refers to conditions like “compliant or hybrid Azure AD joined devices,” allowing policies that grant or block access—or require extra controls—based on whether a device meets compliance/registration requirements.

Regarding evaluation timing, Microsoft’s guidance states that Conditional Access “policies are enforced after the first-factor authentication is completed.” This means the engine needs the user’s primary sign-in context (who the user is and how they authenticated) to evaluate the conditions and then decide whether to allow, block, or require additional controls. Therefore, the statement that policies apply before first factor is not correct.

Finally, Conditional Access includes grant controls such as “Require multi-factor authentication,” and policies can be scoped to specific cloud apps or actions. As a result, you can target a particular application and require MFA when a user attempts to access it, satisfying application-specific risk mitigation while preserving user productivity.

In Microsoft’s Security, Compliance, and Identity guidance, the Microsoft Service Trust Portal (STP) is identified as the public destination where Microsoft publishes independent audit reports, compliance certifications, assessment reports, and trust-related documentation for Microsoft cloud services. The documentation explains that the STP provides customers with access to materials such as SOC 1/SOC 2 reports, ISO/IEC certifications, audit summaries, and compliance guides, enabling organizations to evaluate Microsoft’s controls and map them to their own regulatory requirements. The STP is expressly positioned for transparency and due diligence, allowing customers and auditors to review Microsoft’s compliance posture and understand how Microsoft manages security, privacy, and compliance across its cloud platforms.

By contrast, the Microsoft Purview compliance portal is a tenant-admin portal used to configure and manage compliance solutions (e.g., DLP, Information Protection, eDiscovery, Insider Risk, Compliance Manager) within your organization—not a public repository of Microsoft’s audit artifacts. The Microsoft Purview governance portal focuses on data governance and cataloging scenarios. The Azure EA portal is used for Enterprise Agreement billing and usage management. Therefore, the public site for publishing audit reports and other compliance-related information for Microsoft cloud services is the Microsoft Service Trust Portal.

Assessments

In Microsoft Purview Compliance Manager, assessments are the core components used to track compliance with groupings of controls from specific regulations, standards, or requirements.

According to official Microsoft Security, Compliance, and Identity (SCI) learning content, particularly within the SC-400 and SC-900 certification tracks, the role of assessments is explicitly defined as:

“Assessments in Compliance Manager help you track, implement, and improve compliance with requirements from standards and regulations. Each assessment maps to a specific regulation or control framework, such as ISO 27001, NIST, GDPR, or HIPAA, and includes a set of controls and recommended improvement actions.”

Further extracted content from SCI documentation confirms:

“An assessment is used to measure your compliance posture against a particular regulation or standard. It includes control mappings and provides insight into what’s in place and what still needs to be addressed to meet the compliance goals.”

The other options in the dropdown — Templates, Improvement actions, and Solutions — serve different functions:

Templates provide a blueprint for creating assessments.

Improvement actions are actionable steps generated within assessments.

Solutions in Microsoft Purview refer to bundled capabilities like Insider Risk Management, Information Protection, etc.

Therefore, to track compliance with groupings of controls from a specific regulation or requirement, the correct and Microsoft-verified term is "Assessments."

Microsoft’s hybrid identity guidance explains that Microsoft Entra Connect (formerly Azure AD Connect) is the tool used to synchronize identities from on-premises AD DS to a Microsoft Entra tenant, enabling hybrid identity. Microsoft states that hybrid identity is achieved by connecting your on-premises directory with your cloud directory so users have a single identity to access both environments. This does not require two Microsoft 365 tenants; rather, it requires one Microsoft Entra tenant integrated with your on-premises AD DS. For authentication models—Password Hash Synchronization (PHS), Pass-through Authentication (PTA), or federation (AD FS)—Microsoft specifies that directory synchronization is required so that user objects exist in Entra ID and can authenticate to cloud services while maintaining a consistent identity. Thus, Entra Connect is used to implement the synchronization underpinning hybrid identity; two M365 tenants are unnecessary; and synchronization between AD DS and Entra ID is required for authenticating hybrid identities across Microsoft cloud services.

Microsoft’s shared-responsibility model states that the cloud provider secures the cloud, while the customer secures what they put in the cloud. The Azure Security documentation explains: “Regardless of the type of deployment, you always retain responsibility for your data, endpoints, accounts, and access management.” This applies to IaaS, PaaS, and SaaS, so statement 3 is Yes because the organization is always accountable for the security of information and data.

For SaaS, Microsoft describes that customers “don’t manage or control the underlying cloud infrastructure—including network, servers, operating systems, or even individual application capabilities” and that the provider handles service maintenance and updates. In SaaS, tasks like patching or applying service packs to the application code are owned by the service provider, while the customer focuses on data, identity, and access. Therefore, statement 1 is No.

For IaaS, Microsoft notes the provider manages the physical estate: “Microsoft is responsible for the physical hosts, network, and datacenter facilities,” while the customer configures and secures the guest OS, applications, and network controls within their subscription. Thus, managing the physical network is the cloud provider’s duty, making statement 2 Yes.

These SCI principles are foundational to Microsoft Learn/Docs guidance on Azure’s shared responsibility: provider—“security OF the cloud”; customer—“security IN the cloud,” with data protection always remaining the customer’s responsibility.

Microsoft Entra Conditional Access evaluates signals to make real-time access decisions. Microsoft describes it as bringing “signals together to make decisions and enforce organizational policies,” where administrators choose controls such as Block access, Require multi-factor authentication, Require device to be marked as compliant, or Require hybrid Azure AD joined device. Because MFA is only one of several grant controls, it is incorrect that policies always enforce MFA; they can also simply block, allow, or require other conditions.

Location is a first-class condition. Microsoft states you can define named locations (by countries/regions or IP ranges) and then use them in policy conditions to block or grant access. A common scenario is “Block access from specific locations” or require additional controls when a sign-in originates from an untrusted network. Therefore, Conditional Access can block access to an application based on user location.

Finally, Conditional Access targets users, groups, workload identities, and cloud apps regardless of device join state. Device-related conditions and filters are optional; policies are not limited to “Azure AD-joined devices.” Controls like Require device to be marked as compliant or Require Hybrid Azure AD joined device are only enforced if configured. Hence, Conditional Access does not only affect users on Azure AD-joined devices.

Microsoft describes Identity Protection as a capability that “detects risky users and risky sign-ins using real-time and offline detections and allows you to configure automated responses.” Microsoft is explicit that detections aren’t limited to after authentication; rather, signals are evaluated during sign-in and also by offline analytics, where “some detections are offline and can take up to 48 hours to appear.” Therefore, saying it only “generates risk detections once a user is authenticated” is incorrect.

For risk scoring, Microsoft states that Identity Protection “assigns a risk level to each detection,” and that “risk levels are Low, Medium, or High,” which are then used by user-risk and sign-in-risk policies to drive remediation (for example, requiring password change or MFA).

Microsoft also defines the two core risk concepts: “User risk represents the probability that a given identity or account is compromised,” while “Sign-in risk represents the probability that a given authentication request isn’t authorized by the identity owner.” These definitions underpin Conditional Access and Identity Protection policies that can require additional verification or block access based on the assessed risk.

Taken together, the documentation confirms: detections are not restricted to post-authentication (No), detections carry Low/Medium/High levels (Yes), and user risk is the probability the identity is compromised (Yes).

In Microsoft Purview, eDiscovery (Standard) (formerly Core eDiscovery) provides case management, holds, searches, and export. Microsoft describes that eDiscovery (Standard) lets investigators “search across Microsoft 365 data sources and export the results,” including options to export native files, email to PST, and CSV reports for further review. It uses the same Content search engine and supports selecting locations such as **Exchange Online mailboxes, Microsoft 365 Groups, Teams, SharePoint sites, OneDrive accounts, and Exchange public folders,” enabling organization-wide discovery that includes public folders.

Integration for end-to-end legal review from Microsoft Purview Insider Risk Management is specifically aligned to eDiscovery (Premium) (formerly Advanced eDiscovery). Insider Risk cases provide actions like “Send to eDiscovery (Premium)” to create a review set and apply advanced processing, analytics, and review workflows. Those advanced integrations (review sets, analytics, legal hold communications) are not features of eDiscovery (Standard). Therefore: exporting results (Yes), Insider Risk integration (No, as it targets eDiscovery Premium), and searching Exchange Online public folders (Yes) are the correct evaluations based on the Microsoft Security, Compliance, and Identity study materials for Purview eDiscovery capabilities.

Microsoft Defender for Endpoint includes Automated investigation and remediation (AIR) and Attack surface reduction (ASR) as core capabilities. Microsoft’s guidance states that AIR “uses inspection algorithms and playbooks to examine alerts, determine if they are malicious, and then take remediation actions such as stopping processes, quarantining files, and rolling back changes.” It is designed to “reduce the volume of alerts that require analyst attention and to remediate threats at machine speed across your estate,” helping security teams contain and fix issues without manual intervention.

Defender for Endpoint also provides attack surface reduction features to proactively limit exposure. The Microsoft learn materials describe that ASR “helps organizations minimize areas that attackers can exploit,” and includes “attack surface reduction rules, network protection, web protection, application control (Windows Defender Application Control), and controlled folder access.” These controls “block or constrain risky behaviors and common attacker techniques,” thereby preventing many initial compromise and lateral-movement attempts before they generate incidents.

By contrast, transport encryption is a general platform/security baseline capability rather than a specific Defender for Endpoint feature, and shadow IT detection is addressed through Microsoft Defender for Cloud Apps (App discovery), which can use Defender for Endpoint network signals but is not itself a native MDE capability. Therefore, the two correct capabilities of Microsoft Defender for Endpoint are Automated investigation and remediation and Attack surface reduction.

Microsoft Secure Score for Devices

Artikel

12.05.2022

3 Minuten Lesedauer

Applies to:

Microsoft Defender for Endpoint Plan 2

Microsoft Defender Vulnerability Management

Microsoft 365 Defender

Some information relates to pre-released product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.

To sign up for the Defender Vulnerability Management public preview or if you have any questions, contact us (mdvmtrial@microsoft.com).

Already have Microsoft Defender for Endpoint P2? Sign up for a free trial of the Defender Vulnerability Management Add-on.

Configuration score is now part of vulnerability management as Microsoft Secure Score for Devices.

Your score for devices is visible in the Defender Vulnerability Management dashboard of the Microsoft 365 Defender portal. A higher Microsoft Secure Score for Devices means your endpoints are more resilient from cybersecurity threat attacks. It reflects the collective security configuration state of your devices across the following categories:

Application

Operating system

Network

Accounts

Security controls

Select a category to go to the Security recommendations page and view the relevant recommendations.

Turn on the Microsoft Secure Score connector

Forward Microsoft Defender for Endpoint signals, giving Microsoft Secure Score visibility into the device security posture. Forwarded data is stored and processed in the same location as your Microsoft Secure Score data.

Changes might take up to a few hours to reflect in the dashboard.

In the navigation pane, go to Settings > Endpoints > General > Advanced features

Scroll down to Microsoft Secure Score and toggle the setting to On.

Select Save preferences.

How it works

Microsoft Secure Score for Devices currently supports configurations set via Group Policy. Due to the current partial Intune support, configurations which might have been set through Intune might show up as misconfigured. Contact your IT Administrator to verify the actual configuration status in case your organization is using Intune for secure configuration management.

The data in the Microsoft Secure Score for Devices card is the product of meticulous and ongoing vulnerability discovery process. It is aggregated with configuration discovery assessments that continuously:

Compare collected configurations to the collected benchmarks to discover misconfigured assets

Map configurations to vulnerabilities that can be remediated or partially remediated (risk reduction)

Collect and maintain best practice configuration benchmarks (vendors, security feeds, internal research teams)

Collect and monitor changes of security control configuration state from all assets