Security Review for Microsoft Edge version 150
We have reviewed the new settings in Microsoft Edge version 150 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 139 security baseline continues to be our recommended configuration which can be downloaded from the Microsoft Security Compliance Toolkit. Microsoft Edge version 150 introduced 8 new Computer and User settings; we have included a spreadsheet listing the new settings to make it easier for you to find. As a friendly reminder, all available settings for Microsoft Edge are documented here, and all available settings for Microsoft Edge Update are documented here. Please continue to give us feedback through the Security Baselines Discussion site or this post.
Blocked by Runs on Trust — Ref 715-123160, no workspace created
Enrollment blocked with: "Microsoft runs on trust. We engage in a rigorous set of evaluation and certification processes; as a result your request was blocked." Reference number: 715-123160 Transaction ID: 9bf03e8b-5d2a-4ce3-a00e-325c84188bb3 Correlation ID: eaf15fab-ace6-43d2-a2cc-d40c00106c23 No Partner Center workspace was created, so I can't raise a standard support ticket. Requesting escalation to the Vetting/Trust & Safety team for manual review.Speed where it matters: How Microsoft Intune helps IT prioritize time-sensitive actions
By: Albert Cabello Serrano | Principal Product Manager - Microsoft Intune A closer look at how Intune delivers updates to devices and the investments we’re making to help important changes move faster and more predictably. A common concern we hear from IT admins is, “How quickly will this change actually reach my device?” In many cases, the answer is much faster than expected. Today, 90% of policy updates, app deployments, and device actions in Intune are completed in under an hour. So where does the idea of “8-hour latency” come from? That number reflects a routine maintenance check-in used when devices are idle - not how Intune processes meaningful changes. Intune uses notification-based, priority-driven processing so that high-impact actions, like security policy changes or remediation steps, are handled promptly and reliably as possible. In this context, latency isn’t about making every action instant - it’s about providing predictable, prioritized delivery at global scale. The sections below break down how Intune prioritizes different types of updates and recent investments that are helping time-sensitive changes complete more consistently. How Intune delivers changes to devices Cloud-based device management is designed for real-world conditions; devices are not always online, fully charged, or on stable networks. Intune uses an eventual consistency model so devices can continue to be productive while converging to the desired state over time, without management actions unnecessarily disrupting users or workflows. Because devices operate in different conditions, not all device activity is handled the same way. To manage change reliably at scale, Intune uses different types of device check-ins depending on what needs to happen. Types of device check-ins in Intune Device check-ins generally fall into several categories, each triggered by a different type of action: Single‑device check‑ins: Occurs when an admin or user initiates an action on a specific device, such as starting a device action or installing an app from the Intune Company Portal. Change‑based check‑ins: Push‑triggered check‑ins used to deliver meaningful changes to devices as soon as possible. Client‑initiated check‑ins: Background activity that helps keep devices healthy, such as when a user signs in to a device or when malware status changes. Maintenance check-ins: Scheduled syncs that occur at predetermined intervals and can be client or service-initiated, depending on the platform. These typically occur approximately every 8 hours. Regardless of what triggers a check-in, any pending changes will be applied to the device when it occurs. What happens when an admin makes a change When an admin makes a change in Intune, such as updating a device compliance policy, deploying an app, or setting a configuration, Intune identifies the devices impacted by that change and initiates a change‑based check‑in for affected devices. For online devices, Intune sends a push notification prompting the device to establish a management session with the service, apply the change, and report enforcement status back to Intune. If a device is offline or unreachable, the change is applied when the device next checks in through available mechanisms. Four investments that help critical updates move forward faster The following product changes focus on reducing device‑change latency by shortening the time between an admin action in Intune and enforcement on the device, especially during peak or constrained conditions. 1. Check-in prioritization focused on what matters most Not all device activity carries the same urgency. Routine background check-ins can compete for service resources with devices that have important pending changes, such as compliance updates, remediation actions, or administrator-initiated configuration changes. Intune evaluates the potential impact of delaying a device check-in on security posture, compliance state or user productivity, and dynamically prioritizes processing accordingly. This real-time prioritization model ensures that high-impact actions move forward without being delayed by lower‑impact background activity. Prioritization adapts as conditions change, helping important updates reach devices more quickly and predictably without being delayed by lower-impact background activity. 2. Built-in resilience when multiple changes occur in quick succession Change activity often happens in bursts, with several related updates occurring in rapid succession. These periods of activity may be driven by operational needs or background processes, and can involve adjusting assignments, updating multiple policies, or rolling out configuration changes across the same set of devices. Intune dynamically coordinates notifications, so that each change requiring action triggers a corresponding device notification, even during high-activity periods. This helps improve consistency when applying multiple updates and reduces delays across consecutive changes on devices. Over the next several months, these improvements will extend to additional payloads delivered through the Intune Management Extension (IME), including scripts, Win32 apps, and custom compliance across both Windows and macOS platforms. 3. More timely notifications on Windows Intune notifies devices to check-in when changes require action. If the device is offline, on an unstable network, or low on battery, notifications may be delayed. This can cause missed check-ins or delayed actions. When notification services are delayed, blocked, or unavailable, devices may fall back to scheduled maintenance check‑ins to apply changes. For timely delivery, required notification service endpoints need to remain accessible so devices can receive management signals when updates occur. On Windows devices, Intune complements the Windows Notification Service (WNS) with the same notification protocol that powers Microsoft Teams via the Intune Management Extension. This helps increase the likelihood that devices receive management notifications when they’re online and reachable, improving visibility into whether policy updates or device actions have reached their destination. For more information, see the network endpoints for Intune documentation. 4. Optimized maintenance check-ins for iOS devices Background check-ins are still important to keep devices healthy when nothing else is going on. Unlike Windows devices, iOS devices don’t have client scheduled check‑ins and depend on service‑initiated maintenance check‑ins to ensure device health and compliance. During peak usage periods, these maintenance check‑ins can account for a significant portion of overall traffic, which can compete with devices that require immediate updates. Intune considers device activity in the scheduling of maintenance check‑ins during peak activity, making room for higher‑impact updates, while continuing to ensure devices check in regularly. This helps manage traffic and improves responsiveness when applying policies or remediation actions. What this means for you For IT admins: No additional configuration or workflow changes are required to benefit from Intune’s built-in notification system. When bidirectional communication with notification service endpoints is open, devices can receive and act on updates as they become available. For security teams: Faster delivery of device changes helps shorten the time between a policy update, a tightened Conditional Access rule, an updated compliance baseline, and a remediation action. For Zero Trust frameworks, where posture signals drive access decisions, this helps narrow the window during which a device could be out of compliance or vulnerable. Together, these improvements reflect how Intune is evolving into a more intelligent, priority-aware system. Rather than making every action instant, the focus is on prioritizing high-impact updates so they are delivered without unnecessary delays. This approach is expanding across a number of scenarios to provide a more consistent and predictable experience, helping reduce delays for key updates. Resources to learn more For another perspective on this topic, read an MVP’s take on demystifying the “8-hour” timing myth in this LinkedIn post. You can also watch the recent Tech Takeoff about this same topic to learn more about these improvements. Also, in the April edition of the What's New in Intune blog, we introduced a new segment called Myth vs. Reality. This post is part of that series. To stay current on new capabilities and updates as they ship, follow the What's New in Microsoft Intune blog. What myth should we debunk next? Leave a comment below or reach out to us on X @IntuneSuppTeam or @MSIntune.
Authorization and Governance for AI Agents: Runtime Authorization Beyond Identity at Scale
Designing Authorization‑Aware AI Agents at Scale Enforcing Runtime RBAC + ABAC with Approval Injection (JIT) Microsoft Entra Agent Identity enables organizations to govern and manage AI agent identities in Copilot Studio, improving visibility and identity-level control. However, as enterprises deploy multiple autonomous AI agents, identity and OAuth permissions alone cannot answer a more critical question: “Should this action be executed now, by this agent, for this user, under the current business and regulatory context?” This post introduces a reusable Authorization Fabric—combining a Policy Enforcement Point (PEP) and Policy Decision Point (PDP)—implemented as a Microsoft Entra‑protected endpoint using Azure Functions/App Service authentication. Every AI agent (Copilot Studio or AI Foundry/Semantic Kernel) calls this fabric before tool execution, receiving a deterministic runtime decision: ALLOW / DENY / REQUIRE_APPROVAL / MASK Who this is for Anyone building AI agents (Copilot Studio, AI Foundry/Semantic Kernel) that call tools, workflows, or APIs Organizations scaling to multiple agents and needing consistent runtime controls Teams operating in regulated or security‑sensitive environments, where decisions must be deterministic and auditable Why a V2? Identity is necessary—runtime authorization is missing Entra Agent Identity (preview) integrates Copilot Studio agents with Microsoft Entra so that newly created agents automatically get an Entra agent identity, manageable in the Entra admin center, and identity activity is logged in Entra. That solves who the agent is and improves identity governance visibility. But multi-agent deployments introduce a new risk class: Autonomous execution sprawl — many agents, operating with delegated privileges, invoking the same backends independently. OAuth and API permissions answer “can the agent call this API?” They do not answer “should the agent execute this action under business policy, compliance constraints, data boundaries, and approval thresholds?” This is where a runtime authorization decision plane becomes essential. The pattern: Microsoft Entra‑Protected Authorization Fabric (PEP + PDP) Instead of embedding RBAC logic independently inside every agent, use a shared fabric: PEP (Policy Enforcement Point): Gatekeeper invoked before any tool/action PDP (Policy Decision Point): Evaluates RBAC + ABAC + approval policies Decision output: ALLOW / DENY / REQUIRE_APPROVAL / MASK This Authorization Fabric functions as a shared enterprise control plane, decoupling authorization logic from individual agents and enforcing policies consistently across all autonomous execution paths. Architecture (POC reference architecture) Use a single runtime decision plane that sits between agents and tools. What’s important here Every agent (Copilot Studio or AI Foundry/SK) calls the Authorization Fabric API first The fabric is a protected endpoint (Microsoft Entra‑protected endpoint required) Tools (Graph/ERP/CRM/custom APIs) are invoked only after an ALLOW decision (or approval) Trust boundaries enforced by this architecture Agents never call business tools directly without a prior authorization decision The Authorization Fabric validates caller identity via Microsoft Entra Authorization decisions are centralized, consistent, and auditable Approval workflows act as a runtime “break-glass” control for high-impact actions This ensures identity, intent, and execution are independently enforced, rather than implicitly trusted. Runtime flow (Decision → Approval → Execution) Here is the runtime sequence as a simple flow (you can keep your Mermaid diagram too). ```mermaid flowchart TD START(["START"]) --> S1["[1] User Request"] S1 --> S2["[2] Agent Extracts Intent\n(action, resource, attributes)"] S2 --> S3["[3] Call /authorize\n(Entra protected)"] S3 --> S4 subgraph S4["[4] PDP Evaluation"] ABAC["ABAC: Tenant · Region · Data Sensitivity"] RBAC["RBAC: Entitlement Check"] Threshold["Approval Threshold"] ABAC --> RBAC --> Threshold end S4 --> Decision{"[5] Decision?"} Decision -->|"ALLOW"| Exec["Execute Tool / API"] Decision -->|"MASK"| Masked["Execute with Masked Data"] Decision -->|"DENY"| Block["Block Request"] Decision -->|"REQUIRE_APPROVAL"| Approve{"[6] Approval Flow"} Approve -->|"Approved"| Exec Approve -->|"Rejected"| Block Exec --> Audit["[7] Audit & Telemetry"] Masked --> Audit Block --> Audit Audit --> ENDNODE(["END"]) style START fill:#4A90D9,stroke:#333,color:#fff style ENDNODE fill:#4A90D9,stroke:#333,color:#fff style S1 fill:#5B5FC7,stroke:#333,color:#fff style S2 fill:#5B5FC7,stroke:#333,color:#fff style S3 fill:#E8A838,stroke:#333,color:#fff style S4 fill:#FFF3E0,stroke:#E8A838,stroke-width:2px style ABAC fill:#FCE4B2,stroke:#999 style RBAC fill:#FCE4B2,stroke:#999 style Threshold fill:#FCE4B2,stroke:#999 style Decision fill:#fff,stroke:#333 style Exec fill:#2ECC71,stroke:#333,color:#fff style Masked fill:#27AE60,stroke:#333,color:#fff style Block fill:#C0392B,stroke:#333,color:#fff style Approve fill:#F39C12,stroke:#333,color:#fff style Audit fill:#3498DB,stroke:#333,color:#fff ``` Design principle: No tool execution occurs until the Authorization Fabric returns ALLOW or REQUIRE_APPROVAL is satisfied via an approval workflow. Where Power Automate fits (important for readers) In most Copilot Studio implementations, Agents calls Power Automate (agent flows), is the practical integration layer that calls enterprise services and APIs. Copilot Studio supports “agent flows” as a way to extend agent capabilities with low-code workflows. For this pattern, Power Automate typically: acquires/uses the right identity context for the call (depending on your tenant setup), and calls the /authorize endpoint of the Authorization Fabric, returns the decision payload to the agent for branching. Copilot Studio also supports calling REST endpoints directly using the HTTP Request node, including passing headers such as Authorization: Bearer <token>. Protected endpoint only: Securing the Authorization Fabric with Microsoft Entra For this V2 pattern, the Authorization Fabric must be protected using Microsoft Entra‑protected endpoint on Azure Functions/App Service (built‑in auth). Microsoft Learn provides the configuration guidance for enabling Microsoft Entra as the authentication provider for Azure App Service / Azure Functions. Step 1 — Create the Authorization Fabric API (Azure Function) Expose an authorization endpoint: HTTP Step 2 — Enable Microsoft Entra‑protected endpoint on the Function App In Azure Portal: Function App → Authentication Add identity provider → Microsoft Choose Workforce configuration (enterprise tenant) Set Require authentication for all requests This ensures the Authorization Fabric is not callable without a valid Entra token. Step 3 — Optional hardening (recommended) Depending on enterprise posture, layer: IP restrictions / Private endpoints APIM in front of the Function for rate limiting, request normalization, centralized logging (For a POC, keep it minimal—add hardening incrementally.) Externalizing policy (so governance scales) To make this pattern reusable across multiple agents, policies should not be hardcoded inside each agent. Instead, store policy definitions in a central policy store such as Cosmos DB (or equivalent configuration store), and have the PDP load/evaluate policies at runtime. Why this matters: Policy changes apply across all agents instantly (no agent republish) Central governance + versioning + rollback becomes possible Audit and reporting become consistent across environments (For the POC, a single JSON document per policy pack in Cosmos DB is sufficient. For production, add versioning and staged rollout.) Store one PolicyPack JSON document per environment (dev/test/prod). Include version, effectiveFrom, priority for safe rollout/rollback. Minimal decision contract (standard request / response) To keep the fabric reusable across agents, standardize the request payload. Request payload (example) Decision response (deterministic) Example scenario (1 minute to understand) Scenario: A user asks a Finance agent to create a Purchase Order for 70,000. Even if the user has API permission and the agent can technically call the ERP API, runtime policy should return: REQUIRE_APPROVAL (threshold exceeded) trigger an approval workflow execute only after approval is granted This is the difference between API access and authorized business execution. Sample Policy Model (RBAC + ABAC + Approval) This POC policy model intentionally stays simple while demonstrating both coarse and fine-grained governance. 1) Coarse‑grained RBAC (roles → actions) FinanceAnalyst CreatePO up to 50,000 ViewVendor FinanceManager CreatePO up to 100,000 and/or approve higher spend 2) Fine‑grained ABAC (conditions at runtime) ABAC evaluates context such as region, classification, tenant boundary, and risk: 3) Approval injection (Agent‑level JIT execution) For higher-risk/high-impact actions, the fabric returns REQUIRE_APPROVAL rather than hard deny (when appropriate): How policies should be evaluated (deterministic order) To ensure predictable and auditable behavior, evaluate in a deterministic order: Tenant isolation & residency (ABAC hard deny first) Classification rules (deny or mask) RBAC entitlement validation Threshold/risk evaluation Approval injection (JIT step-up) This prevents approval workflows from bypassing foundational security boundaries such as tenant isolation or data sovereignty. Copilot Studio integration (enforcing runtime authorization) Copilot Studio can call external REST APIs using the HTTP Request node, including passing headers such as Authorization: Bearer <token> and binding response schema for branching logic. Copilot Studio also supports using flows with agents (“agent flows”) to extend capabilities and orchestrate actions. Option A (Recommended): Copilot Studio → Agent Flow (Power Automate) → Authorization Fabric Why: Flows are a practical place to handle token acquisition patterns, approval orchestration, and standardized logging. Topic flow: Extract user intent + parameters Call an agent flow that: calls /authorize returns decision payload Branch in the topic: If ALLOW → proceed to tool call If REQUIRE_APPROVAL → trigger approval flow; proceed only if approved If DENY → stop and explain policy reason Important: Tool execution must never be reachable through an alternate topic path that bypasses the authorization check. Option B: Direct HTTP Request node to Authorization Fabric Use the Send HTTP request node to call the authorization endpoint and branch using the response schema. This approach is clean, but token acquisition and secure secretless authentication are often simpler when handled via a managed integration layer (flow + connector). AI Foundry / Semantic Kernel integration (tool invocation gate) For Foundry/SK agents, the integration point is before tool execution. Semantic Kernel supports Azure AI agent patterns and tool integration, making it a natural place to enforce a pre-tool authorization check. Pseudo-pattern: Agent extracts intent + context Calls Authorization Fabric Enforces decision Executes tool only when allowed (or after approval) Telemetry & audit (what Security Architects will ask for) Even the best policy engine is incomplete without audit trails. At minimum, log: agentId, userUPN, action, resource decision + reason + policyIds approval outcome (if any) correlationId for downstream tool execution Why it matters: you now have a defensible answer to: “Why did an autonomous agent execute this action?” Security signal bonus: Denials, unusual approval rates, and repeated policy mismatches can also indicate prompt injection attempts, mis-scoped agents, or governance drift. What this enables (and why it scales) With a shared Authorization Fabric: Avoid duplicating authorization logic across agents Standardize decisions across Copilot Studio + Foundry agents Update governance once (policy change) and apply everywhere Make autonomy safer without blocking productivity Closing: Identity gets you who. Runtime authorization gets you whether/when/how. Copilot Studio can automatically create Entra agent identities (preview), improving identity governance and visibility for agents. But safe autonomy requires a runtime decision plane. Securing that plane as an Entra-protected endpoint is foundational for enterprise deployments. In enterprise environments, autonomous execution without runtime authorization is equivalent to privileged access without PIM—powerful, fast, and operationally risky.
MCPP application closed at Identity Verification - the verification request was never issued
Posting in case others have hit this, and hoping someone from the compliance team can advise. Our MCPP enrollment was rejected with the standard message - "your organization does not currently meet the requirements to pass verification. There are no appeals available, we have closed your application." No reason was given, and the Partner Center AI assistant could not retrieve one either. What makes this look like a stuck state rather than a decision: The pipeline halted at Identity Verification. Verification Started and Email Verification both completed. Identity Verification failed. Employment Verification and Business Verification were never reached. We were never prompted to complete identity verification - no email to the primary contact, and no in-product prompt, at any point before the rejection. No control to obtain or present a Verified Credential exists on the account. The documentation says you use a Resolve or "Get verified here through our trusted ID-verifier" link and then present the credential by scanning a QR code. We inspected the rendered page directly: none of those elements are present - not hidden by styling, not inside an iframe, not in shadow DOM. The Verification Summary is marked view-only. The path /organization/required-verification returns not-found on both the /dashboard/v2/ and /dashboard/account/v3/ routes. Our Verification Summary renders in the legacy layout (steps in a horizontal row), so the Supplemental Documents area from the updated experience does not exist for us either. There is no route to upload documents. Timing: submitted on a Saturday, rejected by Monday - across a weekend, against a documented 3-5 business day review. No document had been submitted, so there was nothing to review. Every input we can verify is consistent. Legal name, address and registration number match our formation documents and IRS letter exactly. The Entra ID user's display name, first name and last name match the Partner Center primary contact exactly. The primary contact is an individual work address on our own verified domain, not a free or group mailbox. The primary contact holds a valid, non-expired government ID matching the account name, with Microsoft Authenticator installed. Questions: Has anyone had a closed application reopened, and what actually worked? 2. Is there a way to have an account moved from the legacy Verification Summary to the updated experience? That alone would expose both the Verified Credential control and the document upload area. 3. Where the identity verification request appears never to have been issued, is re-issuing it something support can do - or does it strictly require a new application? 4. If reapplying is the only path, does the rejection attach to the submission or to the tenant? We have a full Microsoft 365 environment and a verified domain on this tenant and need to know before doing anything. A support case is open. Happy to provide Partner IDs and tenant ID by private message. Thanks in advance.
MAICPP enrollment blocked (Ref 715-123160) – no workspace, requesting manual Vetting review
Hello Partner Compliance / Trust & Safety team, My enrollment in the Microsoft AI Cloud Partner Program was blocked by the automated trust check immediately after I submitted my company information ("Microsoft runs on trust ... your request was blocked"). Since the block happens at the trust-verification stage, no Partner Center workspace is created, so the standard in-portal support ticket cannot be raised (empty Workspace dropdown, Contact Support dead-ends). I would therefore appreciate a manual escalation. Request: Please route this to the Partner Vetting / Trust & Safety team for a manual review and reset so I can complete verification. If possible, let me know which validation step triggered the block so I can correct it before re-attempting. Case identifiers: - Program: Microsoft AI Cloud Partner Program - Reference number: 715-123160 - Transaction ID: e97d58e3-c28c-41c4-a635-8f455b2fbd32 - Correlation ID: efd2db84-043c-43c1-91b7-b9c1dc4dbd83 Context that may help: - Legitimate business: sole proprietorship (Einzelunternehmen) registered in Germany. - The Entra tenant is newly created for this purpose, which I understand can raise a risk flag; I am the Global Admin. - I can re-attempt using a global admin on my own business domain (rather than the account originally used) if that helps the trust evaluation. - Official business-registration documentation and VAT ID (USt-IdNr) are available on request for verification. Thank you for reviewing this.Sensitivity Auto-labelling via Document Property
Why is this needed? Sensitivity labels are generally relevant within an organisation only. If a file is labelled within one environment and then moved to another environment, sensitivity label content markings may be visible, but by default, the applied sensitivity label will not be understood. This can lead to scenarios where information that has been generated externally is not adequately protected. My favourite analogy for these scenarios is to consider the parallels between receiving sensitive information and unpacking groceries. When unpacking groceries, you might sit your grocery bag on a counter or on the floor next to the pantry. You’ll likely then unpack each item, take a look at it and then decide where to place it. Without looking at an item to determine its correct location, you might place it in the wrong location. Porridge might be safe from the kids on the bottom shelf. If you place items that need to be protected, such as chocolate, on the bottom shelf, it’s not likely to last very long. So, I affectionately refer to information that hasn’t been evaluated as ‘porridge’, as until it has been checked, it will end up on the bottom shelf of the pantry where it is quite accessible. Label-based security controls, such as Data Loss Prevention (DLP) policies using conditions of ‘content contains sensitivity label’ will not apply to these items. To ensure the security of any contained sensitive information, we should look for potential clues to its sensitivity and then utilize these clues to ensure that the contained information is adequately protected - We take a closer look at the ‘porridge’, determine whether it’s an item that needs protection and if so, move it to a higher shelf in the pantry so that it’s out of reach for the kids. Effective use of Purview revolves around the use of ‘know your data’ strategies. We should be using as many methods as possible to try to determine the sensitivity of items. This can include the use of Sensitive Information Types (SITs) containing keyword or pattern-based classifiers, trainable classifiers, Exact Data Match, Document fingerprinting, etc. Matching items via SITs present in the items content can be problematic due to false positives. Keywords like ‘Sensitive’ or ‘Protected’ may be mentioned out of context, such as when referring to a classification or an environment. When classifications have been stamped via a property, it allows us to match via context rather than content. We don’t need to guess at an item’s sensitivity if another system has already established what the item’s classification is. These methods are much less prone to false positives. Why isn’t everyone doing this? Document properties are often not considered in Purview deployments. SharePoint metadata management seems to be a dying artform and most compliance or security resources completing Purview configurations don’t have this skill set. There’s also a lack of understanding of the relevance of checking for item properties. Microsoft haven’t helped as the documentation in this space is somewhat lacking and needs to be unpicked via some aligning DLP guidance (Create a DLP policy to protect documents with FCI or other properties). Many of these configurations will also be tied to regional requirements. Document properties being used by systems where I’m from, in Australia, will likely be very different to those used in other parts of the world. In the following sections, we’ll take a look at applicable use cases and walk through how to enable these configurations. Scenarios for use Labelling via document property isn’t for everyone. If your organisation is new to classification or you don’t have external partners that you collaborate with at higher sensitivity levels, then this likely isn’t for you. For those that collaborate heavily and have a shared classification framework, as is often seen across government, this is a must! This approach will also be highly relevant to multi-tenant organisations or conglomerates where information is regularly shared between environments. The following scenarios are examples of where this configuration will be relevant: 1. Migrating from 3 rd party classification tools If an item has been previously stamped by a 3 rd party classification tool, then evaluating its applied document properties will provide a clear picture of its security classification. These properties can then be used in service-based auto-labelling policies to effectively transition items from 3 rd party tools to Microsoft Purview sensitivity labels. As labels are applied to items, they will be brought into scope of label-based controls. 2. Detecting data spill Data spill is a term that is used to define situations where information that is of a higher than permitted security classification land in an environment. Consider a Microsoft 365 tenant that is approved for the storage of Official information but Top Secret files are uploaded to it. Document properties that align with higher than permitted classifications provide us with an almost guaranteed method of identifying spilled items. Pairing this document property with an auto-labelling policy allows for the application of encryption to lock unauthorized users out of the items. Tools like Content Explorer and eDiscovery can then be used to easily perform cleanup activities. If using document properties and auto-labelling for this purpose, keep in mind that you’ll need to create sensitivity labels for higher than permitted classifications in order to catch spilled items. These labels won’t impact usability as you won’t publish them to users. You will, however, need to publish them to a single user or break glass account so that they’re not ignored by auto-labelling. 3. Blocking access by AI tools If your organization was concerned about items with certain properties applied being accessed by generative AI tools, such as Copilot, you could use Auto-labelling to apply a sensitivity label that restricts EXTRACT permissions. You can find some information on this at Microsoft 365 Copilot data protection architecture | Microsoft Learn. This should be relevant for spilled data, but might also be useful in situations where there are certain records that have been marked via properties and which should not be Copilot accessible. 4. External Microsoft Purview Configurations Sensitivity labels are relevant internally only. A label, in its raw form, is essentially a piece of metadata with an ID (or GUID) that we stamp on pieces of information. These GUIDs are understood by your tenant only. If an item marked with a GUID shows up in another Microsoft 365 tenant, the GUID won’t correspond with any of that tenant’s labels or label-based controls. The art in Microsoft Purview lies in interpreting the sensitivity of items based on content markings and other identifiers, so that data security can be maintained. Document properties applied by Purview, such as ClassificationContentMarkingHeaderText are not relevant to a specific tenant, which makes them portable. We can use these properties to help maintain classifications as items move between environments. 5. Utilizing metadata applied by Records Management solutions Some EDRMS, Records or Content Management solutions will apply properties to items. If an item has been previously managed and then stamped with properties, potentially including a security classification, via one of these systems, we could use this information to inform sensitivity label application. 6. 3 rd party classification tools used externally Even if your organisation hasn’t been using 3rd party classification tools, you should consider that partner organisations, such as other Government departments, might be. Evaluating the properties applied by external organisations to items that you receive will allow you to extend protections to these items. If classification tools like Janus or Titus are used in your geography/industry, then you may want to consider checking for their properties. Regarding the use of auto-classification tools Some organisations, particularly those in Government, will have organisational policies that prevent the use of automatic classification capabilities. These policies are intended to ensure that each item is assessed by an actual person for risk of disclosure rather than via an automated service that could be prone to error. However, when auto-labelling is used to interpret and honour existing classifications, we are lowering rather than raising the risk profile. If the item’s existing classification (applied via property) is ignored, the item will be treated as porridge and is likely to be at risk. If auto-labelling is able to identify a high-risk item and apply the relevant label, it will then be within scope of Purview’s data security controls, including label-based DLP, groups and sites data out of place alerting, and potentially even item encryption. The outcome is that, through the use of auto-labelling, we are able to significantly reduce risk of inappropriate or unintended disclosure. Configuration Process Setting up document property-based auto-labelling is fairly straightforward. We need to setup a managed property and then utilize it an auto-labelling policy. Below, I've split this process into 6 steps: Step 1 – Prepare your files In order to make use of document properties, an item with the properties applied will first need to be indexed by SharePoint. SharePoint will record the properties as ‘crawled properties’, which we’ll then need to convert into ‘managed properties’ to make them useful. If you already have items with the relevant properties stored in SharePoint, then they are likely already indexed. If not, you’ll need to upload or create an item or items with the properties applied. For testing, you’ll want to create a file with each property/value combination so that you can confirm that your auto-labelling policies are all working correctly. This could require quite a few files depending on the number of properties you’re looking for. To kick off your crawled property generation though, you could create or upload a single file with the correct properties applied. For example: In the above, I’ve created properties for ClassificationContentMarkingHeaderText and ClassificationContentMarkingFooterText, which you’ll often see applied by Purview when an item has a sensitivity label content marking applied to it. I’ve also included properties to help identify items classified via JanusSeal, Titus and Objective. Step 2 – Index the files After creating or uploading your file, we then need SharePoint to index it. This should happen fairly quickly depending on the size of your environment. I'd expect to wait sometime between 10 minutes and 24 hrs. If you're not in a hurry, then I'd recommend just checking back the next day. You'll know when this has been completed when you head into SharePoint Admin > Search > Managed Search Schema > Crawled Properties and can find your newly indexed properties: Step 3 – Configure managed properties Next, the properties need to be configured as managed properties. To do this, go to SharePoint Admin > More features > Search > Managed Search Schema > Managed Properties. Create a new managed property and give it a name. Note that there are some character restrictions in naming, but you should be able to get it close to your document property name. Set the property’s type to text, select queryable and retrievable. Under ‘mappings to crawled properties’, choose add mapping, search for and select the property indexed from the file property. Note that the crawled property will have the same name as your document property, so there’s no need to browse through all of them: Repeat this so that you have a managed property for each document property that you want to look for. Step 4 – Configure Auto-labelling policies Next up, create some auto-labelling policies. You’ll need one for each label that you want to apply, not one per property as you can check multiple properties within the one auto-labelling policy. - From within Purview, head to Information Protection > Policies > Auto-labelling policies. - Create a new policy using the custom policy template. - Give your policy an appropriate name (e.g. Label PROTECTED via property). - Select the label that you want to apply (e.g. PROTECTED). - Select SharePoint based services (SharePoint and OneDrive). - Name your auto-labelling rules appropriately (e.g. SPO – Contains PROTECTED property) - Enter your conditions as a long string with property and value separated via a colon and multiple entries separated with a comma. For example: ClassificationContentMarkingHeaderText:PROTECTED,ClassificationContentMarkingFooterText:PROTECTED,Objective-Classification:PROTECTED,PMDisplay:PROTECTED,TitusSEC:PROTECTED Note that the properties that you are referencing are the Managed Property rather than the document property. This will be relevant if your managed property ended up having a different name due to character restrictions. After pasting in your string into the UI, the resultant rule should look something like this: When done, you can either leave your policy in simulation mode or save it and then turn it on from the auto-labelling policies screen. Just be aware of any potential impacts, such as accidently locking users out by automatically deploying a label with encryption configuration. You can reduce any potential impact by targeting your auto-labelling policy at a site or set of sites initially and then expanding its scope after testing. Step 5 - Test Testing your configuration will be as easy as uploading or creating a set of files with the relevant document properties in place. Once uploaded, you’ll need to give SharePoint some time to index the items and then the auto-labelling policy some time to apply sensitivity labels to them. To confirm label application, you can head to the document library where your test files are located and enable the sensitivity column. Files that have been auto-labelled will have their label listed: You could also check for auto-labelling activity in Purview via Activity explorer: Step 6 – Expand into DLP If you’ve spent the time setting up managed properties, then you really should consider capitalizing on them in your DLP configurations. DLP policy conditions can be configured in the same manner that we configured Auto-labelling in Step 3 above. The document property also gives us an anchor for DLP conditions that is independent of an item’s sensitivity label. You may wish to consider the following: DLP policies blocking external sharing of items with certain properties applied. This might be handy for situations where auto-labelling hasn’t yet labelled an item. DLP policies blocking the external sharing of items where the applied sensitivity label doesn’t match the applied document property. This could provide an indication of risky label downgrade. You could extend such policies into Insider Risk Management (IRM) by creating IRM policies that are aligned with the above DLP policies. This will allow for document properties to be considered in user risk calculation, which can inform controls like Adaptive Protection. Here's an example of a policy from the DLP rule summary screen that shows conditions of item contains a label or one of our configured document properties: Thanks for reading and I hope this article has been of use. If you have any questions or feedback, please feel free to reach out.
