B2B SPO: GCCH tenant members as guests on commercial Entra
Has anyone successfully enabled GCC guest access to a Commercial SharePoint Online site? We support customers on GCCH tenants and are migrating an on‑prem SharePoint workload to Commercial M365 SPO. Inviting GCC users as guests fails with token/Token ID errors. Entra sign‑in succeeds, but SharePoint token issuance fails. CTAP is configured on both GCC (outbound) and Commercial (inbound). Microsoft support indicated it may not be possible (“Entra won’t pass OIDC to SPO”), but Microsoft documentation suggests B2B for SharePoint works across US Gov and Commercial. If you’ve made this work (or confirmed it can’t), I’d appreciate any practical guidance or gotchas. Thanks!Join us at Microsoft 365 Copilot Discovery event in Huntsville, AL! - UPDATED LOCATION AND DATES!
The Microsoft 365 Copilot Discovery event in Huntsville, AL features hands-on demos, expert sessions, and real-world use cases showcasing AI-driven productivity, Microsoft Copilot capabilities, and modern workplace innovation. The event takes place on May 19th 2026 in Huntsville, AL.Understanding Compliance Between Commercial, Government, DoD & Secret Offerings - May 2026 Update
Understanding compliance between Commercial, Government, DoD & Secret Offerings: There remains much confusion as to what service supports what standards best. If you have CMMC, DFARS, ITAR, FedRAMP, CJIS, IRS and other regulatory requirements and you are trying to understand what service is the best fit for your organization then you should read this article.
Architecture Risk Brief: Silent Data Integrity Failures in Distributed Criminal Justice Systems
Why Modernized Public Safety Environments Need Stronger Data Integrity Controls In criminal justice information services systems, the most dangerous failures are often the ones you cannot see. A system may appear fully operational—dashboards green, services responsive, transactions flowing—while critical data is incomplete, inconsistent, or out of sync across connected platforms. In these environments, the absence of alerts does not necessarily mean the absence of problems. Instead, it can signal that data integrity issues are developing silently beneath normal system behavior. As agencies modernize criminal justice information services (CJIS) systems, adopt cloud platforms, and expand data sharing across jurisdictions, the challenge is not only keeping systems online; it is ensuring the data moving between them remains accurate, consistent, and trustworthy. Why This Risk Is Growing Criminal justice agencies are going through rapid modernization, and with that comes a level of complexity that simply didn’t exist in earlier, more isolated systems. In many environments, legacy applications are still running alongside newer cloud-based platforms, which creates gaps in how data is processed and interpreted. At the same time, transaction volumes have increased significantly, and under heavy load it’s not uncommon to see partial commits, retry behavior, or subtle inconsistencies that are hard to detect. There’s also a growing expectation for near real-time synchronization across systems, even when those systems weren’t originally designed to stay perfectly in sync. As more agencies begin sharing data across jurisdictions, the number of integration points increases, and each one introduces its own risk. None of these changes are inherently problematic, but together they create conditions where data integrity issues can develop quietly without triggering any obvious system failures. These changes improve capability but also create new failure modes that traditional monitoring does not detect. System uptime alone is no longer a reliable indicator of operational health. The CJIS Security Policy reinforces this requirement by mandating that criminal justice information (CJI) remain accurate, complete, and protected from unauthorized alteration throughout its lifecycle. What Silent Data Integrity Failures Look Like Silent failures almost never show up as outages. Most of the time, everything looks fine on the surface—systems are up, jobs are running, dashboards are green. The problems usually come to light much later, often when someone is preparing for an audit, reconciling data between agencies, or digging into a case where something just doesn’t add up. In one scenario, a transaction completed successfully in the source system but never made it to a downstream platform. There were no errors, no retries flagged—just missing data. In another case, records looked perfectly valid within each system, but when compared across environments, they didn’t match. These kinds of discrepancies tend to surface during reporting or compliance checks, not during normal operations. That’s what makes them difficult to catch. From an operational standpoint, everything appears healthy. There are no alerts or obvious failures, but underneath that, the data has slowly drifted out of sync. Database Corruption: The Most Silent Failure of All Beyond synchronization gaps, database corruption represents an even more dangerous and often invisible threat. Corruption can arise from: Storage subsystem issues Hardware degradation Incomplete writes under high load Failover anomalies Legacy-to-cloud interactions Low-severity corruption may go unnoticed for weeks but eventually impacts multiple agency systems. Because corruption directly threatens the accuracy and integrity of CJI, it poses a significant CJIS compliance risk. My Implementation: Automated Corruption Alerts To deal with this, I implemented a simple automated alerting system that monitors corruption indicators and notifies me as soon as something looks off. Instead of waiting for issues to surface during audits or downstream failures, this provides an early signal that something isn’t right. In practice, it means I can react quickly, investigate the issue before it spreads, and avoid situations where bad data propagates into other systems. In CJIS environments, even a single corrupted record can have real consequences, so early visibility makes a meaningful difference. Flow Diagram to Detect Integrity Root Causes of Silent Data Drift In most cases, these data integrity issues don’t come from obvious failures—they build up during normal day-to-day operations. In high-volume systems, retries and partial commits under load can leave data in an inconsistent state without triggering any errors. During modernization or cloud migrations, subtle differences in schema behavior or transformation logic can cause data to drift between systems over time. Another common gap is monitoring. Most setups track uptime and performance, but very few validate whether the data itself remains consistent across platforms. And once data moves across multiple systems and integrations, each handoff becomes a potential point where something can go slightly wrong. None of these issues stand out individually, but together they create conditions where inconsistencies quietly accumulate. Next Steps for Agencies Criminal justice organizations don’t need to overhaul their entire technology stack to strengthen data integrity. Instead, they can take practical, incremental steps that build resilience into existing systems while preparing for future modernization. Establish a Baseline for Data Integrity Map where data originates, how it moves, and where it is stored across multiple agency systems. Implement Routine Cross-System Validation Use Azure Data Factory, Azure SQL Data Sync, and Log Analytics queries to automate comparisons between operational and reporting systems. Monitor for Corruption and Synchronization Failures Enable corruption detection and configure automated notifications—similar to the low-to-critical corruption alerts I implemented. Treat Failover and Migration as Integrity Events Use Azure SQL Failover Groups and ADF pipelines to verify data consistency before and after transitions. Strengthen Governance and Documentation Use Microsoft Purview to track lineage, schema changes, and data ownership. Build a Culture of Data Integrity Encourage teams to treat data correctness as a shared responsibility across the organization. Final Thoughts Criminal justice information systems have made significant progress in availability, scalability, and security. But as these systems become more distributed and interconnected, data integrity—including corruption detection—is emerging as one of the most critical and least visible operational risks. The challenge is no longer simply ensuring systems stay online. It is ensuring that the data moving through them remains correct, consistent, and trustworthy across every system, agency, and workflow that depends on it. In environments where data directly impacts investigations, reporting, and compliance decisions, integrity must be engineered, validated, and continuously enforced with the same rigor applied to system availability and security.The Art and Science of Prompting for Public Safety
Starting a discussion thread for those in Public Safety that are looking to improve their skilling and prompting of using Microsoft 365 Copilot and agentic AI in your flow of work. Try all the prompts in the attached deck, these are my favorites I've curated over years. Slide 10 is the best prompt I've ever used, it automates persona prompting and is a MUST TRY. Share your favorites or ideas of what you'd like to learn or prompt on. Cheers Dan Narloch WW Government - Product Marketing LeaderAzure Government or Azure Commercial for CJIS 6.0: Choosing Your Compliance Path
Since 2014, United States criminal justice agencies have trusted Microsoft Azure Government to manage Criminal Justice Information (CJI). Built exclusively for regulated government data, it provides datacenters with physical, network, and logical isolation and is operated by CJIS-screened U.S. persons—the "gold standard" for compliance. However, we understand that flexibility is critical for modern agencies. As first announced with the release of CJIS Security Policy (CJISSECPOL) v5.9.1, agencies have the option to utilize Azure Commercial for CJIS workloads by leveraging advanced technical controls in place of traditional personnel screening. With the release of CJIS Security Policy 6.0, this hybrid landscape has evolved. The new policy moves beyond simple access control toward a "Zero Trust" framework which minimizes implicit trust, verifies all requests, and requires continuous monitoring. What’s New in CJIS 6.0? The 6.0 update (released late 2024) is a modernization overhaul. Key changes include: Phishing-Resistant MFA: Strict requirements for FIDO2 or certificate-based authentication for all privileged access. Continuous Monitoring: A shift from point-in-time audits to real-time threat detection and automated logging. Supply Chain Risk Management: Enhanced vetting of third-party software and vendors. The Choice: Azure Government or Azure Commercial: Criminal Justice Agencies can still choose between our two distinct offerings, but the "How" of compliance differs: Azure Government: The path of personnel screening. Microsoft executes CJIS Management Agreements with state CJIS Systems Agencies that include their screening of Microsoft personnel. This offers the broadest feature set with the simplest compliance burden. Azure Commercial: The path of technical controls. Because Azure Commercial support staff are not CJIS-screened, compliance relies on an agency implementing Customer Managed Keys (CMK) encryption. This way, Microsoft cannot access unencrypted criminal justice information, effectively removing Microsoft staff from the scope of trust. Our Commitment Whether you choose the physically secure location of Azure Government or the global scale of Azure Commercial, Microsoft provides the tools—Entra ID, Azure Key Vault, and Microsoft Sentinel—to meet the rigorous demands of CJIS 6.0. Step-by-Step Walkthrough for CJIS 6.0 in Azure Commercial Managing CJI in Azure Commercial requires you to bridge the gap between "standard commercial security" and "CJIS compliance" using your own configurations. Because Microsoft Commercial staff are not CJIS-screened, you must ensure they can never see unencrypted data. Phase 1: Foundation & Residency Step 1: Restrict Data Residency CJIS 6.0 mandates that CJI must not leave the United States. Action: Deploy all Azure resources (compute, storage, disks, networking, monitoring, logging, backups, etc.) exclusively in US regions (e.g., East US, West US, Central US). Policy: Use Azure Policy to deny the creation of resources in non-US regions to prevent accidental drift. o Documentation: Tutorial: Manage tag governance with Azure Policy (See the concept of "Allowed Locations" built-in policy). o Documentation: Azure Policy built-in definitions and assignment (Allowed locations) o Documentation: Details of the "Allowed locations" policy definition. Phase 2: The "Technical Control" (Encryption) This is the most critical step for Azure Commercial. Step 2: Implement Customer Managed Keys (CMK) To meet CJIS requirements in Azure Commercial, which is operated by Microsoft personnel who aren’t CJIS-screened, you must use encryption where you hold the keys, and Microsoft has no access. Action: Provision Azure Key Vault (Premium) or Managed HSM for FIPS 140-2 Level 2/3 compliance. o Documentation: About Azure Key Vault Premium and HSMs. o Documentation: Secure your Azure Managed HSM deployment. Action: Generate your encryption keys within your HSM or import them from on-premises. o Documentation: How to generate and transfer HSM-protected keys (BYOK). Action: Configure Disk Encryption Sets and Storage Account Encryption to use these keys. Do not use the default "Microsoft Managed Key" setting. o Documentation: Server-side encryption of Azure Disk Storage (CMK). o Documentation: Configure customer-managed keys for Azure Storage. o Documentation: Services that support customer-managed keys (CMKs) Step 3: Client-Side Encryption (For SaaS/PaaS) For data processing, encryption should happen before data reaches Azure. Action: Ensure applications encrypt CJI at the application layer before writing to databases (SQL Azure, Cosmos DB). This ensures that even a database admin with platform access sees only ciphertext. Step 3b: Protecting CJI While In Use (Confidential Compute) - Azure Commercial and Customer Managed Key (CMK) encryption satisfy the requirements of the CJIS Security Policy but customers can choose to add an additional control through a Confidential Computing enclave CJIS Security Policy 6.0 requires that Criminal Justice Information be protected while at rest, in transit, and in use. In Azure Commercial, once CJI is decrypted for processing by an application, traditional encryption controls (including CMK) no longer protect the data from platform-level access risks such as memory inspection, diagnostics, or hypervisor operations. To address this risk, agencies may implement Azure Confidential Computing, which uses hardware-backed Trusted Execution Environments (TEEs) to cryptographically isolate data in memory and prevent access by cloud provider personnel—even at the infrastructure layer. o Documentation: Always Encrypted for Azure SQL Database. o Documentation: Client-side encryption for Azure Cosmos DB. o Documentation: Confidential Computing o Documentation: Confidential Compute Offerings Phase 3: Identity & Access (CJIS 6.0 Focus) Step 4: Phishing-Resistant MFA CJIS 6.0 raises the bar for Multi-Factor Authentication (MFA). SMS and simple push notifications may no longer suffice for privileged roles. Action: Deploy Microsoft Entra ID (formerly Azure AD). o Documentation: What is Microsoft Entra ID?. Action: Enforce FIDO2 security keys (like YubiKeys) or Certificate-Based Authentication (CBA) for all users accessing CJI. o Documentation: Enable passkeys (FIDO2) for your organization. o Documentation: How to configure Certificate-Based Authentication in Entra ID. Phase 4: Continuous Monitoring Step 5: Unified Audit Logging You must retain audit logs for at least one year (or longer depending on state rules) and review them weekly. Action: Enable Diagnostic Settings on all CJIS resources to stream logs to an Azure Log Analytics Workspace. o Documentation: Create diagnostic settings in Azure Monitor. Action: Deploy Microsoft Sentinel on top of Log Analytics. o Documentation: Quickstart: Onboard Microsoft Sentinel. Action: Configure Sentinel analytic rules to detect anomalies (e.g., "Mass download of CJI," "Access from foreign IP"). o Documentation: Detect threats out-of-the-box with Sentinel analytics rules. Phase 5: Endpoint & Mobile Step 6: Mobile Device Management (MDM) If CJI is accessed on mobile devices (MDTs, tablets), CJIS 6.0 requires remote wipe and encryption capability. Action: Enroll devices in Microsoft Intune. o Documentation: Enroll Windows devices in Intune. o Documentation: Enroll iOS/iPadOS devices in Intune. Action: Create a Compliance Policy requiring BitLocker/FileVault encryption and complex PINs. o Documentation: Create a compliance policy in Microsoft Intune. o Documentation: Manage BitLocker policy for Windows devices with Intune. Action: Configure "App Protection Policies" to ensure CJI cannot be copied/pasted into unmanaged apps (like personal email). o Documentation: App protection policies overview. Phase 6: Personnel & Documentation Step 7: Update your SEIP/SSP Since you are using Azure Commercial, your System Security Plan (SSP) must explicitly state that you are using encryption as the compensating control for the lack of vendor personnel screening. Action: Document the CMK architecture in your CJIS audit packet. Action: Ensure your agency's "CJI Administrators" (who manage the Azure keys) have met the policy’s personnel screening requirements o Documentation: Microsoft CJIS Audit Scope & Personnel Screening (Reference).
