rss.livelink.threads-in-node

Why identity is the Copilot unlock

AuzinAhmadi — Thu, 23 Jul 2026 19:58:11 GMT

This is Part 2 of a three-part series. Part 1 mapped the people who decide whether your AI program ships. This one is for the Microsoft 365 admins and CIOs whose Copilot is paid for but not “on.” Part 3 will cover agent governance.

“We bought Copilot. Why can’t we turn it on?”
Maybe you’ve said this yourself. You have the licenses. You’re ready to assign them. Months later, Copilot still isn’t in front of a single clinician. The budget cleared. Leadership is asking for the productivity story they were promised, but the deployment is stuck.

The answer is not a license problem or a Copilot problem, but an identity problem. The identity foundation underneath isn’t ready. In healthcare, that foundation is harder to move than anywhere else I’ve worked. Get it right and two things turn on: a Copilot the clinician trusts at the bedside and the control plane for every agent that comes after.

Why identity is the gate, not a checkbox

Microsoft 365 Copilot authenticates users through Microsoft Entra ID. Every Copilot interaction honors the permissions of the signed-in user through Microsoft Graph, so the question “What can this person see?” is answered by your identity layer, not by Copilot. One of the great things about Copilot is it has access to everything you have access to — this is also one of the concerning things about Copilot.

Two different controls play a role here. Identity decides who is at the door and how far you trust the sign-in. Data governance decides what they can reach once inside. Copilot leans on both, and Entra is the first of the two. It is the one that decides whether you can safely turn Copilot on at all. That is why a responsible admin won’t flip Copilot on until the identity foundation holds. They need multifactor authentication everywhere, Conditional Access that actually evaluates risk, and a least-privilege model they trust. All three live in Entra.

Plenty of the health systems I work with authenticate through 3rd-party identity providers. Microsoft 365 still sits on Entra underneath, the directory it’s built on, but the front door is brokered elsewhere. When the primary authentication layer is 3rd-party, Entra still authorizes Microsoft 365 access.

What changes is the signal Entra gets to see:

MFA may be satisfied by a federated claim from elsewhere rather than evaluated by Entra.
Sign-in risk telemetry gets thinner on the Entra side, because Entra never sees the credential go in. The 3rd-party identity provider is evaluating risk at its own front door, but those signals do not become Entra risk that Conditional Access and Entra ID Protection can act on. Some detections still fire offline. Atypical travel is one example, though the IP Entra logs can be a 3rd-party egress rather than the clinician’s. Leaked-credential detection still works, but it is the one Entra ID Protection signal that depends on password hash sync.
Device-compliance signals reach Conditional Access only if your devices are registered in Entra. Federated, non-Entra-joined devices also never get an Entra device-bound Primary Refresh Token, so token protection stays dark.

Risk-based Conditional Access and Entra ID Protection then miss the full picture. You are running the front door of your AI program on one system and governing Copilot’s data access on another. That gap is the gate.

Two ways to close the gap, on two different timetables

The “fast” option keeps the 3rd-party identity provider but moves the Microsoft 365 sign-in to Entra. You defederate the Microsoft 365 domain to managed authentication and register the 3rd party as an external authentication method for MFA. Entra now runs primary sign-in and Conditional Access, so it evaluates device state and risk directly, while the 3rd party still handles the MFA challenge and remains the portal your users know for everything else. You are not ripping out other MFA providers. You are moving one domain’s sign-in to Entra so the signals reach it.

This is the correct path when leadership wants the Copilot productivity story this quarter and a full identity migration is a multi-year mountain you cannot climb first. External authentication methods are generally available as the supported successor to Custom Controls (requiring Entra ID P1). Custom Controls is on a deprecation path, with new configuration blocked and full retirement staged across 2026 into 2027, so confirm the current dates in Microsoft’s documentation before you plan around them.

The “strategic” option consolidates identity on Entra outright. It is the harder path but the one that closes the gap completely. Full consolidation is also what lights up device-bound token protection everywhere, because federated, non-Entra-joined devices never get an Entra Primary Refresh Token. Consolidate when 3rd-party identity providers are mostly doing single sign-on. Keep them as the identity provider for other apps when they are load-bearing across the estate and pulling them out buys you a second migration you don't need.

Either way, the signals must reach Entra before Copilot goes on. If you take the fast path, that managed cutover still runs through the readiness gate and the downtime discipline below. You just skip the full-consolidation mechanics. And if any Microsoft 365 sign-in stays truly federated to a 3rd party, treat it as interim: the thinner Entra telemetry and the absent token protection above stay in force until you close them, so pair it with compensating controls.

Healthcare’s identity constraints are not like other industries

In a normal enterprise, an identity migration is a weekend of change windows and a week of help-desk tickets. In a hospital, the same project touches patient safety. Four constraints make it different:

Electronic health record (EHR) single sign-on dependencies. The EHR is the center of gravity. It integrates with your identity provider, often through a tap-and-go layer, so a clinician can badge into a shared workstation in a second or two. Change the identity provider and you may change badge tap, workstation sign-in, EHR launch, e-prescribing, medication administration, and chart access. You cannot do that blindly.
Round-the-clock, 24/7 care-continuity. There is no maintenance window. The health system runs every hour of every day. An identity change that would be a minor outage at a bank is, in an emergency department, a clinician who cannot open a chart during a trauma intake. The tolerance for downtime is not low. It is zero for anything on the critical path.
Clinician friction tolerance. Clinicians will accept a badge tap and a biometric. They will not accept a multi-step login at the bedside. Add ten seconds to a workflow they run eighty times a shift and they will route around it. Now your security control is theater. This is where the stakeholders from Part 1 hold their veto as the clinical leaders who own care-continuity risk.
The regulatory audit trail. HIPAA expects access controls and a record of who reached protected health records and when. Whatever you build has to keep that trail intact through the migration, not reconstruct it afterward.

None of these are reasons to stay on a fragmented identity model. They are the reasons to migrate carefully rather than quickly.

The Electronic Health Record (EHR) coordination problem

Of the four constraints, EHR integration is the one most likely to stall your migration. The single most common mistake I see is treating it as a pure IT project and looping in the EHR vendor late. The EHR is not a bystander here. It authenticates against your identity provider. The vendor has a say in how that integration changes.

I watched one system set a hard cutover date before it talked to its EHR vendor. Three weeks out, it learned the tap-and-go integration had to be re-certified against the new identity provider. The date slipped by a month, and the fix was not technical. It was a conversation that should have happened at the start.

Coordination effort varies by platform. Use this table to start the vendor conversation. Do not use it to set a cutover date.

EHR platform	Entra integration path	Coordination load	Watch for
Epic	Federation to Entra supported; SAML / OIDC, SMART on FHIR for app-to-EHR authorization	Moderate	Hyperdrive SSO behavior; SMART on FHIR app registrations; Imprivata or tap-and-go path; test real clinical workstation flows in non-prod
Oracle Health (Cerner)	SSO via SAML; tap-and-go middleware (Imprivata) common	Moderate to high	Middleware re-point is its own workstream; validate proximity-badge flows
Meditech	Vendor-assisted SSO; middleware common	Higher	Plan added lead time for vendor coordination; confirm supported Entra patterns early

The pattern across all three: the identity team cannot set the cutover date alone. The EHR vendor and the tap-and-go middleware owner are on the critical path with you. Bring them in while the plan is still a draft, not when you have a date to defend.

The readiness gate: don’t start until these are true

If the left column is true, do not put Copilot in front of clinicians until the right column is done. Hand this to your identity and access lead and ask for your system’s version. It turns “Are we ready?” into a list someone owns.

If this is true	Do not enable Copilot for clinical users until
3rd-party identity provider enforces MFA but Entra risk policies are not active	You have an Entra-led Conditional Access plan or a documented compensating control
EHR SSO depends on tap-and-go middleware	The EHR vendor and the middleware owner have tested the flow in non-prod
Shared clinical workstations are in scope	Badge tap, biometric, EHR launch, and chart access are validated by role
Rollback needs daytime engineering support	The wave is not approved
Overshared or unlabeled sensitive sites remain	The Copilot pilot scope is constrained to clean data

The phased migration playbook

You do not migrate a hospital’s identity in one cutover. You move in stages, prove each one, and keep a way back at every step. Once those readiness gates are owned, the work becomes a migration sequence. The first five steps are identity work. The sixth is where identity readiness becomes Copilot readiness. These steps hold up across most migrations to Entra I have seen:

Pilot a low-risk department. Pick a non-clinical or low-acuity group first — finance or a back-office function, not the ED. Prove the end-to-end flow where a failure is an inconvenience, not a safety event.
Coordinate with the EHR vendor before you touch clinical users. Validate the EHR SSO and the tap-and-go path in a test environment with the vendor in the room. This is the step teams skip and regret.
Cut over in waves, by care setting. Move ambulatory before inpatient and scheduled before emergent, though infusion and urgent care are ambulatory in name only. Sequence by real acuity, not by building. In practice, the first clinical wave is a low-acuity outpatient clinic of twenty or thirty providers, then med-surg, then the ED and ICU last. Each wave is small enough to roll back inside one shift.
Validate against the real workflow, not a checklist. Confirm badge tap, biometric, EHR launch, and chart access for an actual clinician on an actual workstation. A green status page is not validation. A nurse opening a chart is.
Enforce Conditional Access in report-only first. With identity consolidated on Entra, model MFA, device compliance, session controls, and risk-based access before you block anyone. Then enforce by wave once clinical workflows pass. This is the moment the security posture improves.
Turn on the Purview controls Copilot will lean on. Start with sensitivity labels, audit, and an oversharing review, then add Data Loss Prevention. The Microsoft 365 Copilot location in Purview DLP is generally available for sensitivity-label-based blocking. Newer controls, like SIT-based prompt blocking, web-search restrictions, and DLP for Copilot Studio agents, are still rolling out or in preview depending on your tenant, so confirm what you have before the rollout depends on them.

Downtime is a patient-safety issue, not an IT metric

The framing that changes how this project gets run: in a hospital, identity downtime is a clinical event. Treat it that way and the rest of the plan falls into place. A useful test for every mitigation is what I call the 2 a.m. trauma intake. Not “does this pass in a maintenance window,” but “does this hold when a trauma comes through the door at two in the morning and a clinician has to open a chart right now.” If your rollback story only works during business hours with the full team online, it is not a rollback story.

Run the project on the safest assumption: something will go wrong at the worst possible time. Plan for that time. A cutover safety check before any wave goes live:

Failover path tested, not assumed. Know exactly what happens to authentication if the new path fails. Prove it in test.
Rollback measured in minutes, not hours. If you cannot reverse a wave in about fifteen minutes, it is not ready to cut over during a shift when someone is mid-chart. Every wave needs a named owner who can make the call.
Downtime procedures clinicians already know. The EHR’s read-only or downtime mode is part of the plan. The floor has practiced it.
Validated at the worst hour, not the easy one. Sign-off includes an off-hours, high-acuity test, because that is when it will actually matter.
Help desk and clinical informatics briefed per wave. The people who answer the 2 a.m. call know a migration wave is live and what to do.

What identity unlocks (and the bridge to agents)

Here is what turns on: a clinician badges in once and Copilot is right there, scoped to exactly what that person is cleared to see, safe to use in front of a patient. That is the payoff. The control plane underneath is what makes it safe to leave on.

With Entra as the foundation, the liability ownership and the access controls the CISO need are finally yours to run. Identity secures the perimeter. Most of what follows is the data-governance work it is now safe to start. Here is what to enable after the migration and where each control lives.

Post-migration control	What it unlocks for Copilot and agents	Where it lives	Healthcare watch-out
Conditional Access, Copilot-scoped	Real-time access decisions on user risk, device health, and location	Microsoft Entra	Start report-only; enforce by care-setting wave
Sensitivity labels	Label-aware responses; protected content stays protected	Microsoft Purview	Label ePHI and research data before broad enablement
Oversharing review	Stops Copilot surfacing overshared sites and files	Purview / SharePoint	Run clinical and research SharePoint first
Audit	Full trail of Copilot activity for Legal and the CISO	Microsoft Purview	Keep the HIPAA ePHI access trail intact through cutover
DLP for Microsoft 365 Copilot	Restricts sensitive content from Copilot grounding and prompts	Microsoft Purview	Confirm which controls are GA in your tenant

Every agent you build acts as an identity or on behalf of it. You cannot govern what an agent can reach if you cannot govern who the agent is. After this migration, you can.

Identity is the gate. It is also the most underestimated project in a healthcare AI program, because it looks like plumbing and behaves like patient safety. Get the identity foundation right and Copilot can turn on without the security story degrading. Data hygiene, oversharing, and clinical adoption still matter, but the gate is open. You are ready for the harder question: not whether you can deploy an agent, but which agents should exist, whose identity they run under, what they can reach, and who can shut them off.

Part 3, “Agent Governance Is Organizational Readiness,” closes the series. Governance is not the brake on agents. It is what allows you to say yes to them.

Product names, availability, and timelines reflect Microsoft guidance at the time of writing and can change. Verify current state against official Microsoft documentation for your tenant.

Charles Wallace is a Senior FastTrack Architect at Microsoft. He works on Microsoft 365 Copilot and agent adoption across healthcare and life sciences. His focus is the security, identity, and governance foundations that decide whether AI deployments actually succeed.

Who actually blocks AI in healthcare (and why)

AuzinAhmadi — Tue, 28 Jul 2026 17:31:17 GMT

Co-authored by
Charles_Wallace

This is Part 1 of a three-part series on the organizational readiness work between a Copilot proof-of-concept and AI at scale. Part 2 covers why identity is the technical gate that decides whether Copilot turns on. Part 3 finishes with agent governance as organizational readiness.

Who this is for: IT leaders, M365 admins, and project sponsors who keep losing AI pilots in committee.

I've watched a lot of Microsoft 365 Copilot pilots succeed technically and die anyway.

The deployment worked. Licenses were assigned, Conditional Access held, the data didn't leak. Early users loved it. The ambient documentation pilot was reportedly saving clinicians the better part of twenty minutes a visit. Then it sat in a steering-committee queue for two quarters and the funding lapsed.

That pilot didn't fail on technology. It failed on people. In healthcare, that's the failure mode nobody puts on the project plan.

If you've deployed AI in other industries, you know change management is hard everywhere. Healthcare is a different kind of hard. Not because the people are more resistant—it's that the structure of who can stop you looks nothing like other industries. This post maps the people who decide whether your AI program ships, what they actually worry about versus what they say, and the order to engage them in.

Why healthcare's stakeholder map is different

In most enterprises, an executive sponsor with budget can clear the path. A VP says: "We're doing this," and the organization moves.

Healthcare doesn't work that way and the reasons are structural. Physicians aren't employees in the ordinary sense. In teaching hospitals, they're often represented by a residents' association or a faculty practice plan. In community systems, admitting privileges give independent physicians real leverage. They can decline to change a workflow and clinical leadership will usually back them.

On top of that professional autonomy, several European countries, most notably Germany, give works councils legally protected co-determination over technical systems that can monitor staff behavior or performance. How broadly that gets read varies by jurisdiction. Anything that touches care delivery draws scrutiny from patient and family advisory councils and ethics committees. Under all of it runs one constant question: if this goes wrong, who gets sued? Malpractice liability colors every workflow change, whether anyone says so out loud or not.

None of this shows up in a generic readiness checklist. All of it can stop an AI deployment cold.

The blockers nobody puts on the project plan

Physicians and clinical staff control whether AI ever touches clinical workflow. The stated concern is usually speed or accuracy: "This will slow me down; the model isn't good enough." The real concern is autonomy and trust in a tool they didn't choose. Union strength sharpens this in teaching hospitals. Independent-physician leverage does the same in community systems.

Works councils, especially in European systems, hold co-determination rights. The stated concern is data protection. The real one is surveillance of their members. The behavioral signals a security team can switch on, things like Insider Risk analytics and detailed usage tracking, read as monitoring and can trigger a formal consultation.

Patient advocacy groups and ethics committees speak for the people receiving care. The stated concern is privacy. The real one is consent and algorithmic harm: was the consent genuinely informed and voluntary? Do patients understand what algorithmic help means for their care? That gets sharper with anything patient-facing.

Legal and Compliance gets misread more than any other group. The stated concern is almost always HIPAA. The real one is liability and organizational risk aversion. HIPAA usually permits what you're trying to do if you design for minimum-necessary use and get the vendor agreements right. The regulation is rarely the real blocker. Liability and vendor risk are. The vendor terms that matter are the ones on sub-processing, restrictions on model retraining with PHI, and data deletion. You answer that with a named governance owner and an audit trail, not by arguing with the statute.

The CISO and security team own breach liability and they hold a veto most IT leaders forget to plan for. The stated concern is data loss and audit coverage. The real one is that the needs of logging and monitoring an AI rollout can collide with the access model they already run. They're the ones accountable if it goes wrong. On a security-led program, this is your closest ally or your hardest gate, depending on whether you bring them in to co-design the controls or hand them a finished plan to approve.

The CMO, CNIO, and CMIO hold a veto that surprises most IT leaders. Clinical leadership can stop an IT-led initiative if they believe care continuity is at risk. A CIO can fund and deploy a program that either the Chief Medical Officer or the Chief Nursing Information Officer, depending on clinical scope, can still kill. The Chief Medical Information Officer sits between IT and clinical leadership. In practice, they often decide whether that co-sponsorship materializes at all, so engage the CMIO before you assume you have the others. If clinical leadership isn't a co-sponsor, you don't have a sponsor.

Stated concern vs. actual concern

The most useful habit you can build is separating what a stakeholder says from what they mean and then answering the real objection. The stated concern is the door you knock on. The actual concern is the room you have to walk into.

"HIPAA won't allow it" almost never means the regulation forbids it. It means "I don't want to own the risk of this change." Argue the regulation and you lose. Offer a governance owner and an audit trail, and you're past it.

When a physician says the model isn't accurate enough, they've usually not benchmarked anything. They mean "I didn't pick this and I don't trust being second-guessed by software." The fix isn't a better accuracy number. It's bringing them into scope and giving them a way out if it isn't working.

When a works council raises data-protection concerns, the subtext is often that their members feel watched. The fix is being precise about what is and isn't logged and involving them before you deploy instead of after.

When a CMO or CNIO raises care-continuity risk, they're often right, but underneath it sits a simpler ask: "I want a vote on this, not a notice." Co-sponsorship, where they review the real architecture and workflow decisions and not just the rollout message, is the key.

A stakeholder map for healthcare AI

Before you write a deployment plan, map the people. For each group, you want four things: their veto power, their stated concern, their actual concern, and your first move. Run this in a sixty-minute working session with your project lead before the kickoff deck exists. Rank by veto power. Anyone in the high rows who isn't engaged yet is a risk on your plan, not a footnote. The actual-concern column tells you what to bring to the first conversation.

Stakeholder	Veto power	Stated concern	Actual concern	First move
Physicians / clinical staff	High	Accuracy, speed	Autonomy, trust	Co-scoping; a clinical champion
CISO / security	High	Data loss, audit coverage	Breach liability, access-model conflict	Security co-leads governance; threat-model workshop
Works council	High (EU)	Data protection	Surveillance of staff	Early consultation; logging transparency
Patient advocacy / ethics	Med-High	Privacy	Consent, algorithmic harm	Consent design first
Legal & Compliance	High	"HIPAA"	Liability ownership	Named governance owner; audit trail
CMO / CNIO	High (veto)	Care continuity	A real vote and credit	Co-sponsorship, not sign-off
CMIO	Med-High	Workflow integration	Will IT respect clinical workflow	Scope the workflow with them early

Three example projects

A teaching hospital. A large academic medical center piloted ambient clinical documentation and the clinicians loved it. The residents' association still invoked a workflow-change review because the rollout hadn't been brought to them first. The pilot froze for six weeks and only restarted once the primary stakeholder came on as co-sponsor and the residents had a say in scope. Clinical co-sponsorship wasn't a formality. It meant the stakeholder reviewed the workflow design, not just the rollout message. That was what moved it.

A works council. A health system planned to turn on usage analytics and Insider Risk signals alongside Copilot. The works council read the activity logging as surveillance and opened a formal co-determination consultation that took several months. In those jurisdictions, organizations engage the works council before enabling anything that logs clinician behavior, and they are specific about what is and isn’t captured.

A community hospital. They wanted a patient-facing scheduling agent. The patient and family advisory council required a consent-and-disclosure design, so patients knew they were talking to an agent and agreed to it before going live. For anything patient-facing, consent design is a gate, not a finishing touch.

Three systems, three different blockers, one pattern: the technology was never the problem.

Who to talk to first

Mapping the stakeholders is half the job. Sequencing the conversations is the other half. The order that holds up across most healthcare deployments looks like this:

Clinical leadership first. Without a clinical co-sponsor, nothing else matters. Get the CMO or CNIO on board and the CMIO in to scope the workflow before you build a deck.
Security and the CISO early, as co-designers. Bring them the logging and access model while it's still a draft so the controls get built in instead of bolted on.
Legal and Compliance early, for partnership rather than permission. Bring them a governance owner and an audit-trail plan and ask them to help you de-risk, not to bless without oversight.
Frontline champions. Find the physicians and nurses who'll co-scope and advocate and give them real influence over what gets piloted.
Works councils, where they exist, before any logging goes live. Treat the consultation as a prerequisite, not a reaction.
Patient advocacy and ethics for anything patient-facing. Consent and disclosure design before go-live, every time.

Put these conversations on the calendar before the technical project plan, not after. You won't finish all of them before the kickoff deck, but if any of these people first hear about your plan in a steering-committee meeting, you've already lost ground. If you can't name the person on the other side of each one, your pilot is already at risk, however clean the deployment.

You can't engineer your way around a broken stakeholder map. The readiness work nobody talks about starts here. Not with licenses or Conditional Access, but with an honest map of who can stop you and why. Get the people right, address their concerns, and the technical deployment turns into the easy part.

Part 2, "Why Identity Is the Copilot Unlock," takes on the first hard technical gate: why so many health systems have bought Copilot and still can't turn it on, and how to work through the Okta-to-Entra migration without breaking 24/7 care.

Charles Wallace is a Senior FastTrack Architect at Microsoft. He works on Microsoft 365 Copilot and agent adoption across healthcare and life sciences and on the security, identity, and governance foundations that decide whether AI deployments actually succeed.

Limiting Microsoft 365 Copilot data exposure risk with Zero Trust apps and data controls

AuzinAhmadi — Wed, 08 Jul 2026 21:18:16 GMT

Co-authored by
AtilGurcan

In previous posts of this series, we mapped where exposure can exist when organizations deploy Microsoft 365 Copilot and categorized those risks into two distinct layers. Layer 1 covers risks associated with people who can access Microsoft 365 Copilot. Layer 2 covers risks associated with data Microsoft 365 Copilot can access.

Layer 2 risks are governed primarily by the Apps and Data pillars of Zero Trust, with Identity playing a secondary role in defining the scope of data each user can reach. Organizations can address these risks with Microsoft controls such as Microsoft Purview, SharePoint Advanced Management, Microsoft Entra ID Governance, and Microsoft Sentinel. The work is configuring and scoping them deliberately before Copilot scales across the organization.

How to read this post

Each section recaps one risk, describes the mitigation, names the Microsoft control that delivers it, and includes a placeholder for the supporting screenshot. Controls are cumulative—sensitivity labels, DLP policies, and audit logs work together across risks, so several mitigations reinforce one another.

R7: Overshared SharePoint and OneDrive content

Pillar: Apps and Identity

Content shared with “Everyone,” “Everyone except external users,” or broad security groups becomes part of Copilot’s queryable surface for any licensed user—even if that user would never have manually located those files. Years of SharePoint oversharing, combined with Copilot’s ability to traverse and synthesize content in a single prompt, can turn long-standing governance debt into immediate exposure. Copilot makes data once hidden by volume discoverable by intent.

Mitigation starts by understanding what is overshared, then systematically tightening the sharing scope before Copilot scales.

What to do:

Use Restricted SharePoint Search (RSS) during the Copilot pilot as a temporary way to narrow the SharePoint sites Copilot can ground against while you review permissions and governance controls before broad rollout. Then turn it off after validation rather than treating it as a long-term control.
Use SharePoint Advanced Management (SAM) to run data access governance reports and identify sites with “Everyone” or “Everyone except external users” sharing links—prioritize sites holding financial, HR, legal, or project data.
Remove or replace broad sharing links with scoped permissions; replace “Anyone” links with site-member access and require expiration dates on sharing links going forward.
Run Microsoft Entra ID Access Reviews scoped to Microsoft 365 groups and SharePoint site members to catch stale memberships that expand Copilot’s grounding surface.
Use Microsoft Purview Content Explorer to inventory which sites and libraries contain sensitive content and cross-reference with sharing scope.

SharePoint Advanced Management: data access governance report showing sites with broad sharing

R8: Sensitivity label gaps

Pillar: Apps and Data

Microsoft Purview sensitivity labels help classify content by sensitivity and, together with Purview policy controls, shape how that content can be used in Microsoft 365 Copilot. Unlabeled, mislabeled, or improperly inherited content is harder to govern consistently. Mitigation requires both discovering what is unlabeled and closing the labeling gap at scale through policy, rather than relying on manual user action.

What to do:

Turn on mandatory labeling in Microsoft Purview so users cannot save or share documents without applying a label—preventing new unlabeled content from accumulating.
Configure auto-labeling policies in Microsoft Purview to classify content at rest and in transit using built-in sensitive information types (SITs) and trainable classifiers—prioritizing SharePoint libraries and OneDrive for Business.
Apply default sensitivity labels to SharePoint document libraries and Teams channels so that content inherits a baseline label even when users do not label manually.
Turn on container-level label inheritance so that SharePoint sites and Teams workspaces propagate sensitivity settings to documents created within them.
Use Microsoft Purview Content Explorer to quantify the volume of unlabeled content across the tenant and track labeling progress over time.

Microsoft Purview: auto-labeling policy scoped to SharePoint and OneDrive

SharePoint document library: default sensitivity label applied to the library

Content Explorer: labeled vs. unlabeled content breakdown by location

R9: Excessive user permissions

Pillar: Identity and Apps

Copilot follows each user’s existing Microsoft Graph permissions and does not surface content the user cannot access. However, in many enterprise environments, users accumulate access far beyond their current role through leftover project permissions, broad temporary group memberships, and inherited rights from outdated organizational structures. Copilot does not create this overprovisioning, but it makes the full scope of that access immediately visible and usable. What previously required sustained effort to locate and correlate can now be surfaced in a single prompt.

Mitigation focuses on continuously right-sizing permissions to reflect actual role requirements, not historical accumulation.

What to do:

Run Microsoft Entra ID access reviews on a recurring schedule for all Microsoft 365 groups, SharePoint sites, and Teams with access to sensitive content. Require reviewers to justify continued membership rather than defaulting to approval.
Use SharePoint Advanced Management inactive site policies to identify and deprovision sites no longer in active use whose permissions have never been cleaned up.
Audit group memberships for broad “Edit” or “Full Control” rights and replace with scoped contributor roles aligned to current job function.
Apply the principle of least privilege to new project groups from the start: time-bound membership with expiration dates, and access reviews triggered at project close.
Review service account and application permissions in Microsoft Graph to ensure only humans hold standing access to content that Copilot can query.

SharePoint Advanced Management: inactive sites report

Microsoft 365 admin center: group expiration policy configuration

R10: No DLP coverage on Copilot-generated outputs

Pillar: Apps and Data

Copilot outputs—including summaries, drafts, and synthesized answers—can move sensitive information into new contexts, such as chats, emails, pages, and documents. Mitigation extends DLP coverage explicitly to Copilot interactions, grounding data, and downstream locations where generated content may be stored or shared.

What to do:

Use Microsoft Purview DLP for Microsoft 365 Copilot and Copilot Chat to block or audit sensitive prompts, limit external web search when prompts contain sensitive data, and restrict Copilot from using specified labeled files and emails as grounding data.
Configure communication DLP policies for Teams and Exchange so that Copilot-generated content pasted into messages, emails, or chats is evaluated against the same sensitive information type rules as source documents.
Turn on endpoint DLP on managed Windows devices to catch sensitive content that exits by way of clipboard paste, file save, or upload to unmanaged locations after being generated by Copilot.
Review DLP policy coverage for Copilot Pages and other Copilot output surfaces so that synthesized content stored or shared from those surfaces is governed consistently.
Regularly review DLP policy simulation reports to validate that rules fire against realistic Copilot output patterns, not just keyword matches in source files.

Microsoft Purview: DLP policy scoped to Microsoft 365 Copilot workload

Endpoint DLP: activity explorer showing Copilot-related policy matches

R11: Plugin and connector data surface expansion

Pillar: Apps and Identity

Organizations can extend Microsoft 365 Copilot through plugins and Microsoft Graph connectors that pull external data from CRM systems, ITSM platforms, HR applications, and custom line-of-business tools. Each connector expands the data surface Copilot can query on a user’s behalf and often reaches into systems where access control models do not align natively with Microsoft 365 permissions. As organizations add connectors without reviewing their scope and governance, each connected source introduces risk that scales alongside the broader Copilot data surface.

Mitigation requires deliberate governance over which connectors and plugins are turned on, for whom, and under what conditions—before the connected surface grows beyond visibility.

What to do:

Review and restrict which Copilot plugins and Graph connectors are enabled in the Microsoft 365 admin center, disable connectors not actively required, and require admin approval for new connector deployments.
Scope each approved connector to the minimum data set and user population it needs: not all Copilot users should have access to every connected source.
Audit the permission model of each external system behind a connector. Verify that the connector enforces source-system access control and does not flatten permissions for all Copilot users.
Log and review connector activity in the Microsoft 365 audit log to detect unexpected query patterns or unusually broad data retrieval through connected sources.

Microsoft 365 admin center: Copilot plugins and connectors management page

Microsoft Graph connector: connection status and scoped user access settings

R12: Audit and visibility gap

Pillar: Apps and Data

Organizations need visibility into Copilot activity so they can investigate suspicious behavior, monitor adoption, and understand which content sources are involved. Disabling Copilot interaction logging, retaining audit logs for too short a period, or failing to forward logs to a SIEM leaves organizations without the evidence needed to detect anomalous usage patterns, or support incident response. Mitigation requires turning on the right audit tier, retaining logs long enough to support investigation, and building those signals into security operations.

What to do:

Verify that Microsoft Purview Audit (Standard or Premium) is enabled for the tenant and that Copilot interaction events are being captured. Confirm in the Purview compliance portal that Copilot activities appear under the Audit search.
Upgrade to Microsoft Purview Audit Premium for high-risk user populations—including privileged identities and users with access to sensitive sites—to extend log retention up to ten years and gain access to intelligent insights.
Set a minimum audit log retention of 90 days for all users; extend to 180 days or longer for any user group that accesses sensitive or regulated content through Copilot.
Forward Microsoft 365 audit logs to Microsoft Sentinel (or the organization’s existing SIEM) to correlate Copilot activity with endpoint, identity, and network signals and to turn on automated detection rules.
Review Microsoft 365 Copilot usage reports in the admin center regularly to identify unusual query volumes, off-hours activity, or access to unexpected content sources.

Microsoft Purview Audit: Copilot interaction events in audit search

Microsoft Purview Audit: Copilot interaction events in audit search results

R13: Privileged user data amplification

Pillar: Identity, Apps and Data

Administrators, senior IT staff, and other privileged users often hold access that spans organizational boundaries—including mailboxes, site collections, security groups, and configuration data that most users never reach. A Copilot-enabled admin account that is compromised or misused gives adversaries—or an inadvertent insider—an organization-wide view of data that far exceeds the exposure associated with a compromised end-user account. Because Copilot amplifies the full scope of a user’s existing access, privileged identities require the strictest governance controls.

Mitigation applies Just-In-Time access, dedicated account separation, and elevated monitoring to ensure privileged identities are not simultaneously full administrators and active Copilot users.

What to do:

Use Microsoft Entra Privileged Identity Management (PIM) to enforce Just-In-Time (JIT) elevation for administrative roles. Privileged access should be time-bound, require justification, and expire automatically after the task is complete.
Do not assign Copilot licenses to dedicated admin accounts. Administrators should use separate work accounts for day-to-day productivity and Copilot access, keeping elevated administrative permissions away from Copilot-enabled sessions.
Apply the strictest Conditional Access policies to any identity that holds both a Copilot license and elevated permissions. Require phishing-resistant MFA, compliant devices, and enforce token protection.
Enable Entra ID access reviews specifically scoped to privileged role members to ensure administrative permissions are actively justified and time-limited, not held indefinitely.
Prioritize Microsoft Purview Audit Premium for all privileged identities to capture a complete, long-retention record of Copilot interactions associated with high-privilege accounts and forward those logs to Sentinel for alerting.

Microsoft Entra PIM: active role assignments showing time-bound expiration

Conditional Access: policy scoped to privileged role members with phishing-resistant MFA

Layer 2 mitigations at a glance

Each Layer 2 risk maps to a primary control and the Microsoft tool that delivers it. Microsoft Purview recurs across multiple risks because it is the central governance layer for data classification, protection, and audit visibility in the Microsoft 365 environment.

Risk	Primary control	Microsoft tool
R7—Overshared content	Sharing scope reduction + access reviews	SharePoint Advanced Management, Entra ID Access Reviews
R8—Sensitivity label gaps	Auto-labeling + mandatory labeling	Microsoft Purview sensitivity labels
R9—Excessive user permissions	Recurring permission reviews + JIT scoping	Entra ID Access Reviews, SharePoint Advanced Management
R10—No DLP on Copilot outputs	DLP extended to Copilot workloads	Microsoft Purview DLP, Endpoint DLP
R11—Plugin and connector expansion	Connector governance + scoping	Microsoft 365 admin center, Purview DLP
R12—Audit and visibility gap	Full audit coverage + SIEM forwarding	Microsoft Purview Audit Premium, Microsoft Sentinel
R13—Privileged user amplification	JIT access + account separation	Microsoft Entra PIM, Conditional Access

Complete your Zero Trust approach to Microsoft 365 Copilot

Microsoft 365 Copilot does not create new permissions or expose data users cannot already access. What it does do is make existing access more discoverable, bringing years of accumulated oversharing, excessive permissions, unlabeled content, unmanaged connectors, and governance gaps into sharper focus. As a result, reducing Copilot data exposure is not a one-time cleanup effort but a continuous governance practice.

Across this series, we've examined both sides of the Microsoft 365 Copilot risk equation: who can access Copilot and what Copilot can access on their behalf. Together, the Layer 1 and Layer 2 controls provide a practical, Zero Trust-aligned framework for governing identities, devices, applications, and data throughout your Copilot deployment.

For security, compliance, identity, and IT administrators, the next step is to assess your current environment against the risks discussed throughout this series. Review sharing configurations, sensitivity labeling coverage, data loss prevention policies, access governance practices, connector management, and audit visibility to identify gaps before Copilot adoption scales.

Addressing these gaps now can help reduce risk, strengthen compliance, and build a more secure foundation for AI-powered productivity. Use the controls discussed throughout this series to develop a Microsoft 365 Copilot deployment strategy that aligns with your organization's security, compliance, and business requirements. For additional guidance, see the Zero Trust Overview on Microsoft Learn.

Atil Gurcan is a Senior FastTrack Architect who works with customers to implement secure & compliant AI experiences and accelerate their digital transformation, increasing ROI for their investments with Microsoft.

Mitigating Microsoft 365 Copilot access risk: Identity and device controls for Zero Trust

AuzinAhmadi — Wed, 08 Jul 2026 21:16:35 GMT

Co-authored by
AtilGurcan

In our previous post, we mapped where exposure can exist when organizations deploy Microsoft 365 Copilot and grouped those risks into two layers. Layer 1 focused on who can access Copilot—the identity and device conditions that determine whether a user can reach the service.

If those identity and device conditions are weak, exposure may extend beyond a single workload across the user’s entire Microsoft 365 data surface. This post shifts from mapping risk to reducing it.

Each of the six Layer 1 risks (R1–R6) is governed primarily by the identity and endpoints pillars of Zero Trust. The good news: customers with Microsoft 365 E5 already own the controls required to address these risks, including Microsoft Entra ID, Conditional Access, Microsoft Intune, and Microsoft Defender. The next job is configuring and scoping them deliberately before scaling deployment.

How to read this post

Each section recaps one risk, describes the mitigation, names the Microsoft control that delivers it and indicates where to capture the supporting screenshot. These controls are additive. Conditional Access ties identity and device signals together, so several mitigations reinforce one another.

R1—Unmanaged identity access

Pillar: Identity

Because Copilot operates across the full scope of a user's permissions, a compromised, shared, or orphaned account exposes far more than it would have before. Mitigation starts with disciplined identity lifecycle management so that accounts exist only when they should and belong to real users.

What to do:

Automate joiner, mover, and leaver processes with Microsoft Entra Lifecycle Workflows so accounts are provisioned, re-scoped, and disabled on schedule rather than manually.
Run recurring access reviews on Copilot-licensed groups to identify stale or unnecessary accounts.
Eliminate shared and generic accounts; require an individual, attributable identity for every Copilot user.
Block or remove dormant accounts and monitor sign-in activity for privileged identities.

The following examples show lifecycle workflows and access review configuration:

Figure: Lifecycle Workflows—leaver workflow showing account-disable tasks

Figure: Access reviews—review scoped to the Copilot users group

R2—Weak or absent multi-factor authentication

Pillar: Identity

If MFA is inconsistent—or legacy authentication bypasses modern sign-in controls—an attacker may need only a stolen password to open a Copilot session that synthesizes data across services. Closing this gap means enforcing strong authentication consistently and shutting down the protocols that route around it.

What to do:

Require MFA for all users with a Conditional Access policy; use Microsoft-managed policies as a baseline, then tighten.
Move to phishing-resistant authentication methods, such as FIDO2 security keys, Windows Hello for Business, or certificate-based authentication.
Block legacy authentication protocols that don't support modern MFA.
Turn on Microsoft Authenticator number matching and additional context to help resist MFA fatigue attacks.

Figure: Conditional Access—require multifactor authentication policy

Figure: Authentication methods—phishing-resistant methods enabled

R3—Unmanaged or noncompliant devices

Pillar: Endpoints

Users can reach Copilot from any device where they can authenticate. Without endpoint protection, encryption, and compliance evaluation, sessions and their outputs can be stored or exfiltrated from untrusted devices. Mitigation pairs device compliance in Intune with a Conditional Access policy that enforces it.

What to do:

Define Intune compliance policies that require disk encryption, minimum OS versions, endpoint protection (EDR/Defender), and no jailbreak or root status.
Use a Conditional Access grant control that requires devices to be marked compliant, or hybrid Microsoft Entra joined before accessing Microsoft 365 and Copilot.
Feed Microsoft Defender for Endpoint device risk signals into compliance evaluation, so high-risk devices fall out of compliance automatically.

Figure: Intune compliance policy—encryption, minimum OS, and Defender requirements

Figure: Conditional Access—require device to be marked as compliant

R4—License sprawl without role-based scoping

Pillar: Identity and apps

Broad pilot enrollment—licensing whole departments or floors—is itself a risk factor because it grants Copilot access to both well-governed and minimally governed users without an access review. Mitigation makes licensing deliberate: a reviewed group assigned through policy after each member's access is checked.

What to do:

Assign Copilot through group-based licensing tied to a named, security-reviewed pilot group—not by department or location.
Run an access review on each pilot member's permission posture and role sensitivity before granting the license.
Phase rollout in cohorts and consider Restricted SharePoint Search during the pilot to limit the grounding surface.

Figure: Microsoft 365 admin center—Copilot license assignment count

R5—Missing real-time risk evaluation at sign-in

Pillar: Identity and endpoints

Static controls grant or deny access once; they don't react to a session that turns risky. If Conditional Access doesn’t evaluate sign-in and user risk signals—impossible travel, anomalous tokens, Identity Protection alerts—a high-risk session can still reach Copilot before anyone responds. Mitigation makes access decisions risk-aware in real time.

What to do:

Turn on Microsoft Entra ID Protection (included in E5) to generate user risk and sign-in-risk signals.
Create risk-based Conditional Access policies: require MFA or a secure password change on elevated risk, and block on high risk.
Add token protection to bind sign-in sessions to the device and reduce token replay exposure.

Figure: Conditional Access—user risk condition set

Figure: Identity Protection—risky sign-ins dashboard

Figure: Conditional Access—require token protection session control

R6—App protection gap on mobile devices

Pillar: Endpoints and apps

On personal phones that aren't enrolled in MDM, organizations still need to govern the app. Without an application protection policy, users can copy Copilot output into unmanaged apps, and data on a lost device can't be wiped. Mobile Application Management (MAM) protects corporate data inside the app without managing the whole device.

What to do:

Deploy Intune App Protection Policies (MAM) for iOS and Android: require an app PIN, encrypt app data, and allow selective wipe of organizational data.
Restrict data egress: block copy/paste and 'Save As' to unmanaged locations, and block screen capture where the platform supports it (Android).
Pair with a Conditional Access grant requiring an approved client app and an app protection policy for mobile access.

Figure: Intune app protection policies—iOS and Android policy list

Figure: App protection policy—data protection, block copy/paste, and “Save As”

Figure: Conditional Access—require approved client app and require App Protection Policy

Layer 1 mitigations at a glance

Each Layer 1 risk maps to a primary control and the Microsoft tool that delivers it. Conditional Access recurs because it is where identity and device signals are enforced together.

Risk	Primary mitigation	Microsoft control
R1	Identity lifecycle + access reviews	Entra Lifecycle Workflows; Access reviews
R2	Enforce phishing-resistant MFA; block legacy auth	Conditional Access; Authentication methods
R3	Require compliant/managed devices	Intune compliance policies; Defender for Endpoint; Conditional Access
R4	Scoped, reviewed licensing	Group-based licensing; Access reviews
R5	Real-time risk gating at sign-in	Entra ID Protection; risk-based Conditional Access; token protection
R6	Protect data inside mobile apps	Intune App Protection Policies (MAM); Conditional Access

Securing Copilot access isn't only about who can sign in—it's about validating the devices, conditions, and access patterns behind every session. The six controls above close Layer 1 gaps before risky access patterns scale across the organization.

Governing Microsoft 365 Copilot risk: Next steps

Microsoft 365 Copilot security starts before a prompt is ever entered. Identity, device, and session controls help verify that the right people are accessing Copilot from trusted devices under the right conditions. Closing Layer 1 gaps reduces the likelihood that compromised identities, risky sign-ins, or unmanaged devices can access organizational data.

Controlling who can access Copilot is the first step. The next challenge is governing what Copilot can access once a user is authenticated. Strong access controls reduce the chances that the wrong person reaches Copilot. Layer 2 focuses on a different question: if the right person signs in, what information can they discover, summarize, and use?

In the next post of this series, we'll shift from access controls to data controls and explore how organizations can reduce Layer 2 risk through SharePoint and OneDrive permissions management, sensitivity labels, data loss prevention (DLP), connector governance, and auditing capabilities.

Before expanding your Copilot deployment, review the six Layer 1 controls covered in this article and identify any gaps in your identity, device, and access policies. You can also use the Zero Trust Workshop to assess your current security posture and prioritize remediation efforts.

When you're ready, continue to Post 3 in this series: Governing Microsoft 365 Copilot data risk to examine how data governance controls help limit exposure after authentication and strengthen secure Copilot adoption.

Understanding Copilot Risk: Mapping Exposure Across Zero Trust Pillars

AuzinAhmadi — Wed, 08 Jul 2026 21:16:10 GMT

Co-authored by
AtilGurcan

AI represents a major shift in how users interact with organizational data. Instead of finding information one file, email, or chat at a time, users can ask natural language questions and get synthesized answers drawn from content they already have permission to access. That can improve productivity, but it can also amplify the impact of broad access, oversharing, and weak governance.

Microsoft 365 Copilot brings this shift into focus. It doesn’t grant new permissions, but it acts as a force multiplier for existing access, making it faster and easier for users to discover, aggregate, and act on data across Microsoft 365. That makes it critical to understand both who can access Copilot and what data it can surface on a user’s behalf. A second layer of risk follows from how organizational data is structured, shared, and governed. In environments with overshared content, excessive permissions, or inconsistent governance, this acceleration can lead to faster and broader access to sensitive information than organizations may expect.

This shift carries important security implications, especially as organizations move from pilots to scaled deployment. While customers with Microsoft 365 E5 licensing may already have access to tools that help identify and reduce risk, licensing alone does not reduce exposure.

What’s often missing during early Copilot deployments is a clear view of the risk surface itself: what data is exposed, who can access it, and through which vectors. Organizations building their Microsoft 365 Zero Trust posture can use the Zero Trust Workshop to assess their current posture, identify gaps, and better understand how existing permissions and governance impact Copilot readiness.

In this post, we map Copilot-related risk to the key Zero Trust control areas most relevant to deployment: identity, endpoints, apps, and data. Our goal is to help organizations understand where exposure exists and which control areas they should focus on before scaling deployment.

Use Zero Trust to assess Microsoft 365 Copilot risk

Microsoft defines Zero Trust as a security model built on three core principles: 

Verify explicitly
Use least privileged access
Assume breach

Instead of trusting users or devices based solely on network location, Zero Trust requires continuous validation of every user, endpoint, and request, regardless of where the request originates. Microsoft’s Zero Trust adoption model groups security controls across technology pillars such as identities, endpoints, apps, data, network, infrastructure, and security operations.

For this analysis, we’ll focus on the four pillars most directly involved in Microsoft 365 Copilot deployments: identity, endpoints, apps, and data.

Figure 1. Four control areas that shape Copilot exposure

Together, these pillars help answer three key questions:

Who can access Copilot
From which endpoints and applications
What data can Copilot surface once access is granted

For more information and details about Microsoft’s Zero Trust framework, visit Zero Trust Overview at Microsoft Learn.

Why Microsoft 365 Copilot changes the risk conversation

Before assessing specific risks, it helps to understand why Copilot changes the risk conversation compared to traditional Microsoft 365 applications. Most enterprise apps operate within a bounded context. The time and effort required to manually locate, connect, and synthesize information across systems creates friction and a practical limit on how quickly users can surface and act on data across systems. Copilot removes much of that friction. At the speed of a prompt, Copilot lets users retrieve and bring together information from across a user’s existing access—spanning emails, files, meetings, chats, and other Microsoft 365 services—in a single response.

This exposure is not a result of new permissions. It comes from how quickly and easily existing access can be discovered, aggregated, and used. To understand where exposure appears, it helps to break Copilot risk into two interconnected layers: access and data.

Figure: Two-layer model for Microsoft 365 Copilot risk.

The two-layer Microsoft 365 Copilot risk model

The foundation of this analysis is simple: Copilot acts as a force multiplier for whatever access a user already has. If that access is governed well, Copilot can improve productivity. If not, it can amplify exposure.

With that framing in mind, we’ll examine Copilot risk in two distinct layers:

Access to the Copilot service itself
Access to the data that Copilot can ground on and surface

The first layer focuses on who can access Copilot and under what conditions. The second focuses on what Copilot can see and surface once access is granted.

Risk layer 1: Who can access Microsoft 365 Copilot?

The first layer of risk begins at the point of entry: the conditions that determine whether a user can access Copilot. Organizations don’t need to address every potential exposure point at once. Start by using the table below as a map of where exposure can exist across identity and endpoint controls. We’ll explore how to mitigate these risks in the second post of this series.

The risks below are primarily governed by Microsoft’s Zero Trust identity and endpoint pillars. Together, these pillars help determine whether the right user can access Copilot from a trusted endpoint under the right access conditions.

Table 1. Identity and endpoint risks that affect Copilot access

	Risk	Pillar	Description
R1	Unmanaged identity access	Identity	A compromised, shared, or former employee account can authenticate Microsoft 365 and access Copilot. Because Copilot operates across the full scope of a user’s permissions, compromised accounts can expose a much larger risk surface than before Copilot existed. Strong account hygiene and identity lifecycle management can reduce that exposure.
R2	Weak or absent multi-factor authentication (MFA)	Identity	If MFA isn’t enforced, or if legacy authentication bypasses modern sign-in controls, users can start Copilot sessions with only a password. In environments with inconsistent MFA coverage, stolen credentials may be enough to gain access. Because Copilot can synthesize data across services, compromised accounts create more risk than access to a single application.
R3	Unmanaged or non-compliant devices	Endpoints	Users can access Copilot through browsers and native apps from any device where they can authenticate. Unmanaged or noncompliant endpoints without endpoint protection, encryption, or compliance evaluation can expose Copilot sessions and allow outputs to be stored or exfiltrated locally.
R4	Broad Copilot licensing without role-based scoping	Identity and apps	Broad Copilot licensing without role-based scoping. Copilot pilots often begin with broad license assignments across departments or business units instead of smaller, security-reviewed user groups. When organizations assign licenses without reviewing access rights, permission posture, and role sensitivity, they can expand exposure across both well-governed and minimally governed users.
R5	Missing real-time risk evaluation at sign-in	Identity and endpoints	If Conditional Access doesn’t evaluate sign-in and user risk signals, such as anomalous activity, or identity protection alerts, high-risk sessions may still reach Copilot. Without real-time risk evaluation, controls may respond only after access is granted.
R6	App protection gap on mobile devices	Endpoints and apps	Users can access Copilot from personal mobile devices that are not enrolled in device or app management. Without app protection policies, organizations may not be able to control how Copilot outputs move into unmanaged apps or remove organizational data from lost devices.

Key observations from Layer 1:

Identity appears most frequently across Layer 1, reflecting how tightly Copilot access depends on authenticated user permissions and sign-in conditions. Endpoint-related risks also play a major role because unmanaged or noncompliant endpoints can expose Copilot sessions and outputs beyond the organization’s trusted environment.

Together, these risks show that securing Copilot access is shaped by two factors: who can sign in, and whether the endpoint and session meet the organization’s access requirements.

Risk layer 2: What data can Microsoft 365 Copilot reach?

The second layer of risk assumes that the user is already authenticated and actively using Copilot. At this stage, the focus shifts from who can access Copilot to what data Copilot can surface on the user’s behalf. These risks reflect the exposure created by existing permissions, overshared content, connected systems, and governance gaps.

Layer 2 risks are governed primarily by the apps and data pillars, with identity playing a secondary role in defining the scope of data each user can access. Much of Copilot’s value and risk comes from how it surfaces information based on user intent.

Figure:How user intent changes data discovery

Data and application risks that shape Copilot exposure

These risks highlight how permissions, sharing, labeling, and governance directly shape what Copilot can retrieve, synthesize, and surface across organizational data.

	Risk	Zero Trust pillar(s)	Description
R7	Overshared SharePoint and OneDrive content	Apps and identity	Content shared with "Everyone," "Everyone except external users," or broad groups can become part of Copilot’s queryable surface for licensed users who already have access to that content. Years of oversharing, combined with Copilot’s ability to retrieve and synthesize content in a single prompt, can turn long-standing governance gaps into immediate exposure. Copilot can make data that was once hidden by volume, discoverable by intent.
R8	Sensitivity label gaps	Apps and data	Microsoft Purview sensitivity labels and related protections tell Copilot how to handle content, including whether it can summarize, cite, or include that content in responses. Across containers such as SharePoint sites and Teams, unlabeled, incorrect, or inconsistently labeled content may be treated as unclassified and surfaced freely. Large volumes of legacy content can make that gap harder to manage at scale.
R9	Excessive user permissions	Identity and apps	Copilot follows each user’s existing Microsoft 365 permissions and does not surface content users cannot access. However, users often accumulate access beyond their current role through leftover project permissions, temporary group memberships, and inherited access. Copilot doesn’t create this overprovisioning, but it can make the full scope of it easier to discover and use.
R10	No DLP coverage on Copilot-generated outputs	Apps and data	Copilot outputs, such as summaries and drafts can combine sensitive details from multiple sources. Organizations should review how their DLP labeling and data protection policies apply to generated content, especially when users move Copilot outputs into email, chat, or external documents.
R11	Plugin and connector data surface expansion	Apps and identity	Organizations can extend Copilot through agent and connectors that pull external data from CRM systems, ITSM platforms, and other line-of-business tools. Each connected source expands the set of data users can access through Copilot. Each connected source expands the set of data users can access through Copilot and may introduce governance and access model differences that need to be reviewed.
R12	Audit and visibility gap	Apps and data	Organizations need enough visibility to understand how users interact with Copilot and which resources Copilot accesses in response to prompts. Audit logs and monitoring help security teams investigate suspicious activity, understand usage patterns, and reduce risk over time.
R13	Privileged user data amplification	Identity, apps and data	Privileged users often hold access across sensitive systems and data. A compromised privileged account with Copilot access can expose a much larger slice of organizational data than a standard user account. Privileged identities therefore need tighter access to governance and review.

Key observations from Layer 2:

Apps-related risks appear throughout Layer 2 because Microsoft 365 Copilot depends on connected systems, accessible data sources, and governance over generated outputs. The data pillar reinforces the need to protect both sensitive source content and the AI-generated responses that bring content together. The table above maps each risk to its primary and secondary Zero Trust pillars to show where to act. Primary pillars represent control areas that most directly govern a given risk, while secondary pillars represent contributing factors.

Governing Microsoft 365 Copilot risk: Next steps

Copilot typically doesn’t grant broader access than a user already has. Instead, it makes existing access easier to discover, connect, and use across Microsoft 365. Organizations that successfully scale Copilot are the ones that understand and govern that access first. Understanding where exposure exists is the first step. Your next step depends on where your organization is in their Zero Trust journey.

Need to assess your current status? Visit the Zero Trust Workshop.

Ready to learn more about reducing risk by strengthening access controls at the point of entry? Check out post 2 of this series: Mitigating Microsoft 365 Copilot access risk: Identity and device controls for Zero Trust.

Azure Availability Zone Mapping and VM Resilience Analysis Guidance using SRE.AZURE.COM Agent

munieswar_avulapalli — Mon, 08 Jun 2026 19:50:35 GMT

Overview

This guidance, supported and tested using SRE.Azure.com, helps Azure platform engineers understand how Availability Zones are mapped within their subscription and how virtual machines (VMs) are distributed across those zones.

SRE.Azure.com enables discovery and analysis of zone mappings, VM placement, and infrastructure resilience.

Why This Matters

Azure uses logical zones (1, 2, 3), but these map differently to physical datacenter zones (az1, az2, az3) in each subscription. This means workloads in the same logical zone across subscriptions may not be physically co-located.

Understanding this is critical for high availability, disaster recovery, compliance, and resilience planning.

Example

sub-prod-eastus-01 -> Zone 1 → az3
sub-prod-eastus-01 -> Zone 2 → az1
sub-prod-eastus-01 -> Zone 3 → az2
sub-prod-weu-01 -> Zone 1 → az1
sub-prod-weu-01 -> Zone 2 → az2
sub-prod-weu-01 -> Zone 3 → az3

Key takeaway: Logical zone numbers do not guarantee physical separation across subscriptions.

What SRE.Azure.com agent Enables

- Discover logical-to-physical zone mappings
- Analyze VM distribution across zones
- Identify resilience gaps
- Generate presentation-ready reports

Suggested Prompt

“Act as an Azure platform engineer and generate a clean, presentation-ready analysis for availability zone design.

For Azure subscription <subscription-id>, produce two outputs inline in chat.

Output 1 — Zone Mapping Summary
- Query Azure directly for region availability zone mappings
- Show how logical zones map to physical zones
- Include a takeaway and tables

Output 2 — VM Resilience Distribution
- List VMs with zone, physical mapping, and protection level

Formatting:
- Use markdown tables
- No raw JSON
- Screenshot-friendly layout
- End with 3 observations”

Example output:

And so on ……

Next Steps:

Get Started | Azure SRE Agent

What is SRE Agent? | Azure SRE Agent

Microsoft 365 Copilot on mobile: What staged rollout plans can miss

JulieHersum — Tue, 02 Jun 2026 21:50:56 GMT

IT teams often design rollout plans in careful stages: the right pilot group, the right prerequisites, the right communications, and the right guardrails. Sequencing matters.

But when Microsoft 365 Copilot on mobile shows up in your environment, the shape of adoption can change.

Employee behavior doesn’t always follow the same tidy stages as licensing or deployment plans. Once people can use Copilot in the moments where work actually happens—between meetings, on the go, in a hallway conversation, before a customer call—usage can spread faster, more socially, and less linearly than many rollout models assume.

You can stage the rollout, but you can’t always stage the real-world usage pattern that follows. And mobile is one of the fastest places that gap shows up.

What we’re seeing: mobile changes the moments where Copilot shows up

Mobile shifts adoption because it changes the context in which Copilot appears day to day:

Copilot shows up more during “in-between” work moments

Those moments where people look for quick help: summarizing, drafting, finding, checking, and preparing.

Usage spreads through behavior, not just rollout sequence

A teammate shares a faster way to prep for a meeting. A leader asks for a quick recap while traveling. A project team starts referencing Copilot outputs in a chat thread. That kind of spread can move ahead of your staged plan.

Desktop assumptions don’t always carry over cleanly

Governance, communication, and readiness decisions that feel straightforward in a desktop-first mindset can surface earlier when usage starts in mobile-first ways.

Taken together, mobile introduces a second force into staged rollout planning: behavioral adoption momentum that doesn’t always wait for the next planned phase.

Staged Copilot deployment ≠ staged usage

Mobile frequently compresses the “pilot → expand → scale timeline,” creating earlier-than-expected issues:

IT starts fielding questions about “what’s allowed,” “what’s recommended,” or “what’s safe” before the plan anticipated
Governance and communication become tightly linked. If the org hasn’t expressed expectations and guardrails early and clearly, fast-moving usage can create confusion or conflicting local norms
Rollout plans start competing with reality. Mobile can make Copilot feel “present” in daily work. While IT is still staging rollout, parts of the organization behave like they’re already in broader adoption.

In many environments, this doesn’t stay theoretical for long.

What to do: four areas that tend to matter most

If you’re planning your Copilot rollout, you’ll want to think through these four connected areas:

Rollout sequencing: how you stage availability and expansion
User behavior expectations: how adoption may spread, and how you’ll message it
Governance and readiness considerations: what needs to be clear before usage accelerates
Communication planning: how you set expectations so momentum doesn’t create confusion

If you’re hearing early signals that people are experimenting with Copilot in mobile contexts before the rollout has fully caught up or already seeing pockets of usage spreading faster than expected, use these four as levers for regaining clarity and alignment

Next step

Read the full blog for Microsoft 365 Copilot mobile rollout planning guidance, including how to align sequencing, governance, and communication, whether you’re still designing your rollout approach, or already responding to early signs of faster-than-expected adoption.

Read the full Accelerator blog: Microsoft 365 Copilot on mobile: Planning guidance for IT admins

Windows 365 for Agents: run AI agents in Cloud PCs across real applications

JulieHersum — Thu, 28 May 2026 01:04:03 GMT

Copilot agents have been talking the talk—summarizing information, drafting content, and answering questions. But soon they’ll be walking the walk—executing workflows across systems in policy-controlled Cloud PCs.

With Windows 365 for Agents (now in public preview), you can run AI agents in a secure environment and use natural language to direct them to work across software and complete tasks, such as processing invoices or updating CRM data.

What’s changing?

It may sound like a small shift, but Windows 365 for Agents introduces a fundamentally different runtime model.

For the first time, you’ll be able to automate workflows that live outside APIs across real applications—including legacy and UI-based systems—without giving up enterprise security or control.

Much of today’s work still lives in browsers, desktop apps, and legacy systems—environments that assume intentional, human behavior. But agents behave differently:

Humans operate intermittently and with judgment
Agents can operate continuously and at scale

Agents depend on IT-defined boundaries, such as identity, policy, access, and monitoring, to keep execution aligned with intended workflows.

Without boundaries, agents can:

Access unintended systems
Act beyond their intended scope
Amplify small mistakes across workflows

Agents need a dedicated execution space designed for autonomous activity but governed by humans by default.

Windows 365 for Agents introduces the right execution environment

Windows 365 for Agents provides a dedicated Cloud PC environment that lets you define and control agents in various ways:

Independently and continuously, or on demand
Under your existing identity, policy, and management controls, such as Microsoft Entra ID and Intune
As repeatable, multi-step workflows across real applications, including legacy and UI-based systems, within the boundaries you set

Running agents in this controlled environment helps isolate risk and enforce security boundaries so act autonomously while remaining fully governed by your policies and without negatively impacting production systems.

Get started with Windows 365 for Agents

Interested in how this works and what Windows 365 for Agents unlocks for your environment? Read full blog, Windows 365 for Agents: run AI agents on secure cloud PCs, to learn more.

Deploying DNS Private Resolvers and Private DNS Zones for Azure AI Supported Services

munieswar_avulapalli — Tue, 28 Apr 2026 19:24:54 GMT

Private Networks:

Private DNS Zones: Resolves domain names to private IPs within Azure virtual networks without exposing them to the internet. Private DNS Zones are global, you don’t need to create multiple same private DNS Zones, you can reuse the same zones as it’s global
DNS Private Resolvers: Fully managed service that enables DNS resolution between Azure VNets and on-premises networks without custom DNS servers. DNS Private resolvers are regional, which means if you have Azure EAST US and WEST US 2 regions, you need to create DNS Private resolvers in both regions linked to Private DNS Zones, you can adopt centralized or distributed DNS Private resolvers, I will discuss both options later in this article

Public Networks: <In this part – not focusing on Public Networks>

Public DNS Zones: Resolves internet-facing domain names to publicly accessible IP addresses
Traffic Managers: DNS-based traffic load balancer that routes client requests to the best available global endpoint
DNS Security Policy: Controls and protects DNS resolution behavior (e.g., filtering, forwarding, and access rules) to secure name resolution and prevent misuse

**Note: 1. Follow Prerequisites to deploy resources. 2. A common misconception is that VNet peering enables DNS resolution. In reality, private DNS zones are only accessible to VNets that are explicitly linked to them, peering provides connectivity, but not name resolution.

In the following snapshot à Azure Portal à Network Foundations à DNS, lets explore individual DNS Services offered and later in this document, we will interconnect

**Credits to Microsoft Azure Portal Design team for creating new grouped views – you can check out for more – like compute infrastructure, Hybrid, Backup

Now, let’s delve into scenario 01: I have grabbed the following snapshot from Azure AI Landing Zones and removed non-network Azure resources to focus only on private Network components,

**Credits to AI Landing Zone team for the diagram, Original Version:

Inbound Zoom in view with End-to-End Flow

Hop	Summary
1	Client initiates request
2	DNS query sent to on-prem DNS
3	DNS query forwarded to Azure
4	Azure DNS Resolver processes query
5	Private DNS resolves to Private Endpoint IP
6	Traffic routed via VNet peering
7	Traffic hits Private Endpoint
8	Request served by Azure Files

*Link Private DNS to DNS resolvers in other regions, Private DNS is GLOBAL and DNS Resolvers are regional

Example Snapshot of entire flow:

Nslookup from Client machine,

Domain – DNS Conditional Forwarder configuration

Note 1: Make sure you selected “All DNS Servers in this forest” for replication, otherwise users pointed to some other domain will be unable to resolve

Verifying Connectivity with PsPing <credit to Sysinternals team PsPing >

PsPing, a tool from Sysinternals, is highly effective for verifying network connectivity from on-premises environments to Azure resources on specific ports. This is particularly useful when you need to ensure connectivity to ports such as 445, 443, 1433, 1521, or any other port required by Azure services you intend to access from either on-premises locations or other cloud environments.

By using PsPing, you can test and confirm that the necessary ports are open and accessible, which is crucial for troubleshooting connectivity issues and ensuring smooth communication between your on-premises infrastructure and Azure-hosted resources.

Ensure your firewall is set to allow traffic
DNS private resolvers – inbound configuration

Private DNS Configuration

Virtual Network links enable to your private dns

Make sure you have peer between hub and spoke
Private Endpoint configuration

Storage Account configuration

“Replace the file share with any supported Azure service that uses Private Endpoints, and follow the same guidance.”

2. Outbound <flow and resources colored with blue> part 2 upcoming soon

Copilot agents are scaling faster than most organizations expected

JulieHersum — Fri, 17 Apr 2026 17:53:04 GMT

Copilot agents are easy to pilot.

Across organizations, teams are building agents to automate tasks, surface insights, and streamline everyday work. Early results are positive—and encouraging. One agent leads to another. Interest spreads. Adoption grows.

Then a different question starts to surface:

What happens when Copilot agents move beyond experiments and start to scale across the organization?

That’s where things are getting more complicated.

When success creates a new problem

In early stages, conversations about Copilot agents focus on how to build, with questions centering on tools, prompts, and connectors. As usage expands, the challenge shifts away from delivery and toward coordination.

Organizations see signals like:

Multiple teams building agents independently
Overlapping use cases with different risk profiles
Unclear ownership as agents move into shared workflows
Hesitation around approving the next agent

These aren’t failures. They’re signs that agent usage is becoming meaningful enough to require intent, especially at an enterprise level.

Why scale changes the conversation

As Copilot agents move from isolated experiments to shared enterprise capability, the conversation shifts. The challenge is no longer just how to deliver agents, but how—and which—agents the organization should operate at scale.

That shift introduces tradeoffs that rarely appear during pilot phases:

How much autonomy should teams retain?
Where does consistency start to matter?
How should we support experimentation without creating fragmentation?
How can leadership stay aligned as impact grows?

Without a shared way to reason through these decisions, choices begin to outpace clarity.

This is where many IT and business leaders pause. Not to stop innovation, but to ask a more fundamental question:

What does “scaling well” actually look like for us?

A CIO‑level framework for deliberate scale

Organizations that recognize themselves at this inflection point will want to read Microsoft’s Accelerator article, A CIO framework for scaling Copilot agents—a CIO‑level perspective designed for when agent adoption begins to scale.

The framework explores:

What changes as agents move from pilots to enterprise capability
How leadership decisions evolve with scale
How to balance flexibility with coherence
How to guide growth before friction sets in

It’s framed for CIOs and senior IT leaders who are thinking beyond approving the next agent build, who are focusing now on aligning teams, expectations, and operating models at scale.

👉 Read the full framework on Microsoft 365 Accelerator

Discussion

What signals tell you it’s time to move from experimenting with agents to planning for scale?
Where does agent growth create the most tension in your organization today?
What’s the one decision you wish had been clearer earlier in your agent journey?

Microsoft 365 Accelerator is where planning conversations go deeper.
If your organization is moving from “can we build this?” to “how do we scale this responsibly?”, Accelerator is where you want to go next.

Copilot Chat in financial services: Is productivity moving faster than policy?

JulieHersum — Mon, 13 Apr 2026 16:49:44 GMT

In financial services, it's rarely the value of a new technology that slows down adoption. More often, it's when productivity starts to outpace the policies designed to govern it.

That tension is beginning to surface with Copilot Chat.

Teams are finding real efficiency gains—faster research, clearer summaries, better preparation—while leaders ask a different question:

What does responsible, repeatable adoption look like once usage expands across regulated roles?

Those conversations usually appear when Copilot Chat becomes operational enough that ad hoc decisions feel insufficient.

A new post on Microsoft 365 Accelerator is designed for that exact moment. How financial leaders are scaling Microsoft 365 Copilot Chat without increasing risk introduces a planning kit that shows financial services leaders how to scale Copilot Chat usage while keeping governance, audit readiness, and oversight intact.

Instead of features, the kit is focused on the decisions and guardrails that help organizations move forward and use Copilot Chat with confidence.

If you’re seeing strong demand from business teams and equally strong questions from risk or compliance teams, this kind of guidance brings those conversations together.

👉 Read the full planning guidance and explore the Copilot Chat kit on Microsoft 365 Accelerator.

We'd like to know:

At what point did Copilot Chat usage in your organization start raising governance or policy questions?
Which decisions felt easy during early experimentation but harder once Copilot Chat became more widely used?
How are you thinking about ownership and oversight as Copilot Chat moves beyond individual use cases?

Tell us in the comments below.

If this discussion feels familiar, you’re not alone. Microsoft 365 Accelerator is designed for the next phase—when teams start asking not just can we, but how do we do this well.

Modernizing On‑Prem File Servers: Azure Storage Mover and File Sync

SriniThumala — Sun, 08 Mar 2026 21:46:02 GMT

Azure File Sync is a hybrid cloud storage service that centralizes on-premises file shares into Azure Files while preserving the experience of a local Windows file server. It installs an agent on Windows Server(s) to cache and sync files to an Azure file share (the cloud backend). Key features include cloud tiering (keeping only hot files on-prem and tiering cold data to Azure) and multi-site synchronization, so changes propagate across servers via the cloud. In essence, Azure File Sync transforms your file server into a cache for Azure, providing continuous two-way sync between on-premises and the Azure file share.

Azure Storage Mover is a fully managed migration service used to transfer file data into Azure Storage (Azure Blob containers or Azure file shares) with minimal downtime. It works by deploying a migration agent near the source storage, which then copies data directly to Azure. The cloud-based Storage Mover resource orchestrates migrations (including initial bulk transfer and optional delta syncs for changes) across multiple shares from a central interface. Unlike File Sync, Storage Mover is not a continuous sync service but rather a one-directional data mover for scenarios like one-time migrations or periodic updates.

Side-by-Side Technical Comparison

Aspect	Azure File Sync	Azure Storage Mover
Primary Purpose	*Hybrid file service*: Ongoing two-way sync between on-prem file servers and Azure Files, enabling local caching and multi-site data sharing.	*Migration tool*: One-way transfers of file data from on-prem (or other storage) to Azure Storage, optimized for lift-and-shift migrations with minimal downtime.
Architecture	Agent on Windows Server connects local NTFS volumes to an Azure File Share (cloud endpoint). The Azure Storage Sync Service coordinates sync across servers in a sync group. Supports cloud tiering to offload cold files to cloud. Sync is continuous and multi-directional (all endpoints stay in sync).	Cloud service + on-prem agent: An Azure Storage Mover resource manages migration jobs. Lightweight migration agents (VMs or containers) run near your sources, sending data directly to the Azure target (Blob or File share). The service orchestrates project-based migrations but does not keep sources in sync after completion.
Supported Sources	Windows file servers (NTFS), accessed via SMB/NFS protocols (the agent needs Windows Server OS). Ideal for Windows-based file shares.	SMB shares, NFS exports, and similar file systems on any platform (Windows or Linux NAS). Also supports migrating from other clouds’ storage (e.g., S3 buckets) into Azure. Broad support for heterogeneous sources.
Supported Targets	Azure Files only. (Cloud endpoint is an Azure file share in a Storage Account). Supports SMB (and NFS 4.1 Azure file shares in preview) as target share types.	Azure Storage (Blob containers or Azure file shares). For example, can migrate into an Azure Blob (ADLS Gen2) container or an Azure File share depending on scenario.
Sync vs. Migration	Continuous Sync: Bi-directional; changes on-prem or in Azure propagate to all endpoints. Designed for long-term hybrid operation, not just a one-time move.	Batch Migration: One-time or repeated transfer; not a live sync. Typically used to move data entirely to Azure (cutover once done). Supports incremental (delta) syncs to capture changes between migration runs.
Performance & Scale	Scales to large datasets (tested up to 100 million files per sync group). Throughput can reach hundreds of files/sec for upload/download given sufficient resources. Performance depends on server hardware, network, and Azure Files limits.	Built to handle high-volume migrations (100M+ files). Can scale out by deploying multiple agents or using bigger VMs to increase throughput. Performance mainly limited by network bandwidth and source/target IOPS and can be optimized by parallel jobs and delta sync workflows.
Integration	Deep integration with Azure Files (the back-end store) and Windows Server. Works with Azure Backup for centralized backups or using file share snapshots. Leverages Azure’s redundancy (LRS/ZRS/GRS) for durability; supports Azure AD DS for identity integration to maintain ACLs in cloud.	Integrated with Azure Arc (for agent management) and can combine with Azure Data Box for hybrid migrations (offline + online phases). Managed using Azure Portal and CLI, provides logging/monitoring through Azure Monitor for migration jobs. No ongoing infrastructure after migration completes.

Advantages of Azure File Sync:

Hybrid Cloud Caching: Retains on-premises low-latency file access (via local Windows servers) while using Azure as central storage. End users and apps continue using a local file server interface.
Cloud Tiering & Storage Efficiency: Frees up local storage by tiering infrequently used files to Azure. This reduces on-prem disk usage without sacrificing access to full dataset (files are pulled from cloud on demand).
Multi-site Sync & Collaboration: Enables near-real-time sync across multiple servers/sites via Azure hub. Great for distributed teams sharing a common file set, replacing need for complex DFS-R setups or manual transfers.
Minimal Disruption Migration: Can be used as a no-downtime migration path to Azure Files – sync in background, then cut over clients to the Azure share with identical structure and ACLs.

Advantages of Azure Storage Mover:

Purpose-Built for Migration: Optimized for transferring data at scale into Azure. Can handle large one-time migrations or scheduled recurrent syncs without continuous agent overhead post-migration. Simplifies multi-terabyte or multi-site migration projects.
Heterogeneous Source Support: Works with a variety of source types (SMB, NFS shares on any OS) and can migrate into both Azure Files and Azure Blob, providing flexibility that Azure File Sync can’t (e.g., migrating Linux NFS servers or third-party storage to Azure).
Centralized Orchestration: Cloud architects can manage all migrations via a single Azure Storage Mover resource – with projects & jobs tracking progress per share. Logging, error handling, and coordination are unified, unlike scripting copy operations per server.
Incremental & Low Downtime: Supports delta synchronization to bring the target up-to-date after an initial bulk copy. This reduces cutover downtime since only last-minute changes need transferring. Also integrates with offline seeding (Data Box) plus online catch-up to minimize network strain and downtime.

Common Use Cases and When to Choose Each

Azure File Sync – Use Cases: Ideal when you need to maintain on-premises file server access while leveraging cloud storage. Some common scenarios:

Branch Office File Sharing: Multiple offices each have a local file server, all synced to a central Azure Files share. Users get fast local access, and the cloud ensures each site’s data stays consistent.
File Server Augmentation: You want to extend an existing Windows file server with virtually unlimited cloud capacity (via tiering) rather than fully moving to cloud. Azure File Sync offloads old data and provides cloud backup, but users and apps continue as normal with the local server.
Gradual Migration / Testing: You plan to eventually migrate to Azure Files but want a seamless, no-downtime transition. Deploy AFS on the server, let it sync all data to cloud, then optionally eliminate the on-prem server later. This way, users never stop accessing their files during the migration process.

Azure Storage Mover – Use Cases: Best when you have a defined migration project to move file shares to Azure, especially for heterogeneous environments or large volumes:

Data Center Exit / Large File Share Migration: Moving tens or hundreds of TBs of data from on-prem NAS or file servers to Azure Storage as a one-time project. The Storage Mover’s robust scalability and delta-sync capabilities help ensure a smooth transfer with minimal final cutover downtime.
Consolidating Cross-Platform Data to Azure: If you need to migrate non-Windows file systems (Linux NFS, etc.) or even data from other clouds into Azure, Storage Mover supports those sources out-of-the-box. For example, migrating a Linux file repository into Azure Blob for big data analytics.
Recurring Scheduled Migrations: In cases where you periodically copy data from on-prem to Azure (e.g., monthly exports from a local system to cloud for archiving), Storage Mover can be run as needed and centrally monitored, without maintaining a constant sync infrastructure in between.

Conclusion

When to choose which: Use Azure File Sync if your goal is to keep using on-prem servers and need a hybrid solution for the foreseeable future, or if you require distributed caching and continuous sync for collaboration. It’s essentially part of your production architecture for hybrid cloud file storage. Conversely, choose Azure Storage Mover when you want to permanently migrate data into Azure (and possibly decommission on-prem storage), or when dealing with a one-off bulk transfer task. In summary, Azure File Sync is an ongoing hybrid file service, and Azure Storage Mover is a one-time (or scheduled) migration service. Both can complement your cloud strategy, but they address distinct scenarios in a cloud architect’s toolkit.

Copilot adoption: Move your org from pilot to production with this guide

JulieHersum — Thu, 19 Feb 2026 20:32:15 GMT

Are you an IT admin or Copilot adoption lead ready to safely start or scale your rollout of Microsoft 365 Copilot?

Piecing together the right guidance can be something of a treasure hunt so we created a trusted, single starting point for you: 8 Copilot & agent hubs every adoption leader should bookmark.

This guide is organized around the typical adoption lifecycle (plan → build → operate) to help you accelerate your Copilot adoption without skipping governance.

Inside the guide, you’ll learn:

What each resource hub includes—and how each maps to plan → build → operate for Copilot.
How to turn guidance into motion: Practical steps you can reuse for rollout and change management (not just reference links).
Which resources to share with each audience—admins, champions, and business sponsors—so everyone stays aligned.
How to scale with confidence: Starting points. that support a governed, production-ready Copilot program

To get started, check out the full post and bookmark each resource hub today.

Did you know?

FastTrack helps eligible customers with Microsoft 365 Copilot adoption by providing expert guidance, self‑service resources, and structured engagements at no additional cost.

If your adoption program could use a boost, FastTrack can help.

Visit the Microsoft 365 Accelerator site for Copilot quickstart guides, governance templates, and adoption kits—or submit a request for personalized deployment and change management assistance (RFA) from FastTrack today.

The Copilot resource guide to share with your employees

JulieHersum — Thu, 19 Feb 2026 20:01:33 GMT

From customers driving Microsoft Copilot adoption, one request we hear a lot is: “Can you send me to a simple starting place?”

Now we can. Essential Copilot resource hubs for employees is a trusted, easy-to-share guide that rounds up key Microsoft-owned Copilot learning and support hubs. It's designed to help you speed up Copilot onboarding and get your employees building good habits from day one.

How to use it with end users

Adoption leaders: Use the hubs to structure learning paths (new user onboarding, prompting basics, role-based scenarios) and reinforce them in champions and community programs.
IT admins: Add a link to the guide in your rollout emails, intranet, and helpdesk macros so employees have a consistent “start here” link.
Everyone: Share this as one source of truth, then keep your internal guidance focused on what’s unique to your organization (policies, approved use cases, and where to get help).

For more information about this simple approach that scales, read the guide: Essential Copilot resource hubs for employees

Need help?

FastTrack helps eligible customers with Microsoft 365 Copilot adoption by providing expert guidance, self‑service resources, and structured engagements at no additional cost.

If your adoption program could use a boost, visit the Microsoft 365 Accelerator site for Copilot quickstart guides, governance templates, and adoption kits. Or, submit a request for personalized deployment and change management assistance (RFA) from FastTrack today.

Intermittent Delay in Loading Files Tab in Microsoft Teams Channels

dicknoort715 — Thu, 09 Oct 2025 13:20:31 GMT

Description:

Within our municipality, we are experiencing an intermittent issue where the Files tab in Microsoft Teams channels takes >5 seconds to load. This behavior appears to be random and is not tied to specific users, devices, or locations. We have conducted several internal checks and can confirm the following:

The issue occurs in both small and large Teams channels, regardless of the number of files or folders.
It affects various Surface laptops, so it does not appear to be device-specific.
It happens both inside and outside our municipal buildings, ruling out local network dependency.
We exclusively use Microsoft products, including Surface devices, Microsoft Defender, and Intune for device management.

We would like to know:

Is this a known issue within Microsoft Teams?
Are there specific tenant-level settings or Intune configurations that could influence the performance of the Files tab?
Are there any recommended diagnostics or optimizations we can apply to improve consistency?

We appreciate any guidance or insights you can provide.

Kind regards,
Dick Noort
Advisor Information Services

Ready to accelerate your Zero Trust journey? Discover what’s next

JulieHersum — Fri, 03 Oct 2025 16:40:32 GMT

For admins | 1-minute read

Zero Trust isn’t just a security buzzword—it’s the new baseline for protecting your organization in a world where threats are always evolving.

But what does it really take to move from strategy to action?

Find out by reading our recent blog, Accelerate your Zero Trust journey: Using the Microsoft Zero Trust workshop for impact on the M365 Accelerator site. In it, we break down some of the real-world challenges IT admins face and show how this hands-on workshop can help you build a clear roadmap forward.

For example, learn how you can use the workshop to:

Assess and improve your security posture by evaluating your organization’s current security maturity across six critical Zero Trust pillars (Identity, Devices, Data, Network, Infrastructure, Security Operations), identify gaps, and prioritize actions for improvement.

Drive cross-team alignment and executive buy-in by bringing together stakeholders from security, infrastructure, networking, and compliance for communication, consensus building, and creating a data-driven roadmap that resonates with leadership.

Turn security strategy into actionable results with practical steps for leveraging the Zero Trust Workshop to transform security from a reactive task into a proactive, strategic advantage for your organization.

Next steps

Ready to move beyond theory and see how Microsoft’s approach can help you secure identities, apps, and data?

Then Accelerate your Zero Trust journey is your next must-read.

Get the full story and workshop details here.

Governing Copilot agents: Your next step starts here

JulieHersum — Fri, 22 Aug 2025 23:42:47 GMT

For those of you navigating this shift, Rob Howard, Microsoft’s VP of Product Management for Microsoft 365 Copilot Extensibility, offers a practical governance framework in his article, What IT admins need to know about governing AI agents.

The article introduces three key governance pillars:

Security controls using Microsoft Purview.
Management controls through admin centers and deployment planning.
Agent reporting to monitor usage and stay ahead of compliance.

You’ll also get a first look at governance zones—a planning model to help segment Copilot deployment based on your organization’s risk tolerance and data sensitivity. Think sandbox, controlled, and trusted zones, with guidance on how to phase rollout.

What else you’ll find:

A checklist to assess your readiness.
Real-world examples of phased deployment.
Links to tools you already use, like Purview, Power Platform admin center, and Microsoft 365 admin center.
A preview of the upcoming white paper and webinar.

Next Steps

Ready to securely and strategically lead your organization into the future of AI?

Read Rob’s blog today for reliable advice on governing Copilot agents. It’s part of a broader initiative by FastTrack for Microsoft 365 to support IT admins with actionable, admin-relevant content on governing Copilot AI agents—so stay tuned for future articles, webinars, and more on the topic!

Bring AI out of the shadows with agents for Microsoft 365 Copilot Chat

JulieHersum — Mon, 30 Jun 2025 22:17:46 GMT

For IT admins and Microsoft 365 admins
7-minute read

Overview

Shadow AI is almost certainly happening across your organization—whether you can see it or not. Employees are using tools like ChatGPT and Notion AI to get work done, even without organizational knowledge or approval. This creates real risks like data leakage, compliance violations, and a lack of visibility into how employees are using artificial intelligence.

Fortunately, IT admins are in a unique position to fix the problem at its core.

Today's article is intended to be a practical playbook for helping IT admins lead the charge toward responsible AI use in their organizations by empowering secure, compliant, and easy-to-manage agents for Microsoft 365 Copilot Chat.

What is shadow AI?

Like shadow IT, the term ‘shadow AI’ exists for a reason: it refers to unsanctioned, often hidden, use of AI tools.

In the shadows, artificial intelligence can be hard to detect and even harder to govern. Tools can be browser-based, embedded in SaaS apps, or used on personal devices. Controls that mitigate shadow IT—like app blocking or firewall rules—don’t necessarily translate to AI use.

Both shadow IT and shadow AI involve technical and behavioral elements, however unauthorized use of AI presents deeper behavioral challenges beyond unauthorized tools. These challenges center around how users make decisions and potentially bypass governance in ways that are harder to detect and control.

While employees may not want to go rogue or bypass IT—and they generally don’t want to put the organization at risk—they do want to get their work done efficiently. They turn to public AI tools when they can’t find the capabilities they need inside the tools they have permission to use.

Agents for Microsoft 365 Copilot Chat give you a way to lead AI use into the light and meet your users’ needs with modern AI business tools. By building and deploying task-specific, data-grounded chat experiences that live inside Microsoft 365, users get fast, relevant answers they’re looking for without having to step into the shadows and leave the secure environment you manage.

These agents are part of the broader Microsoft 365 Copilot ecosystem and are designed to automate and execute business processes directly within Copilot Chat.

Should you ignore or even allow shadow AI?

When employees use public AI tools without oversight, they create risks that are harder to detect, harder to govern, and harder to reverse.

For IT admins, the stakes are high for operational, security, and technical risks:

Loss of visibility and control: You can’t protect what you can’t see.

- Shadow AI obscures oversight. It’s harder to track usage or enforce policies for tools used outside your environment.

- No centralized monitoring = no control. Without a unified view, you can’t troubleshoot issues, optimize usage, or step in when something goes wrong.
- Shadow data silos emerge. Generative AI content created outside your tenant isn’t retained or governed, which complicates lifecycle management, legal holds, and compliance requests.

Security and compliance risks

- Enterprise-grade protections are lacking. Most public AI tools don’t support conditional access, audit logs, or data loss prevention (DLP) policies, leaving you with blind spots and increased risk of data leaks.

- Sensitive data exposure. Employees may unknowingly input proprietary or regulated data into public models, risking violations of GDPR, HIPAA, or internal policies.
- Compliance gaps. If tools aren’t tracked or documented, they increase the burden of proving compliance and can become major liabilities during audits or regulatory reviews.

IT and governance challenges

- IT is out of the loop. Adoption of unauthorized AI tools sidelines IT, preventing teams from recommending secure, supported alternatives or aligning tools with organizational standards. When users go rogue with AI tools, they aren't using recommended secure, supported options that align with your environment and policies.
- Tool sprawl = more support tickets. Unapproved tools often lack integration with existing systems, creating support burdens and increasing the risk of misconfigurations.

Bottom line: Allowing or ignoring shadow AI will make it much harder to manage later. That’s why Copilot Chat agents, combined with strong governance and user education, are such a powerful response: they give you a way to meet end user demand without losing control.

What IT admins are up against

When it comes to eradicating rogue AI, admins have their work cut out for them. Here’s a summary table of how activating Copilot Chat agents at your organization can help stem the tide:

Unsanctioned AI use contributes to:	How to stem the problem:
Loss of visibility and control Employees use unsanctioned AI tools.	Reframe shadow AI as a signal Offer sanctioned tools that meet user needs and bring AI usage into the light.
Data governance gaps Unapproved tools bypass DLP and compliance policies.	Keep data in your tenant Copilot agents respect Microsoft 365 compliance, identity, and data boundaries.
Inconsistent AI use across teams Different tools create fragmented workflows.	Centralize AI access Deploy agents across Teams and Microsoft 365 to unify usage.
Security and compliance risks Shadow tools may not meet regulatory standards.	Use enterprise-grade protection Copilot agents are authenticated with Azure AD and governed by Microsoft Purview.
Lack of deployment clarity Admins may not know where to start.	Follow a clear blueprint This blog outlines steps for setup, governance, and scaling.
Missed innovation opportunities IT is seen as a blocker, not a partner.	Support safe innovation Let business units build AI chat agents with IT guardrails in place.

Copilot Chat agents remove the roadblocks to getting value from AI

Microsoft's chat agents aren’t just another AI tool—they’re designed to work the way IT works.

Secure by design: Agents run inside your Microsoft 365 tenant and authenticate through Azure AD.
Compliant by default: They respect DLP and audit policies and retention through Microsoft Purview.
Customizable and governable: You can define access, data sources, and usage policies.
Easy to deploy: Agents live inside Teams and Microsoft apps, so users don’t need to install anything new.

Copilot Chat agents strengthen governance

While Copilot for Microsoft 365 helps users work more efficiently inside apps like Word, Excel, and Teams, Copilot's AI agents go a step further. They give IT the ability to create task-specific, role-based, and data-grounded AI experiences that directly replace the kinds of tools employees might otherwise seek out on their own.

Key deployment benefits for IT admins

Benefit	Impact
Visibility	Know who’s using AI, how, and with what data.
Control	Define and enforce usage policies.
Compliance	Align AI use with regulatory standards.
Efficiency	Reduce support tickets with self-service agents.
Innovation	Empower business units without losing oversight.

Take the next step

Like shadow IT, you may not get rid of shadow AI completely or overnight. But you can meet it head-on with tools that work for your users and comply with your policies.

Start by deploying a few AI Chat agents in high-impact areas. Use the resources in this article to guide your rollout.

With Copilot Chat agents, you’re not just solving a technical problem. You’re leading your organization toward safer, smarter AI adoption.

Tools that make it easier

When it comes to Microsoft 365 deployments, you’re never alone. FastTrack for Microsoft 365 offers a full set of resources to help you learn about, build, manage, and instruct end users on Copilot Chat agents:

Credentialed access, sign in required:

Microsoft 365 advanced deployment guides and assistance
Microsoft 365 Copilot onboarding hub
Microsoft 365 Copilot: Quickstart, Copilot Chat licensing

Open access, no sign-in required:

Get started with Microsoft 365 Copilot extensibility
Microsoft 365 Copilot ADG: Streamlining your Copilot journey (video)
Copilot Chat Success Kit – Microsoft Adoption
Microsoft Copilot AI setup and usage guides
AI in business: Artificial intelligence tools & solutions (blog)
Request assistance from FastTrack

Deployment blueprint: Get started today

Remember: You don’t need to roll out everything at once. Start small, build momentum, and scale responsibly.

Here’s a blueprint that will get you to the finish line:

Copilot Chat agent deployment checklist

Step 1: Prepare your environment

☐ Set up Copilot Studio and review licensing.

☐ Create Power Platform environments that reflect your data boundaries and governance needs.

☐ Identify early declarative agent use cases (e.g., HR FAQs, IT help desk).

Note: Only declarative agents are currently supported in Copilot Chat. Agents that access tenant data (e.g., SharePoint, Graph) require pay-as-you-go billing.

Step 2: Define governance policies

☐ Use role-based access control (RBAC) to manage who can create, publish, and use agents.

☐ Apply naming conventions, approval workflows, and publishing guidelines.

☐ Set up guardrails for data access, agent behavior, and knowledge sources.

☐ Assign maker permissions via Microsoft Entra groups or Copilot Studio user licenses.

Step 3: Deploy and monitor

☐ Use the Microsoft admin center and Power Platform admin center to manage billing and access.

☐ Monitor usage with audit logs, analytics, and the Copilot Control System.

☐ Identify which teams are still using unauthorized AI tools and guide them toward approved Copilot agents.

Step 4: Support and scale

☐ Offer training, templates, and office hours to support agent creators and users.

☐ Establish a Center of Excellence (CoE) to share best practices and governance.

☐ Highlight successful use cases to drive adoption and build momentum.

☐ Encourage feedback loops to refine agent behavior and expand scenarios.

Shadow AI prevention checklist

What else should you do to discourage shadow AI? Here's a handy checklist of actions to take:

Data protection

☐ Apply Microsoft Purview DLP policies to monitor and restrict sensitive data.

☐ Use sensitivity labels and encryption to protect data at rest and in transit.

☐ Set up conditional access policies to limit AI tool usage by role, device, or location.

Acceptable use

☐ Publish clear guidance on approved AI tools and data usage.

☐ Include AI-specific clauses in acceptable use and security policies.

☐ Reinforce policies through onboarding, training, and regular reminders.

Monitoring and detection

☐ Use Microsoft Defender for Cloud Apps (MCAS) to detect unsanctioned AI usage.

☐ Analyze browser traffic and app usage patterns for high-risk behavior.

☐ Set up alerts for uploads to known AI endpoints (e.g., ChatGPT, Claude).

Education and empowerment

☐ Run awareness campaigns about shadow AI risks and approved alternatives.

☐ Offer training on how to use Copilot and Copilot Chat agents effectively.

☐ Create a feedback loop for users to request new AI capabilities.

Internal partnerships

☐ Collaborate with HR, legal, and other teams to understand AI needs.

☐ Support business units in building Copilot Chat agents with IT oversight.

☐ Use shadow AI behavior as a signal for unmet needs and prioritize accordingly.

Governance alignment

☐ Align Copilot deployment with your organization’s responsible AI principles.

☐ Document how Copilot Chat agents support ethical and regulatory standards.

☐ Use audit logs and analytics to support transparency and accountability.

Driving adoption and measuring impact with the Microsoft 365 Copilot Dashboard

JulieHersum — Thu, 29 May 2025 18:35:37 GMT

Since 2023, nearly 70% of Fortune 500 companies have integrated Microsoft 365 Copilot’s advanced AI into their daily workflows, unlocking new efficiencies and streamlining collaboration—and they’re seeing measurable business impact.

For example, Vodafone discovered employees who use Copilot save an average of 3 hours per week, reclaiming 10% of their workweek. Lumen Technologies estimates that using Copilot will help their sales teams save $50 million per year.

These are game-changing outcomes. But how do these companies know their numbers are accurate? And how did they achieve them? The key to maximizing the value of AI-driven productivity tools is more than simply licensing your end users and waiting for them to make the most of it. In fact, the key lies in measuring its impact.

To drive meaningful adoption and maximize ROI with Microsoft 365 Copilot, organizational leaders need clear visibility into how their workforces are using it. This means understanding:

Who’s adopting AI with Copilot.
How effectively is Copilot supporting workflows.
What measurable productivity gains are users achieving.

In this article, business leaders and IT can learn more about the Microsoft 365 Copilot dashboard, including its key features and core metrics.

We'll also go over IT's tasks for configuring the dashboard and granting access to business leaders so they can analyze Copilot usage patterns themselves, refine their Copilot engagement strategies, and help drive productivity gains in their teams and throughout the organization.

What is the Copilot Dashboard?

The Microsoft Copilot Dashboard is a tool in Viva Insights that helps IT, business leaders, change managers, and other non-technical stakeholders track usage of Microsoft 365 Copilot with practical insights they can use to:

Prepare users to work effectively with AI
Drive Copilot adoption across teams
Measure impact on workplace behavior

Key features and core metrics of the Copilot Dashboard

With a Viva Insights license, your unlock advanced dashboard features, including:

Comprehensive Metrics

A 28-day aggregated view of Copilot usage, adoption, readiness, and impact, to help you understand engagement and Copilot business value.

Readiness tracking

Based on Microsoft 365 app usage patterns, these metrics can help you identify which teams are ready to adopt AI into their daily workflows and which may need additional support, training or upskilling.

Adoption insights

With adoption insights, dashboard users can track active Copilot usage patterns within each Microsoft 365 app to measure how effectively teams are integrating Copilot into workflows. They can also pinpoint areas where Copilot users may need training or support to maximize productivity. By default, the dashboard’s Adoption trendline shows the prior six-month trend for all users in the organization. You can adjust filters at the top of the page for specific groups.

Impact analysis

This insight allows you to analyze how often employees in your organization use Copilot during a specified time period. Leaders can also measure productivity gains through metrics like meeting efficiency, email usage, and document collaboration.

Advanced tools, such as before-and-after behavioral data and employee surveys, can reveal early and even deeper insights into Copilot’s organizational impact.

Learning opportunities

Use qualitative feedback data from Copilot impact pulse surveys to identify Copilot satisfaction levels, challenges, and areas for improvement.

For example, you can compare high-adoption teams with low-adoption ones to uncover training or awareness gaps.

Managing the Copilot Dashboard: Key admin responsibilities

Global admins play a critical role in configuring and managing the Copilot Dashboard.

Their roles include:

Setting up and configuring the Copilot Dashboard.
Granting access and supporting business stakeholders.
Integrating data.

1. Setting up and configuring the Microsoft 365 Copilot Dashboard

Global IT admins are responsible for setting up and configuring the Copilot Dashboard to align with organizational goals and requirements. This includes managing settings and turning features on and off as needed.

2. Granting access and supporting business stakeholders

Admins, you'll also need to assign permissions to specific leaders, stakeholders, or groups through the Microsoft 365 admin center or PowerShell. Make sure stakeholders in different roles have the correct permissions.

You'll also play a critical role in supporting and troubleshooting issues that users might encounter, such as technical problems and related assistance.

Who should have access to the Copilot Dashboard?

Business leaders

You can view engagement and adoption metrics directly and make informed decisions about how best to guide users on adopting Copilot.

Department heads

You'll want to monitor how your teams are using Copilot and identify areas for improvement.

IT managers

You'll need to oversee the technical aspects of Copilot deployment and ensure smooth operations.

HR Managers

Track employee sentiment and impact metrics for workforce planning and development.

How do admins grant access to the Copilot Dashboard?

You can delegate and manage access for individuals or groups to the dashboard in two different ways:

1. The Microsoft 365 admin center

Access the Copilot Dashboard here or
Sign in to Microsoft 365 admin center
Navigate to the Settings tab
Select Setup
Go to the Copilot Dashboard to Manage access settings. From there you can search for and select users to grant or revoke access.

Manage access for groups by selecting the Groups option, searching for Entra ID groups, and adding or removing users as needed.

2. PowerShell

Viva Insights admins can delegate access to organizational insights and the Copilot Dashboard using PowerShell.

Set policies to enable or disable access to the dashboard at the tenant level using PowerShell cmdlets. This method gives you more granular control. Use it to manage access for larger groups or the entire organization.

Note: You can only delegate access to users with a Viva Insights license. Viva Insights is available as part of the Microsoft Viva Suite or as a standalone add-on to Microsoft 365 enterprise plans.

How do business stakeholders access the Copilot Dashboard?

Business stakeholders, you can access the Microsoft 365 Copilot Dashboard through your Teams Viva Insights app.

3. Integrating organizational data into the dashboard

Admins will upload organizational data directly through the admin center and configure it for analysis. If both the Viva Insights admin and the Global admin upload data, the dashboard will merge these uploads and display insights based on the most recent data.

Empowering business stakeholders with insights they can act on

Microsoft 365 Copilot is transforming productivity, and metrics powered by Viva Insights are proving its impact to the world.

Access the Copilot Dashboard today for yourself and unlock Copilot’s full potential for driving organizational success.

Learn more

For more information on connecting to the Copilot Dashboard for Microsoft 365 customers, watch our recent video, AI Transformation: Maximize the value of Copilot with Copilot Dashboard and check out our article: Connect to the Microsoft Copilot Dashboard for Microsoft 365 customers | Microsoft Learn.

Need more assistance? FastTrack is here to help!

FastTrack is available to support customers with eligible licenses. Request assistance from FastTrack today or contact your assigned FastTrack Architect (FTA).

Azure Firewall and Service Endpoints

cloudtrooper — Mon, 14 Apr 2025 11:48:33 GMT

In my recent blog series Private Link reality bites I briefly mentioned the possibility of inspecting Service Endpoints with Azure Firewall, and many have asked for more details on that configuration. Here we go!

First things first: what the heck am I talking about? Most Azure services such as Azure Storage, Azure SQL and many others can be accessed directly over the public Internet. However, there are two alternatives to access those services over Microsoft's backbone: Private Link and VNet Service Endpoints. Microsoft's overall recommendation is using private link, but some organizations prefer leveraging service endpoints. Feel free to read this post on a comparison of the two.

You might want to inspect traffic to Azure services with network firewalls, even if that traffic is leveraging service endpoints. Before doing so, please consider that sending high-bandwidth traffic through a firewall might have cost implications and impact on the overall application latency. If you still want to go ahead, this post is going to explain how to do it.

The Design

Service endpoints have two configuration parts:

Source subnet configuration to tunnel traffic to the destination service.
Destination service configuration to accept traffic from the source subnet.

The key concept to understand is that if traffic from the client is going to be inspected by a firewall before going to the Azure service, then the source subnet is actually the Azure Firewall's subnet, not the original client's subnet:

You can configure service endpoints for a specific Azure service on a subnet using the portal, Terraform, Bicep, PowerShell or the Azure CLI. In the portal this is what it looks like:

For Azure CLI, enabling service endpoints for Azure Storage accounts in all regions would look like this:

❯ subnet_name=AzureFirewallSubnet
❯ az network vnet subnet update -n $subnet_name --vnet-name $vnet_name -g $rg --service-endpoints Microsoft.Storage.Global -o none --only-show-errors

You would then configure your Azure services to accept traffic coming from the Azure Firewall subnet. For example, for Azure Storage Accounts this is what you would see in the portal:

Network Rules or Application Rules?

Ideally you should use Application Rules in your firewall to make sure that your workloads are accessing the right Azure services, and not exfiltrating data to rogue data services that might be owned by somebody else and still could have the same IP address.

This is an example of a star rule granting access to all Azure Storage Accounts, but you should specify your own:

I tested with two storage accounts, one in the same region and another one in a different region than the client (the client being in this case the Azure Firewall). Access to both storage accounts is working, and as you can see both accesses are logged in the Storage Account as well as in the Azure Firewall (I have removed some characters from the storage account names to obfuscate them):

❯ ssh $vm_pip "curl -s4 $storage_blob_fqdn1"
Hello world! 
❯ ssh $vm_pip "curl -s4 $storage_blob_fqdn2"
Hello world!
❯ query='StorageBlobLogs | where TimeGenerated > ago(15m) | project AccountName, StatusCode, CallerIpAddress'
❯ az monitor log-analytics query -w $logws_customerid --analytics-query $query -o table
AccountName              CallerIpAddress     StatusCode  
----------------------   -----------------   ----------
storagetest????eastus2   10.13.76.72:10066   200
storagetest????westus2   10.13.76.72:11880   200
❯ query='AzureDiagnostics | where TimeGenerated > ago(15m) | where Category == "AZFWApplicationRule" | project SourceIP, Fqdn_s, Protocol_s, Action_s' 
❯ az monitor log-analytics query -w $logws_customerid --analytics-query $query -o table 
Action_s  Fqdn_s                                       Protocol_s SourceIP
--------- -------------------------------------------- ---------- ----------
Allow     storagetest????eastus2.blob.core.windows.net HTTPS      10.13.76.4 
Allow     storagetest????westus2.blob.core.windows.net HTTPS      10.13.76.4

The storage account sees as client IP the Azure Firewall's IP (in the subnet 10.13.76.64/26), and the Azure Firewall logs show the actual client IP (in the workload subnet 10.13.76.0/26).

If you use network rules you would lose a lot of the flexibility of the Azure Firewall, even if using FQDN-based rules. The reason is that if there were 2 storage accounts with different FQDNs sharing the same IP address, and the same client resolves both FQDNs, when Azure Firewall looks at the packet it will not be able to guess to which storage account each specific packet belongs to. From a routing perspective it would still work though, as long as you have the default SNAT settings of Azure Firewall, which involves translating the IP address when public IP addresses are involved:

Conclusion

There are some reasons why you might want to pick VNet service endpoints over private link (cost would probably be one of them). If so, there are advantages and disadvantages of sending traffic to Azure services via a firewall. If you decide to inspect traffic to VNet service endpoints with Azure Firewall, hopefully this post has shown you how to do that.

What are your thoughts about this?