Accelerate connectors development using AI agent in Microsoft Sentinel
Today, we’re excited to announce the public preview of a Sentinel connector builder agent, via VS code extension, that helps developers build Microsoft Sentinel codeless connectors faster with low-code and AI-assisted prompts. This new capability brings guided workflows directly into the tooling developers already use, helping accelerate time to value as the Sentinel ecosystem continues to grow. Learn more at Create custom connectors using Sentinel connector AI agent Why this matters As the Microsoft Sentinel ecosystem continues to expand, developers are increasingly tasked with delivering high‑quality, production‑ready connectors at a faster pace, often while working across different cloud platforms and development environments. Building these integrations involves coordinating schemas, configuration artifacts, Azure deployment concepts, and validation steps that provide flexibility and control, but can span multiple tools and workflows. As connector development scales across more partners and scenarios, there is a clear opportunity to better integrate these capabilities into the developer environments teams already rely on. The new Sentinel connector builder agent, using GitHub Copilot in the Sentinel VS code extension, brings more of the connector development lifecycle -- authoring, validation, testing, and deployment into a single, cohesive workflow. By consolidating these common steps, it helps developers move more easily from design to validation and deployment without disrupting established processes. Read the full announcement here: Accelerate connectors development using AI agent in Microsoft Sentinel Original Publication: Microsoft Security Community Blog, March 30th, 2026
Building Microsoft Sentinel Connectors in Minutes with the Sentinel Connector Builder Agent
Overview We previously announced the public preview of the Microsoft Sentinel connector builder agent via VS code extension, that helps developers build Microsoft Sentinel codeless connectors faster with low-code and AI-assisted prompts. This post walks through a hands-on lab using a mock Network Log API to demonstrate how the Sentinel connector builder agent simplifies building Codeless Connector Framework (CCF) pull connectors. Instead of manually creating ingestion infrastructure and configuration files, you’ll use a guided, conversational workflow in VS Code to generate connector artifacts, test them against a live API, and deploy them into Microsoft Sentinel. The lab focuses on the end-to-end experience ranging from API setup to validated connector deployment so you can see how quickly a working integration can be produced. For additional guidance beyond this lab, refer to our MS Learn documentation. The Lab Environment This lab is built around a mock Network Log API hosted as an Azure Function App. The purpose of the lab environment is to give us a live API that we can use to build, validate, and test the Sentinel CCF connector builder agent against end to end. The API exposes 50 synthetic network activity records that look and behave like a real product data source, including web traffic, DNS requests, blocked remote access attempts, malware command-and-control blocks, VPN activity, and other common network events. That makes it a useful stand-in for the type of telemetry many teams want to onboard into Microsoft Sentinel. The API is intentionally shaped like the kind of source a customer might expose for telemetry retrieval. It uses API key authentication through the X-API-Key header, returns paginated results through a nextLink model, and provides a predictable response structure that the builder agent can map into a pull connector configuration. The repo contains everything needed for the walkthrough. There is an ARM template to deploy the Function App, reference documentation for the API, and a sample connector package showing the generated polling config, table schema, DCR, and connector definition. The end goal of the lab is straightforward: use the builder agent to generate a CCF pull connector that ingests this API into the custom NetworkLogAPIGetNetworkLogs_CL table in Sentinel. Follow the full walkthrough here: Building Microsoft Sentinel Connectors in Minutes with the Sentinel Connector Builder Agent Original Publication: Microsoft Sentinel Blog, August 11th, 2026Empower Real-Time Security with Microsoft Sentinel’s CCF Push Feature
In today’s rapidly evolving threat landscape, organizations need security solutions that deliver actionable insights in real time, not minutes or hours after the fact. Microsoft Sentinel continues to expand its capabilities, driven by a commitment to empower customers and partners with cutting-edge tools for proactive defense. Today, we are excited to announce the public preview of our latest innovation, the Sentinel Codeless Connector Framework (CCF) Push feature. CCF Push addresses a critical need: enabling seamless, automated, and immediate delivery of security data to Sentinel, so teams can respond to threats as they happen. What Is CCF Push and Why Does It Matter? Microsoft Sentinel connectors generally follow two patterns. In the polling pattern, partners and customers expose their web‑facing REST API endpoints and use our traditional CCF connectors to poll those endpoints at intervals to gather data for ingestion into Sentinel. In the push pattern, partners and customers send data directly to a Sentinel workspace. Our new CCF Push capability was built to streamline and accelerate time to adoption for this second pattern. Read the full announcement here: Empower Real-Time Security with Microsoft Sentinel’s CCF Push Feature Original Publication: Microsoft Sentinel Blog, February 12th, 2026
Announcing new security enhancements across Azure IoT services
Security is foundational to the connected products and solutions our customers build. It shapes every decision, from how devices are provisioned to how they connect and receive updates. As device fleets scale and attackers probe new vectors, from the network layer to the software supply chain, customers are asking for stronger security defaults at each of these stages. Today we’re strengthening all three. Customers managing connected devices get a modern transport-security baseline with TLS 1.3 for Azure IoT Hub, identity-based provisioning that removes long-lived secrets with managed identity support for linking an IoT Hub to DPS, and encrypted update delivery with TLS downloads for Device Update for IoT Hub. TLS 1.3 and managed identity are in Public Preview; TLS downloads is Generally Available. At a glance Feature Service Status TLS 1.3 support Azure IoT Hub Public Preview Managed identity for Hub linking Azure IoT Device Provisioning Service + IoT Hub Public Preview TLS downloads (encrypted update delivery) Device Update for IoT Hub Generally Available TLS 1.3 support for Azure IoT Hub (Public Preview) Azure IoT Hub now supports TLS 1.3 through new endpoints that sit alongside the existing classic endpoint: Classic endpoint: <hub>.azure-devices.net TLS 1.3 Device endpoint: <hub>.device.azure-devices.net TLS 1.3 Service endpoint: <hub>.service.azure-devices.net The new device and service endpoints support TLS 1.3, and also support TLS 1.2 with a reduced, security-compliant cipher suite set. Devices connect through the device endpoint for device-to-cloud telemetry and cloud-to-device messages, while backend and management applications built on the service SDK connect through the service endpoint. The existing endpoint remains available, so customers can adopt the new endpoints on their own timeline rather than through a forced migration. No enablement action is needed: the new endpoints are provisioned automatically on new and existing hubs, and customers adopt TLS 1.3 by pointing their device or service clients at the new hostnames. TLS 1.3 gives customers a more modern security baseline for IoT connectivity. Just as importantly, this release introduces a clearer separation between device traffic and service traffic through dedicated endpoints, which makes the connectivity model easier to understand and evolve over time. This design also reflects how real IoT deployments work. Many customers cannot update every device or backend integration at once, so a side-by-side endpoint model helps teams test, validate, and roll out changes in stages. Learn more about Azure IoT Hub support for TLS 1.3. Managed identity support for Hub linking (Public Preview) We are also introducing managed identity support for linking an IoT Hub to DPS. DPS links to an IoT Hub securely to assign devices to the right hubs at scale, and until now, that link has relied on connection-string (shared access key) authentication. This dependency on a shared key results in customers keeping local authentication enabled on the IoT Hub, even when their security policies call for disabling it in favor of Microsoft Entra ID. Managed identity support removes that constraint: DPS can now authenticate to IoT Hub using a managed identity backed by Microsoft Entra ID so the Hub linking no longer requires a connection string. As a result, customers can disable local authentication on the IoT Hub, remove long-lived shared keys from the provisioning path, and simplify credential lifecycle management and security governance with no shared keys to rotate, store, or accidentally leak. Together, TLS 1.3 and managed identity strengthen the same Hub linking scenario: TLS 1.3 modernizes how devices and services connect to IoT Hub, while managed identity gives Azure services credential-free authentication during provisioning. Learn more about how to link an IoT Hub to DPS using managed identity. Secure update delivery: TLS downloads for Device Update for IoT Hub (Generally Available) Device Update for IoT Hub can now deliver update content over HTTPS, encrypting update content in transit between the Device Update service and your devices. For customers managing large fleets, this brings update delivery in line with the same modern transport-security expectations now applied to device and service connectivity, and helps teams meet encryption-in-transit and compliance requirements. Download security is a deployment-level setting available in Device Update data plane API version 2026-06-01. New deployments created with this version use HTTPS by default, while existing deployments continue using their current configuration. Customers that require HTTP downloads can still explicitly select HTTP. You can configure download security in the Azure portal when creating a deployment, or through the REST API, SDKs, Azure CLI, and automation workflows. Earlier API versions support HTTP downloads only. Before enabling HTTPS, confirm your devices are ready. Devices must support HTTPS downloads, trust the required root certificate authorities, and support TLS 1.2 or TLS 1.3. Some constrained or embedded devices may require code changes; see additional considerations for constrained or embedded devices. Learn more about download security for Device Update for IoT Hub. Why this matters together With these enhancements, Azure IoT services are taking another step toward secure, modern device onboarding, connectivity, and lifecycle management. TLS 1.3 modernizes how devices and services connect, managed identity removes secrets from the provisioning flow, and TLS download protects update content in transit. Each addresses a different layer of the security model, and together they reflect Microsoft's ongoing, security-first commitment to the platforms our customers build on. Customers can adopt TLS 1.3 for IoT Hub and managed identity for Hub linking in Preview today and put TLS downloads for Device Update into production right now. Get started Explore the documentation and share your feedback: TLS 1.3 for Azure IoT Hub (Preview) Managed identity for Hub linking (Preview) Download security (TLS) for Device Update for IoT Hub For questions or feedback, email us at iotdeviceonboarding@microsoft.com
did the Jun 9 Security Update remove trusted (amazon) certs?
We have a product that runs on Windows and uses AWS IoT to connect and transmit info. We noticed yesterday that many - roughly 2/3 of our fleet went silent - no connections. We have some of our own PCs that experienced this as well. Investigation yielded issues with TLS. The client (which is just using the default windows cert checking) actively terminated the connected. It didn't like the cert from the AWS IoT endpoint. All of these PCs were happily connected on Jun 8. Investigation seemed to indicate that some combination of Amazon Root CA (1-4) and some Starfield certs were not in the device cert mgr. Also - when we manually added AmazonRootCA1.pem to the cert mgr, our service connected again. So the evidence seems to strongly support that the security update removed trusted amazon root certs from the cert store. I'm guessing some/many won't notice since they are making regular TCP connections and maybe the certs get auto-added if they are not there? But we are doing MQTT over the AWS port 8883. So perhaps Windows did not detect this and seek to refresh its cert store? Can anyone confirm if they have seen the same?
New audit requirement for Security specializations starts July 2026
Security specializations signal verified, high-caliber capability to customers and Microsoft field teams—and that signal holds up better when the bar is credible. To support that standard, starting July 2026, an independent audit will replace the Customer References requirement for four Security specializations: Cloud Security, Data Security, Identity & Access Management, and Threat Protection. Whether you’re enrolling for the first time or renewing, you’ll need to meet this audit requirement to earn or maintain your credential. Moving to an audit model for these specializations raises the bar, aligns Security with Azure specializations, and gives you a stronger, harder-to-copy advantage in competitive deals and co-sell conversations. When the change goes live, existing partners will be given a six-month extension to their anniversary date to allow time to prepare for the audit. What to do now Review the updated requirements so you know what the audit entails Check your specialization status and renewal date to understand when this applies Start preparing your documentation and evidence now—don’t wait for your renewal window Prepare early to stay in good standing, avoid disruption, and keep your business moving.Show you’re a trusted leader in secure AI deployment with the Agentic Security specialization
Differentiate your expertise, build customer trust, and demonstrate readiness to deliver secure AI outcomes as customers move from experimentation to enterprise-wide AI adoption with the Agentic Security specialization, set to launch later in FY27. The Agentic Security specialization provides a clear, credible, and durable market signal that validates a partner's capabilities helping customers strengthen their security posture through AI-powered defense, threat protection, and operational resilience. Whether delivering services, software, or integrated security solutions, partners can earn the specialization to access badging and other key benefits while showcasing their ability to support customers as they strengthen security, improve operational resilience, and scale AI adoption responsibly.Behind the Build with Gigamon: Enriching Microsoft Sentinel with Network-Derived Telemetry
Behind the Build is an ongoing series spotlighting standout Microsoft partner collaborations. Each edition dives into the technical and strategic decisions that shape real-world integrations—highlighting engineering excellence, innovation, and the shared customer value created through partnership. Security teams today operate across an expanding set of signals, spanning identity, endpoint, cloud and application environments. Yet many organizations still lack sufficient visibility into how systems communicate across their infrastructure, creating gaps in detection, investigation, and response. In this edition of Behind the Build, I spoke with Srinivas Chakravarty, vice president, cloud ecosystems at Gigamon, about how Microsoft and Gigamon collaborated to bring network-derived telemetry into Microsoft Sentinel, helping customers enrich security investigations with deeper runtime context and AI-driven insights. The Evolution of Network Intelligence and Why It Matters For more than twenty years, Gigamon has helped organizations access and operationalize network traffic across complex environments. Today, the Gigamon Deep Observability Pipeline, helps enable organizations to extract actionable network-derived telemetry across hybrid infrastructure, encrypted traffic, containers, and modern application environments. That foundation makes the Gigamon Deep Observability Pipeline a strong complement to Microsoft Sentinel. Microsoft Sentinel brings together security telemetry from across the enterprise—including identity, endpoint, cloud, application, and network data sources—while Gigamon contributes enriched network-derived telemetry that provides additional runtime context into how systems, applications, and services communicate. Together, these signals can help organizations gain deeper insight for threat detection, investigation, and response. As Srinivas put it: “You have logs, you have metrics, you have traces, but network telemetry completes the picture.” Together, these data sources provide deeper context for threat detection, investigation, and AI-driven analysis. Read the full announcement here: Behind the Build with Gigamon: Enriching Microsoft Sentinel with Network-Derived Telemetry Original Publication: Microsoft Sentinel Blog, June 30th, 2026Extending Sentinel Data Integration: Azure Blob Storage Support for CCF Connectors
As organizations scale their security operations, the ability to ingest, process, and analyze high volumes of data reliably becomes increasingly critical. Microsoft Sentinel continues to expand its ecosystem through the Codeless Connector Framework (CCF), enabling ISVs to build and deliver integrations with Sentinel faster while simplifying deployment for customers. Today, CCF extends even further with support for Azure Blob Storage, introducing a new pattern for how data can be delivered into Sentinel. Expanding Connector Patterns with Azure Blob Storage CCF has traditionally enabled connectors that integrate directly with partner APIs and data sources. With this latest enhancement, ISVs can now build connectors that read data from Azure Blob Storage—unlocking new flexibility in how security data is collected and delivered. In this model, an ISV writes data to an Azure Blob Storage account. The Sentinel connector then reads from that storage layer, using Azure-native components such as Event Grid and storage queues to process events and forward them through data collection rules (DCR) into Log Analytics workspace. This approach introduces a durable data layer between the data source and Sentinel, enabling more resilient and scalable ingestion scenarios. Read the full announcement here: Extending Sentinel Data Integration: Azure Blob Storage Support for CCF Connectors Original Publication: Microsoft Sentinel Blog, May 5th, 2026
