Microsoft Ignite 2026: New Sentinel Connectors Announcement
Microsoft Sentinel helps organizations detect, investigate, and respond to threats across increasingly complex environments. As AI transforms security operations, bringing together the right data and context is more important than ever, giving human defenders and AI agents a more complete view of the environment to reason over and act on. These integrations bring signals from Microsoft and third-party technologies together across the security environment, unlocking richer context for investigations and helping power the new Integrated Security Operations Center (ISOC) in Microsoft Defender, where human defenders and AI agents can reason across the environment with shared context. The connector ecosystem isn’t the only area seeing rapid growth. Microsoft Sentinel continues to add new capabilities, including Nested API support, Azure Blob support, and multi-account support, while AI-powered tools like the connector builder agent are making it easier than ever for developers to build integrations and bring more of their security data into Sentinel. At the same time, Unified Data Management, now in public preview, makes it easier for customers to manage their Microsoft Sentinel data, connectors, tables, and ingestion health in one place. For Microsoft Ignite 2026, we’re excited to showcase recent additions to this growing ecosystem and the partners making them possible. These new and enhanced connectors continue to broaden the security data available to customers, helping human defenders and AI agents gain the context they need across the technology estate. Airlock Digital for Microsoft Sentinel Airlock Digital helps prevent malware, ransomware, and unauthorized software with deny by default application control, allowing only trusted applications, scripts, and processes to run. Its Microsoft Sentinel push integration ingests execution history, browser extension control events, server administrative activity, and policy changes for monitoring and investigation. Included parsers map execution and audit events to Microsoft’s ASIM for analysis alongside other security signals. A customizable workbook supports investigation and monitoring, and teams can create analytics rules using the ingested data. NC Protect Data Connector for Microsoft Sentinel NC Protect Data Connector for Microsoft Sentinel from archTIS brings user activity and protection logs from NC Protect into Sentinel for centralized security analysis. The connector captures user activities and access-related events, while built-in workbooks support investigation and visualization of user behavior. By correlating NC Protect audit data with other security telemetry, the integration helps teams identify suspicious user activity, trigger alerts and response workflows, strengthen auditing, and monitor guest activity across SharePoint and Teams. blacklens.io for Microsoft Sentinel blacklens.io for Microsoft Sentinel brings external and internal attack-surface data, risk-prioritized vulnerabilities, darknet intelligence, and supply-chain risks into Microsoft Sentinel. The connector ingests exposed assets, compromised identities, stolen credentials and session cookies, typosquatting domains, and supplier activity on ransomware leak sites. The solution includes a data connector and analytics rule for creating Sentinel incidents, with configurable notification rules for alert severity and type. Findings are available in Log Analytics for correlation with existing Sentinel signals and can support custom analytics rules, workbooks, automation, and threat investigations. BloodHound Enterprise BloodHound Enterprise (BHE) helps organizations protect critical assets across modern hybrid environments by continuously uncovering identity attack paths and providing actionable remediation guidance. By integrating with Microsoft Sentinel, BHE delivers attack path data and identity security posture insights directly into Sentinel workflows. This helps security teams prioritize remediation efforts based on exposure to critical assets while enriching investigations into identity-based threats, including lateral movement and privilege escalation. Together, BHE and Microsoft Sentinel help security teams connect threat detection to underlying identity risk, speed investigations, and reduce opportunities for attackers. BlueVoyant Anthropic Claude Compliance BlueVoyant Anthropic Claude Compliance brings compliance activity from the Anthropic Claude Compliance API into Microsoft Sentinel using the Codeless Connector Framework (CCF). The connector ingests Claude compliance events into Sentinel, giving security, risk, and audit teams centralized visibility into AI usage and related activity. By correlating these compliance signals with identity, endpoint, and other security telemetry, the integration supports threat hunting, investigation of policy violations and anomalous behavior, compliance monitoring, and repeatable audit workflows. Cato Networks for Microsoft Sentinel Cato Networks for Microsoft Sentinel brings security and network events from the Cato SASE Platform into Microsoft Sentinel using the Codeless Connector Framework (CCF) Push pattern. The connector pushes events into a dedicated Log Analytics table, making Cato activity available alongside other Sentinel data. By centralizing this telemetry in Sentinel, the integration enables security teams to incorporate Cato events into threat hunting, detection, and visualization workflows alongside broader security signals. Check Point EM ThreatCloud Intelligence Feed Connector for Microsoft Sentinel The Check Point EM ThreatCloud Intelligence Feed Connector brings threat intelligence from Check Point Exposure Management into Microsoft Sentinel. The connector ingests indicators of compromise (IoCs), including malicious IP addresses, domains, URLs, and file hashes, enriched with threat context such as confidence, severity, kill-chain stage, and campaign associations. An included playbook further enriches incident IoCs through ThreatCloud, helping security teams correlate intelligence with existing telemetry, accelerate triage and investigation, and reduce the manual effort required to maintain threat intelligence. Check Point Exposure Management Threat Intelligence IoC for Microsoft Sentinel Check Point Exposure Management Threat Intelligence IoC for Microsoft Sentinel brings threat intelligence from Check Point Infinity External Risk Management into Sentinel. The connector ingests malicious IP addresses, domains, URLs, and file hashes, enriched with context such as severity, confidence, and detected activity. By correlating these indicators of compromise (IoCs) with existing logs through analytics rules, hunting queries, and watchlists, the integration helps security teams reduce manual intelligence management, identify matches with external threats, and accelerate threat detection and investigation. Citrix SPA Sentinel App Citrix SPA Sentinel App brings Citrix Secure Private Access and Device Posture service events into Microsoft Sentinel using the Codeless Connector Framework (CCF). The connector imports critical logs, policy outcomes, and user activity data, giving security teams greater visibility into application access and device posture activity. An included workbook supports visualization and analysis of Citrix data, helping SOC teams correlate activity with broader security telemetry, investigate security risks, support compliance monitoring, and strengthen threat hunting across their environment. ContraForce Events for Microsoft Sentinel ContraForce Events for Microsoft Sentinel brings security delivery and administrative activity from ContraForce workspaces into Microsoft Sentinel using the Codeless Connector Framework (CCF). ContraForce is an Agentic Security Delivery Platform for service providers and security teams running triage, investigation, and response across Microsoft Defender XDR and Sentinel. The connector ingests incidents, privileged access changes, service account credential activity, and high-impact workspace actions. Three included analytics rules detect privileged access, credential, and high-impact workspace activity, helping teams monitor and investigate the platform supporting their security operations. Corelight for Microsoft Sentinel By transforming all network traffic into rich, comprehensive evidence, Corelight gives security teams using Microsoft Sentinel the visibility to understand exactly what is happening across their enterprise networks. In addition to native integration with Microsoft Sentinel, Corelight integrates with Microsoft Defender for Endpoint, Defender Vulnerability Management, and Entra ID to streamline investigations, accelerate responses, and remediate incidents quickly and easily. The Corelight App for Microsoft Sentinel includes intuitive dashboards, pre-defined workbooks , sample queries, and analytics rules that help make SOC teams more efficient and effective. CTM360 CTM360 brings external threat visibility into Microsoft Sentinel. The integration connects the CTM360 HackerView and CyberBlindspot platforms to Sentinel through REST APIs, so external attack surface and digital risk events flow straight into security operations workflows. HackerView surfaces externally exposed assets and security issues across your attack surface. CyberBlindspot adds organization-specific threat intelligence from surface, deep, and dark web monitoring. With these signals centralized in Sentinel, security teams can analyze external exposures alongside their broader telemetry and speed up detection, investigation, and response. Cyren CrowdStrike IOC Automation Cyren CrowdStrike IOC Automation connects Cyren IP reputation threat intelligence with Microsoft Sentinel and CrowdStrike Falcon to operationalize malicious IP indicators. An included Logic App playbook automatically retrieves known malicious IP addresses from Cyren and submits them to CrowdStrike Falcon as custom indicators of compromise (IOCs) for blocking and detection. Scheduled execution keeps the intelligence updated and automates the flow of Cyren IP reputation data into CrowdStrike Falcon for blocking and detection. Vaikora AI Agent Signals for Microsoft Sentinel Vaikora AI Agent Signals for Microsoft Sentinel brings behavioral security signals from AI agents into Sentinel for centralized monitoring and response. The connector ingests risk scores, anomaly and threat classifications, policy enforcement decisions, and audit data, including signals for prompt injection attempts and suspicious tool usage. Included analytics rules and a workbook help security teams detect behavioral anomalies, investigate policy violations, and incorporate AI agent risks into existing Sentinel incident workflows. Vaikora AI Agent Signals for SentinelOne Vaikora AI Agent Signals for SentinelOne brings high-risk behavioral security signals from Vaikora into SentinelOne as threat intelligence indicators of compromise (IOCs). The integration filters high-severity and anomalous AI agent activity and maps Vaikora risk scores to SentinelOne severity levels. The resulting IOCs are submitted to SentinelOne and expire after 90 days, enabling Vaikora security signals to be incorporated into SentinelOne endpoint protection workflows. DataBahn Agentic Data Control Plane for Microsoft Sentinel DataBahn’s agentic data control plane integrates with Microsoft Sentinel to provide our shared customers an AI-native data pipeline and orchestration platform that allows them to accelerate enterprise deployments. DataBahn’s pipeline standardizes onboarding and shaping across all data sources while providing operational visibility into data flow and health. Together, the collaboration focuses on reducing onboarding friction, improving normalization consistency, and enabling intentional routing, which helps security teams improve visibility, support threat detection, and streamline investigation and incident response workflows. Delinea Platform for Microsoft Sentinel Delinea Platform Sentinel Solution brings privileged access activity into Sentinel natively through the Content Hub, as a complete SOC package. The connector pulls audit events covering secrets access, authentication, session activity and configuration changes directly into Sentinel. Ready-made workbooks, analytics rules with baseline-driven detection, hunting queries and an automated response playbook let security teams detect bulk secret access, failed sign-in bursts and privilege escalation sooner, investigate without leaving Sentinel and answer auditors with a record of what happened and why it was allowed. Dynatrace Software Intelligence Platform with Microsoft Sentinel Dynatrace integrates bidirectionally with Microsoft Sentinel, bringing application attacks, runtime vulnerabilities, Dynatrace Intelligence problems, and audit logs into Sentinel, where analytics rules, workbooks, and playbooks support detection, triage, and response. Sentinel can also send alerts to Dynatrace and enrich detected attacks with Sentinel and Microsoft Defender XDR insights. Bindplane by Dynatrace complements the integration by collecting and routing logs into Sentinel, including normalization to ASIM tables, giving SOC teams runtime and topology context for investigations. ExtraHop RevealX for Microsoft Sentinel ExtraHop RevealX for Microsoft Sentinel brings network detection and response (NDR) into Sentinel, giving your SOC visibility into threats that endpoint and log tools miss, including lateral movement and credential abuse hiding in encrypted east-west traffic. RevealX decrypts and analyzes network traffic at line rate, out of band with no impact on the network. The connector sends ExtraHop detections into Sentinel for dashboards, custom alerts, and investigation, so network context enriches your existing SOC workflows instead of sitting in a separate console. Fire Compass FireCompass Risks for Microsoft Sentinel brings validated external risk findings from the FireCompass platform into Microsoft Sentinel through the Codeless Connector Framework. The connector ingests risk data including severity, affected assets, assessment context, impact, and remediation guidance. By making validated exposures available in Sentinel, security teams can correlate external risks with endpoint and network telemetry, track remediation progress, and build analytics rules, workbooks, and hunting queries on top of FireCompass findings. Gambit Security Sentinel Solution Gambit brings resilience context into Microsoft Sentinel. It finds the resilience issues in your environment and syncs them to your Sentinel workspace daily, to help analysts see recovery risk before anything goes wrong. Sentinel correlates those issues with its detections. Your team can then prioritize the attacks most likely to disrupt critical operations: the ones hitting resources that aren’t ready to recover. Sentinel tells you what’s happening. Gambit tells you whether you can recover from it. Holm Security for Microsoft Sentinel Holm Security for Microsoft Sentinel brings asset data from the Holm Security platform into Sentinel via the Holm Security REST API. The connector ingests web and network assets into Microsoft Sentinel, including metadata such as IP addresses, hostnames, operating systems, tags, and vulnerability counts per asset. By incorporating this asset inventory alongside other security telemetry, the integration enables security teams to build dashboards, create custom alerts, and correlate asset information with other data in Microsoft Sentinel. Idira Endpoint Privilege Manager for Microsoft Sentinel The Idira® Endpoint Privilege Manager by Palo Alto Networks integration for Microsoft Sentinel pulls application events and policy audit activity into Microsoft Sentinel using the Codeless Connector Framework and the Idira Endpoint Privilege Manager REST API. Events land in a dedicated Log Analytics table, so security teams can analyze privilege activity alongside their other telemetry and build detections. IPinfo: IP geolocation & intelligence database IPinfo: IP geolocation & intelligence database brings contextual IP intelligence into Microsoft Sentinel to enrich security logs and investigations. The solution provides data such as IP geolocation, network ownership and routing, proxy and residential proxy detection, ASN information, and other IP classifications. By adding this context to IP addresses observed in Sentinel, the integration helps security teams better understand indicators of compromise, prioritize security events, strengthen threat detection and investigation, and inform network and access management decisions. Island Solution for Microsoft Sentinel Island Solution for Microsoft Sentinel brings user activity and administrative audit events from the Island Enterprise Browser into Microsoft Sentinel for centralized security monitoring. The solution automatically shares events from the Island Management Console with Sentinel and includes data connectors and workbooks for user activity and admin audit logs. By adding browser activity context to existing security telemetry, the integration helps security teams monitor and analyze user and administrative activity and investigate potential security issues. NetApp Ransomware Resilience for Microsoft Sentinel NetApp Ransomware Resilience detects and contains ransomware attacks on NetApp ONTAP workloads in real time, then enables fast, clean recovery. Its Microsoft Sentinel integration enriches alerts with data-layer context, including attack type, severity, user and IP, and affected cluster, volume, and SVM. The NetApp SOAR playbook can take actions on ONTAP such as trigger immutable snapshots, block suspicious users or IPs, and take compromised volumes offline. Together, these integrations extend the NetApp Platform’s ability to help security teams triage and respond to ransomware attacks, limit data loss, protect recovery points, and coordinate response across storage and security teams. NordStellar for Microsoft Sentinel NordLayer Intelligence by NordStellar for Microsoft Sentinel brings external threat and exposure findings into Sentinel through the Azure Monitor Logs Ingestion API. The integration provides findings including leaked credentials, breach exposures, malware and info-stealer infections, dark web activity, domain impersonation risks, and external attack surface vulnerabilities. By correlating these findings with other security telemetry in Sentinel, the solution helps teams investigate external threats, identify exposures affecting their organization, and automate triage and response through analytics rules and SOAR playbooks. Panorays for Microsoft Sentinel Panorays for Microsoft Sentinel brings third-party security findings from the Panorays platform into Sentinel through the Panorays API. The connector provides security teams with visibility into the security posture of vendors and supply-chain organizations, making third-party risk and vulnerability findings available alongside other security telemetry. By incorporating Panorays findings into Sentinel workflows, the integration helps SOC teams centrally monitor and investigate third-party risks and correlate them with internal security signals. USTA Account Takeover Prevention Sentinel Connector USTA Account Takeover Prevention Sentinel Connector brings compromised credential intelligence from the PRODAFT USTA Threat Intelligence platform into Microsoft Sentinel. The connector ingests alerts for exposed corporate credentials, enabling security teams to investigate potential account takeover risks within existing Sentinel workflows. Included analytics can identify newly compromised credentials and successful Microsoft Entra ID sign-ins involving known-compromised accounts, helping SOC teams operationalize external credential intelligence and prioritize investigation and response. USTA IoC Threat Stream for Sentinel USTA IoC Threat Stream for Sentinel brings curated indicators of compromise (IoCs) from the PRODAFT USTA Threat Stream into Microsoft Sentinel Threat Intelligence. The integration provides indicators including malicious URLs, phishing sites, and malware hashes derived from PRODAFT investigations. By making these indicators available for correlation with existing telemetry, hunting queries, and detection rules, the solution helps security teams identify connections to malicious infrastructure, investigate phishing and malware activity, and incorporate external threat intelligence into existing triage and response workflows. USTA Payment Card Fraud Intelligence Sentinel Connector USTA Payment Card Fraud Intelligence Sentinel Connector brings compromised payment card intelligence from the PRODAFT USTA Threat Intelligence platform into Microsoft Sentinel. The connector retrieves alerts associated with an organization’s payment card BIN ranges and makes them available within Sentinel for investigation. Included analytics identify newly exposed and non-expired compromised cards, helping security teams centralize payment fraud intelligence, prioritize potentially actionable exposures, and incorporate them into existing investigation and response workflows. Pulumi Cloud Audit Logs for Microsoft Sentinel Pulumi Cloud Audit Logs for Microsoft Sentinel brings audit logs from Pulumi, the infrastructure platform for humans and agents, into Microsoft Sentinel through the Codeless Connector Framework (CCF). The connector ingests authentication events, organization membership changes, stack lifecycle operations, policy changes, and access token usage. It also includes three analytics rules that detect failed login attempts, stack deletions, and organization membership changes. Your security team can see what a human or agent did, when, and where across infrastructure as code, secrets, configuration, and policies, which helps speed up security and governance investigations. QCrypton PQC Scanner for Microsoft Sentinel QCrypton PQC Scanner for Microsoft Sentinel brings post-quantum cryptography readiness findings from Azure environments into Sentinel using the Codeless Connector Framework (CCF). The connector provides visibility into cryptographic assets including Key Vault keys, TLS certificates and configurations, and Entra ID app registration certificates, with quantum posture ratings and risk scores. Included are six analytics rules, a workbook, and a notification playbook to help security teams identify vulnerable cryptographic assets and prioritize post-quantum migration planning. SailPoint for Microsoft Sentinel SailPoint for Microsoft Sentinel brings identity security telemetry from SailPoint Identity Security Cloud into Sentinel using the Codeless Connector Framework (CCF). The solution streams audit and search events into Sentinel tables, where analysts can correlate identity activity with other security signals and query SailPoint APIs for additional identity and account context during incident triage. Automated playbooks can also remediate threats by revoking access or disabling compromised accounts, helping teams connect identity insight with investigation and response. SAP LogServ (RISE), S/4HANA Cloud private edition SAP LogServ (RISE), S/4HANA Cloud private edition extends Microsoft Sentinel security monitoring for SAP RISE environments with infrastructure, database, operating system, and network security logs managed by SAP Enterprise Cloud Services. Deployed alongside the Microsoft Sentinel Solution for SAP applications, it complements application-layer monitoring to provide visibility across the SAP stack and enable cross-layer threat detection and correlation. The solution supports near real-time log collection, built-in analytics and workbooks, ASIM-based security content, and correlation with signals from endpoints, Microsoft Entra ID, and other sources in Microsoft Sentinel. MailRisk data connector for Microsoft Sentinel MailRisk data connector for Microsoft Sentinel brings suspicious email data analyzed by users through Secure Practice MailRisk into Sentinel. The connector ingests enriched email metadata and risk assessment updates from the Secure Practice API, providing potential indicators of compromise identified from reported emails. By incorporating MailRisk data alongside other security telemetry, the integration helps security teams correlate suspicious email activity, search and investigate potential threats, and incorporate user-reported email intelligence into alerting and incident response workflows. SecurityScorecard Ratings for Microsoft Sentinel SecurityScorecard Ratings for Microsoft Sentinel provides cybersecurity posture ratings based on continuously monitored risk factors and threat intelligence. SecurityScorecard evaluates organizations using an A-F rating, helping security teams identify and track cybersecurity risks. The solution supports use cases including enterprise cyber risk management, third-party risk monitoring, executive reporting, and cyber due diligence. SIGNL4 - Mobile Alerting & Response for Microsoft Sentinel and Defender for Cloud SIGNL4 bridges the gap between security detection and human response with mobile-first alerting and incident management for Microsoft Sentinel and Defender for Cloud. Its two-way integrations allow security teams to acknowledge, escalate, and resolve incidents directly from their mobile devices, with updates automatically synchronized back to Sentinel. Critical Defender for Cloud findings trigger actionable response workflows, while persistent mobile notifications, automated escalations, and on-call scheduling ensure the right people are reached when it matters most. The result is faster incident response, clear accountability, and a fully auditable process - wherever responders are. SOC Prime Audit CCP SOC Prime Audit CCP brings SOC Prime Platform audit logs into Microsoft Sentinel for centralized security monitoring and analysis. The connector ingests platform activity including user actions, API calls, and administrative events, providing an audit trail across detection engineering processes. By correlating SOC Prime activity with other security signals in Sentinel, the integration helps security teams investigate platform activity, support compliance monitoring, and incorporate audit telemetry into broader threat detection and response workflows. SOCRadar Alerts Azure Sentinel Directional Solution SOCRadar Threat Intelligence for Microsoft Sentinel enriches security operations by bringing prioritized, context-rich alerts directly into Microsoft Sentinel. Covering SOCRadar’s Extended Threat Intelligence capabilities, including Brand Protection, External Attack Surface Management (ASM), Third-Party Findings, and other security modules, the integration helps organizations monitor external threats and manage investigations within their existing SOC workflows. Bidirectional synchronization also helps keep incident status, severity, and comments aligned between Microsoft Sentinel and SOCRadar. SpyCloud Enterprise Protection for Microsoft Sentinel SpyCloud Enterprise Protection for Microsoft Sentinel brings stolen identity data from infostealer malware, phishing attacks, and third-party breaches into Microsoft Sentinel, helping security teams uncover compromised identities, prioritize high-risk exposures, and accelerate remediation to prevent session hijacking and other targeted identity-based attacks. The solution includes a custom API connector, a Logic Apps playbook for ingesting data into Log Analytics, analytic rules that generate Sentinel incidents from breach and malware data, and additional Logic Apps playbooks for incident automation and enrichment. Tenable App for Microsoft Sentinel Tenable App for Microsoft Sentinel brings asset and vulnerability data from Tenable One Vulnerability Management into Sentinel for centralized security analysis. The integration combines Tenable cyber exposure insights with Sentinel’s collection, detection, and investigation capabilities, making vulnerability context available alongside other security telemetry. By incorporating asset and vulnerability findings into Sentinel workflows, the solution helps security teams correlate exposure data with security signals, investigate risks affecting vulnerable assets, and better prioritize remediation efforts. Uniqkey Security Events for Microsoft Sentinel Uniqkey Security Events for Microsoft Sentinel brings authentication, credential access and management, sharing, administrative activity, and platform threat detections into Microsoft Sentinel using the Codeless Connector Framework (CCF). Included analytics rules identify scenarios such as sign-ins from unfamiliar IP addresses, excessive credential access, data exports, and security policy or privilege changes. A workbook visualizes activity and threat detections, helping security teams monitor password-management activity, investigate potential credential risks, and correlate findings with broader security telemetry. Utimaco Enterprise Secure Key Manager Utimaco Enterprise Secure Key Manager (ESKM) integrates with Microsoft Sentinel to provide centralized security monitoring and visibility into cryptographic key management activities through KMIP server logs. The solution enables organizations to monitor key operations, KMIP client activity, and authentication events, helping security teams identify suspicious behavior and investigate potential threats. Built-in analytics rules help detect brute-force authentication attempts, repeated permission-denied events, and key-destruction activity, while hunting queries and a dedicated workbook support deeper investigation of unusual users, source IPs, key retrieval patterns, and after-hours activity. valimail-sentinel-enforce Valimail enables organizations to see who sends email using your domain, protects against domain impersonation, and displays a verified logo in inboxes to increase brand trust. Our Microsoft Sentinel Connector brings Valimail Enforce event data directly into Sentinel, allowing security teams to incorporate our telemetry into unified SIEM workflows, monitor authentication and enforcement trends in real time, and build custom alerts and visualizations based on DMARC events. Once configured, Sentinel continuously ingests Valimail event logs, enriching your broader security intelligence and helping to improve your ability to detect and respond to threats across your environment. Varonis for Sentinel Solutions Varonis for Sentinel Solutions brings enriched, data-centric Varonis alerts into Microsoft Sentinel for triage, investigation, and remediation. Varonis insights are contextualized alongside other security events to provide a unified view of data risk. This allows security teams to view and close Varonis alerts directly within Sentinel, reducing the need to switch interfaces and supporting incident resolution with less manual effort Whisper for Sentinel Whisper for Sentinel enriches Microsoft Sentinel incidents and alerts with threat and infrastructure intelligence for IPs, domains, ASNs, and networks. The solution provides threat scores, supporting evidence, infrastructure relationships, and historical context directly within Sentinel. Included enrichment playbooks, analytics rules, hunting queries, and workbooks support investigation of threats including C2 communications, malicious infrastructure, suspicious domains, and BGP anomalies, while retained enrichment data can be queried and correlated with existing logs. WhoisFreaks Threat Intelligence for Microsoft Sentinel The WhoisFreaks solution for Microsoft Sentinel brings domain threat intelligence and newly registered domain (NRD) data into Sentinel using the Codeless Connector Framework (CCF). Customers can connect malware, phishing, and spam threat feeds, along with gTLD and ccTLD NRD feeds with or without WHOIS data. Included analytics rule templates help identify high-confidence malicious domains, newly registered domains appearing in threat feeds, threat-listed parked domains, and unusual NRD volumes that may indicate bulk registration activity. Wiz for Microsoft Sentinel Wiz for Microsoft Sentinel brings Wiz Issues, Vulnerability Findings, and Audit logs into Microsoft Sentinel. Wiz identifies and prioritizes cloud security risks across areas including vulnerabilities, malware, internet exposure, identity, and data security in AWS, Azure, Google Cloud, OCI, Alibaba, and Kubernetes environments. In addition to the solutions from our third-party partners, we are also excited to announce the following connectors published by the Microsoft Sentinel team: Agari Solution Akamai DDOS Protection Alibaba Cloud Networking Atlassian Organization Audit AWS Elastic Kubernetes Service AWS Elastic Load Balancing Cisco Cloud Security Cisco Meraki Events via REST API Crowdstrike Falcon Endpoint Protection Elastic Agent Solution Imperva WAF Cloud Solution Microsoft Copilot Microsoft Dragon Copilot Mulesoft CloudHub Alerts OpenAI Qualys VM Knowledgebase Rapid7 InsightVM CloudAPI SentinelOne TheHive Solution Trellix Enpoint Security Trend Micro Cloud App Security VMware Workspace ONE Zoom Reports Building a more connected foundation for security operations The strength of the connector ecosystem reflects the work of Microsoft and our technology partners to support our shared customers. Together, we are helping organizations connect the technologies they rely on and bring more of their security data into a unified operational experience. For customers If you are a Microsoft Sentinel or ISOC customer, or considering adopting it, we want you to have the security connectors and integrations you need to get value from the platform. If an integration with an independent software vendor (ISV) is not yet available, or you have an issue with an existing solution, we have a dedicated team that may be able to assist by working with ISVs to build new or update existing connectors. For software companies If you are a software development partner, the Microsoft Sentinel Codeless Connector Framework (CCF) provides a streamlined way to bring your product into the Microsoft Security ecosystem. Partners can also work directly with Microsoft for engineering guidance and support to build or improve a connector. Building a more connected foundation for security operations Our goal is simple: help customers protect their digital environments by giving human defenders and AI agents a more complete picture of risk. We’ll continue investing in connectors, partnerships, and integrated security experiences to help customers defend their organizations with greater visibility, context, and confidence. Learn More Microsoft Sentinel What is Microsoft Sentinel Empower Real-Time Security with Microsoft Sentinel’s CCF Push Feature | Microsoft Community Hub Growing our connector ecosystem with 500+ Microsoft Sentinel connectors Microsoft Defender ISOC in Microsoft Defender Microsoft Sentinel connector hands-on labs Building Microsoft Sentinel Connectors in Minutes with the Sentinel Connector Builder Agent Building a CCF Nested API Pull Connector: A Technical Lab Walkthrough Microsoft Sentinel features in public preview Accelerate connectors development using AI agent in Microsoft Sentinel | Microsoft Community Hub Extending Sentinel Data Integration: Azure Blob Storage Support for CCF Connectors | Microsoft Community Hub Public Preview: Nested API Support Comes to Microsoft Sentinel CCF | Microsoft Community Hub Public Preview: Multi-Account Support for Microsoft Sentinel Codeless Connectors | Microsoft Community Hub Manage all your Microsoft Sentinel data in one place with Unified Data Management (Public Preview) | Microsoft Community HubThe CISO Cheat Sheet to Microsoft Digital Defense Report 2026
I know we’re all busy, so I’ve pulled the most important data from this year’s Microsoft Digital Defense Report into one short read. The full report is well worth exploring, but this article focuses on the numbers and trends most relevant to security leaders. This year’s edition shows that AI is lowering the time, expertise and cost required to discover and exploit weaknesses, enabling attackers to operate with greater speed, scale and autonomy. The report describes this as AI “changing the physics of cybersecurity”: attack timelines are compressing and agentic systems are beginning to automate more of the attack lifecycle. Trend 1: Time has collapsed The clearest finding is about speed. Vulnerability discovery is increasingly running ahead of remediation, while the time from discovery to weaponisation is shrinking. In the AI era, weaponisation can follow in hours. Vulnerability discovery and weaponisation now often needs only a well-written prompt. The median time from discovery in the wild to weaponisation is below 24 hours. Vulnerabilities were on track for a record estimated 72,000 CVEs in 2026. The report expects a multi-year period in which the number of known but unpatched vulnerabilities rises sharply before eventually declining. The median time from container start to first exploit attempt is 5.3 hours. The ransomware actor Storm-1175 moved from web-facing exploitation to deploying Medusa ransomware in as little as 24 hours. CISA added over 110 CVEs to its Known Exploited Vulnerabilities catalogue between November 2025 and May 2026, most within a week of disclosure. The mismatch with enterprise reality is the uncomfortable part. The report says the disclosure-to-exploitation window has shrunk to single-digit days. Between November 2025 and May 2026, CISA added more than 110 vulnerabilities to its Known Exploited Vulnerabilities catalogue, most within a week of disclosure. In one example, Storm-1175 moved from exploiting a web-facing vulnerability to deploying Medusa ransomware in as little as 24 hours. Microsoft’s Red Team makes an important point: a patch is also a disclosure. Every fix points attackers towards the flaw it closes. As AI-assisted analysis makes reversing patches faster and more reliable, the report argues that patch velocity, not simply patch availability, becomes the control that matters. Trend 2: Attack chains are gaining autonomy The report charts a clear progression: September–November 2025: AI assists in orchestrating a campaign, as in the Anthropic-reported espionage case. April–June 2026: Full-chain autonomy is demonstrated in labs. July 2026: Real-world autonomous attacks of increasing complexity appear. Two frontier models, Mythos and GPT-5.5, completed a 32-step attack chain against an emulated enterprise with no human help. The test environment had no defenders. The UK AI Security Institute reached a similar finding independently. GPT-5.5 was the second model to solve its end-to-end corporate network attack simulation, a task AISI estimates would take a human about 20 hours. Open-weight models lag closed models at orchestrating attacks by about seven months. In the wild, early July 2026 saw the first documented automated ransomware extortion attack, named JADEPUFFER by Sysdig. Microsoft has seen AI-orchestrated intrusions that share elements with it. Initial access consistently came from internet-exposed services running known-vulnerable software. The report is measured on this point. Volumes of AI-orchestrated activity remain low. In most observed real-world operations, complex end-to-end intrusions still retain meaningful human direction. The Red Team's framing is the most useful one: AI doesn't create a new class of attack, it collapses the effort needed to find and exploit existing attack paths. Trend 3: AI has become an attack surface The report's second takeaway is that attackers are already targeting AI itself. The adoption numbers explain why. 88% of enterprises are experimenting with agents, and 82% of leaders plan broader rollouts within 12–18 months. The report cites industry projections of roughly 1.3 billion agents in production by 2028. What attackers are doing to AI systems: Four techniques accounted for roughly 90% of observed attack activity in telemetry from Azure AI workloads: malicious link injection (52%), jailbreaks (16%), tool and agent abuse (12%), and identity and credential abuse (10%). Memory poisoning: An attacker who can place content anywhere an agent reads can often place it where the agent remembers. Email is the dominant pathway the Red Team has observed. Human-in-the-loop isn't a complete control: Red team testing saw approval prompts ignored, or bypassed by a policy stored in poisoned memory. Developer tools turned against their owners: The "s1ngularity" malware hijacked locally installed AI command-line tools to hunt for secrets. It leaked about 2,000 secrets and 20,000 files across 225 victims. AI browsers: In daily use at more than 40% of organisations in Microsoft's dataset, they were the initial infection vector in incidents involving 57 malware families in a May 2026 analysis. Chat histories as a target: Malicious AI-assistant extensions reached nearly 900,000 installs and more than 20,000 enterprise tenants, harvesting AI chat histories that often contain code, architecture and credentials. The identity implications are direct. Each agent needs its own identity, not one borrowed from an employee, and a named human sponsor. The report also treats revocation latency, the time to cut off a compromised agent, as a measured outcome. Trend 4: The front door is still identity AI changes the speed and personalisation of social engineering. It hasn't changed where attacks start. Initial access in Defender Experts data: User execution: 30% Valid accounts: 20% Malicious copy-and-paste: 13% Phishing: 11% Together, user execution and valid accounts account for over half of observed activity. In incident response engagements, phishing as an initial access vector jumped from 7% to 23% year on year. The standout numbers: ClickFix: Defender saw user-pasted malicious commands on more than 1.1 million unique devices between February and early May 2026, roughly an 8x increase. AiTM: URLs accounted for 45% of the identified phishing techniques in the report’s breakdown. Separately, the share of AiTM phishing and token-theft attacks more than doubled during the first six months of 2026, although the report notes that their overall share remained comparatively small. Teams vishing: Weekly confirmed malicious volume increased 502% year on year. Per attempt, 48% of vishing calls kept the victim engaged for more than 20 seconds, and 30% lasted more than one minute. When a call succeeds, attackers can persuade the victim to install a remote-management tool and complete reconnaissance in two minutes or less. Business contact impersonation (BCI): The report introduces this term for conversations that start with a trusted-looking contact. Microsoft detected more than 46 million attacks in 12 months, with a 121% spike in April 2026. The share of first-contact messages that explicitly asked for money or documents fell from 17% to 3%. The first message is deliberately bland, like "Are you at your desk?" Password attacks declined 26% year on year, which the report describes as strong evidence that MFA and passkeys are forcing attackers to pivot. That pivot includes techniques such as fatigue attacks, AiTM phishing and token theft designed to circumvent conventional MFA. Trend 5: Attackers are inheriting trust rather than breaking in The report's headline theme is that risk is increasingly interconnected. Threats travel through the trusted relationships between identities, software supply chains, partners and cloud platforms. The numbers: Supply chain: Major open-source ecosystems saw attacks roughly every ten days, accelerating through Q2 2026. Shai-Hulud 2.0 affected 25,000 repositories. Megalodon backdoored 5,561 GitHub repositories in under six hours. Trusted signing: In May 2026, Microsoft disrupted Fox Tempest, a "malware-signing-as-a-service" operation that obtained genuine certificates for ransomware loaders and infostealers. Microsoft revoked over a thousand fraudulent code-signing certificates. Legitimate access: An unsanctioned remote monitoring tool is now one of the most reliable mid-stage indicators of a human-operated intrusion. Cloud identity: Cloud identity abuse was the most observed technique against critical infrastructure, representing 78% of the technique mix in Microsoft’s data for March to June 2026. Hybrid intrusions: The Storm-2885 case showed an attacker using a privileged cloud identity to close and downgrade security alerts. The report says identity governance and alert-handling workflows deserve Tier 0 treatment. Dwell time: DART data shows a statistically significant increase in dwell time year on year, meaning organisations took longer to detect intrusions. Ransomware shows the same ecosystem pattern. Qilin led leak-site data with 16.4% of victims, up 386%. Defender detections tell a different story, with Akira at 22%. Trend 6: Defence works best when it's connected The report is not only a catalogue of threats. The strongest defensive evidence: Disruption works. Following the March 2026 disruption, Tycoon2FA activity had fallen 95% from its November 2025 peak by June. Its share of CAPTCHA-gated phishing declined from 76% in December 2025 to 12% in June 2026. Correlation is the highest-leverage variable. The report argues that how well defenders share and correlate signals across endpoint, identity, cloud, email and network is one of the highest-leverage strategic variables under their control. AI is also changing defensive operations. The report describes AI-assisted triage, incident summarisation, hunting-query generation and detection engineering as ways to accelerate investigations and allow analysts to concentrate on higher-value work. Automated disruption can compress response time. The report says that when a correlated incident reaches a defined confidence threshold, defensive systems can automatically isolate devices, disable compromised accounts, revoke sessions or quarantine affected cloud resources. It also stresses the importance of appropriate governance and human oversight for high-risk AI actions. The report also recommends changing what leaders measure. It suggests moving from patches deployed to exposure reduced, detection coverage increased and time-to-mitigate compressed. What the MDDR recommends: ten security priorities The report starts its recommendations with the foundations: Secure by Design, Secure by Default and Secure Operations, applied through identity-centric Zero Trust. Microsoft says these keep the priorities below durable as AI adds more identities, applications, agents and dependencies to govern. Govern cyber risk at leadership level. Report identity exposure, patch latency, agent permissions, critical dependencies, dwell time and recovery readiness to the board. Defend identity as the primary control plane. Deploy passkeys and phishing-resistant MFA, reduce privilege and govern human and non-human identities. Invalidate and rotate tokens and session credentials quickly. Establish governance, visibility and data controls for AI. Keep visibility of approved AI tools, services and agents, and monitor for unauthorised or unmanaged use. Apply sensitivity-aware access and data protection to the data those systems can reach. Reduce exposure and edge risk. Continuously discover internet-facing assets and patch edge devices quickly. Centralise high-fidelity logging, enforce strong authentication and combine network visibility with threat intelligence. Focus on cross-signal correlation. Correlate endpoint, identity, cloud, application, email and network signals to detect intrusions earlier. Correlation also helps defenders anticipate attack paths and likely targets. Enact a continuous threat and vulnerability management model. Combine asset visibility, vulnerability identification, threat detection and AI-accelerated insight into a single continuous programme. Validate exposure through proactive testing. Run assume-breach exercises on cloud services, SaaS platforms, APIs and workflow automation. Prioritise them by where your highest-value data is stored, accessed or aggregated. Secure software dependencies. Harden software installation, keep a software inventory and validate provenance. Monitor packages and prepare for rapid containment. Participate in collective defence. Share actionable threat indicators and victim-informed intelligence with trusted partners and law enforcement. This supports coordinated tracking, investigation and disruption. Prepare for long-horizon technology transitions. Build a cryptographic inventory and advance post-quantum planning alongside AI governance. Read together, the numbers tell one story: the attacker’s workflow is becoming faster and less expensive. AI can shorten vulnerability discovery, exploitation, secret discovery and lateral movement, while organisations still face the slower operational work of testing, coordinating and deploying safe changes across complex environments. At the same time, agent identities can proliferate faster than organisations can inventory, govern and revoke them The defining question for boards today is not whether disruption will occur, but whether the organization can continue operating, contain harm, recover quickly, and maintain trust when it does. Source: Microsoft Digital Defense Report 2026, Version 1.1. Reporting period: July 2025–June 2026.
From Automation to Intelligence: Logic Apps + Functions + GenAI
Traditional automation excels at “When this happens, do that.” But what if a workflow also needs to interpret context, condense information, or suggest what to do next? That’s where combining Azure Logic Apps, Azure Functions, and generative AI gets interesting. Here’s how I think about their roles: - Logic Apps coordinate Connect services, oversee workflow steps, and determine what happens next. - Azure Functions process Run custom logic, validate data, transform it, and handle specialized tasks. - GenAI interprets and creates Make sense of unstructured information, summarize content, categorize inputs, and offer recommendations. A basic workflow might look like this: Business Event ↓ Logic App ↓ Azure Function ↓ GenAI ↓ Validation / Human Review ↓ Action Example: Smarter Incident Triage Picture an alert from a production system: The Logic App receives the alert and collects relevant context. The Azure Function handles the technical data. GenAI summarizes the problem and proposes potential next steps. The Logic App sends the recommendation for validation or human approval. Once approved, the action is carried out. The key point? AI doesn’t need to take the place of rule-based automation. It can add intelligence to the automation you already have. My straightforward architecture guideline: 🔄 Logic Apps: What comes next? ⚙️ Functions: What needs to be processed? 🧠 GenAI: What does this information tell us? 👤 Human: Is this action the right one to take? 💬 What’s your view? Are you using GenAI to assist with existing Azure workflows, or shifting towards automation that’s more AI-driven?
Microsoft Defender Offline scan: BitLocker recovery prompt and missing scan results on Windows11 Pro
Microsoft Defender Offline scan not completing or recording results — Windows 11 Pro I need help fixing Microsoft Defender Offline and verifying that scans complete successfully. History: Initially, starting an Offline scan rebooted Windows, but no scan screen appeared. The process lasted less than a minute on a laptop with 1 TB of storage. No result appeared in Protection history. SFC and DISM reported no system corruption. Windows repair failed with error 0xC1900101–0x20017; factory reset also failed. During clean installation, a technician changed or repaired something in the BIOS to resolve a storage-partition recognition problem. Windows then installed successfully. BitLocker is enabled on C: and D:. WinRE has since been repaired and enabled. Current behaviour: Defender Offline requests the BitLocker recovery key for C: after reboot. After I enter it, the Defender Antivirus scan screen appears and displays progress. The background also displays “Preparing for recovery.” (?!?!, I ran a scan, not a recovery) Windows starts normally afterward, but no new Offline scan result appears in Protection history. Event Viewer findings (31 October, around 1:52 pm): Event 1000 shows a Quick Scan started by scheduled maintenance. Event 1002 shows the same scan stopped before completion, with reason “RPC connection rundown.” I did not schedule or run a Quick Scan; I initiated only Defender Offline at that time. Other events around the same time include 1150, 1151, 1152, and 5007. Theee is also an event 2030 at 12:51pm, when I ran the offline scan for the first time today. Questions: Why do the events report a scheduled Quick Scan when I initiated Defender Offline? How can I fix this and verify that Offline scans complete successfully? Could BitLocker, WinRE, TPM, Secure Boot, or the previous BIOS repair be involved? I want to resolve this without reinstalling Windows if possible. Microsoft Support case: 7110599710.
MC1457836 vs docs: Sentinel in unified RBAC with a service principal or GDAP. Which is it?
This is about the article https://learn.microsoft.com/en-us/defender-xdr/activate-defender-rbac, which states: Assigning permissions to a service principal or to a GDAP user group in Microsoft Sentinel isn’t supported in unified RBAC. If you need either capability, don’t activate Sentinel in unified RBAC yet. Continue using Azure RBAC for Microsoft Sentinel. Message center notice MC1457836 announces that Microsoft automatically enables unified RBAC on all tenants between late September and late December 2026, including Sentinel Reader, Responder and Contributor workspace permissions. These two statements cannot both be followed. The article tells affected customers not to activate Sentinel; MC1457836 activates it for them. This is not hypothetical for MSSPs. We operate a managed XDR service across roughly 25 customer tenants. Both unsupported capabilities are load-bearing in that model: A service principal holds Microsoft Sentinel Contributor through Azure Lighthouse and deploys analytics rules via ARM (Microsoft.OperationalInsights/workspaces/providers/alertRules). GDAP user groups are the standard delegated access route for partners. Could this be clarified: Does the service principal and GDAP limitation also apply to tenants activated through the MC1457836 automatic rollout, or does that path behave differently? If it does apply, what is the recommended action for tenants that are auto-activated before the limitation is lifted? Is deactivating the Sentinel workload after activation the supported mitigation, and is it expected to fully restore Azure RBAC behaviour for a service principal? Can a tenant be excluded from automatic Sentinel activation in advance, rather than only opting out afterwards? The article also warns that changing permissions in the Azure portal after Sentinel is active in unified RBAC may cause sync errors. For Lighthouse-delegated permissions, which are managed outside the customer tenant entirely, is that a supported configuration once Sentinel is active? A note in the “Before you begin” section describing how this limitation interacts with the automatic rollout would help partners decide whether to pre-emptively opt out.More security around using Custom Script Extensions and Session Host Configuration
We are currently implementing and testing the new Session Host Configuration and Session Host Management features. We rely on Custom Script Extensions to implement some functionality immediately to the newly deployed Session Hosts instead of waiting for GPOs or other to take effect. We don't add these changes to the golden images. Currently the Custom Script Extensions functionality definable in the Session Host Configuration only allows to define a script URL. What is the intended mechanism of authentication for this solution? Currently it seems that its only possible to use an anonymous access level Blob. Defining a token within the script URL is not great due to the fact that the URL is viewable in plain text via the Azure Portal. Neither of those will satisfy. Key vault references are used when defining credentials for domain join and local admin accounts for the Session Hosts. Would it be possible to have key vault references for CSE Storage Account Name/Key or SAS token or the possibility to define a Managed Identity instead. These can be defined when deploying the CSEs manually. Please guide me as to what the best solution would be to this topic. Many thanks in advance.
Microsoft Defender XDR / Defender for Endpoint data connectors inconsistent failures
Hello, We are deploying our SOC (Sentinel) environments via Bicep. Now the Defender XDR ( MicrosoftThreatProtection) and Defender for Endpoint ( MicrosoftDefenderAdvancedThreatProtection) data connectors are failing to deploy inconsistantly. It seems to be a known issue due to the following posts: - https://github.com/Azure/SimuLand/issues/23 - https://techcommunity.microsoft.com/t5/microsoft-sentinel/quot-missing-consent-invalid-license-quot-defender-for-endpoint/m-p/3027212 - https://github.com/Azure/Azure-Sentinel/issues/5007 Next to this issue I see almost no development on the data connectors API, is there some news to be spread how to enable data connectors automated in the future, since it seems to be moving to Content Hub. It is hard to find any docs about how to deploy this for example via Bicep!? Also I have a question regarding 'Tenant-based Microsoft Defender for Cloud (Preview)' data connector. We deploy this now via GenericUI data connector kind, but this has no option to enable it via automation. Same as the question in the previous paragraph, how would this be made possible?Integrating ServiceNow with Azure DevOps: Use Cases That Actually Show Up in Practice
I have been working in the integration space for quite some time. Though I work as a Content Manager, I am always curious to see how users handle integrations between multiple systems. Usually, the service desk runs on ServiceNow, and the build happens in Azure DevOps. But these tools aren't inherently connected, and someone has to manually relay information between them. So, the records never show consistent data. You need a way for the data to pass automatically between them. Even within this setup, a lot of scenarios come forth: from a single ServiceNow instance connecting to a single Azure DevOps org, up to companies running six or seven orgs off a shared service layer. Here's the full range of use cases I keep seeing, organized by what they're actually solving. Native Tools vs. a Dedicated Integration Layer Before the use cases, it's worth being clear on when you need more than what's built in. ServiceNow's IntegrationHub can push data through flows, and there's a spoke for looking up and creating basic Azure DevOps work items. Azure DevOps also has a native extension for pipeline-to-change-management syncing. These native options work fine when the integration is simple: one team, clean field mappings, developers on hand to maintain it. They start to struggle once you're crossing org boundaries, crossing company lines, or dealing with fields and states that don't line up between the two systems. At that point, a dedicated integration layer that handles the mapping and keeps each side's access separate is usually the better fit. Core Sync Use Cases 1. Sync ServiceNow Requests to Azure DevOps User Stories Current setup: Support or service teams work in ServiceNow. When a request needs development, someone has to get it onto an Azure DevOps board as a User Story. Problem: A person creates the work item by hand, copies the request details, and checks back later for updates. When the work item closes, the ServiceNow request often doesn't reflect that, so the requester never hears back. The two records aren't linked. Solution: A trigger, filtered by assignment group, category, or a manual send action, creates the User Story automatically. The link between the two records gets stored on both sides. Updates to the work item flow back to the request, and closing one side closes the other. 2. Sync Comments and State Back to ServiceNow Current setup: ServiceNow holds the ticket the requester sees. Azure DevOps holds the actual dev work. Problem: When the work item moves in Azure DevOps, the ServiceNow ticket's state doesn't follow. Comments the dev team adds stay in Azure DevOps, so the service team keeps pinging developers for status. Solution: As the work item's state changes, it updates the linked ServiceNow ticket. Comments from the dev side sync back too. The service team sees progress without opening Azure DevOps or chasing anyone. 3. Sync ServiceNow Catalog Items to Azure DevOps Current setup: Users order catalog items in ServiceNow. Fulfilling some of them takes real development work tracked in Azure DevOps. Problem: The catalog task sits in ServiceNow while the work happens somewhere the requester can't see. Someone bridges the two manually, and the catalog item's status stops meaning anything. Solution: The catalog item creates a matching work item in Azure DevOps with the request details attached. As the dev team works, status and comments sync back, so the catalog task shows real progress and closes when the work item does. 4. Cut Duplication Between Incidents and User Stories Current setup: Incidents land in ServiceNow. Some get tracked as User Stories in Azure DevOps so the dev team can work them alongside the rest of the backlog. Problem: The same information gets documented twice, updated twice, and the two records drift apart over time. Solution: Incidents create linked User Stories automatically, with comments and status syncing both ways. Update one side and the other reflects it, so nobody's working the same incident twice without realizing it. 5. Sync Bugs with Attachments Across Multiple Orgs Current setup: Bugs get raised in ServiceNow, often by a separate first-line support team, while product teams work across several distinct Azure DevOps orgs. Problem: Recreating bugs by hand loses attachments and context, and there's no clean way to route each bug to the right org out of several. When a bug's fixed, ServiceNow doesn't hear about it. Solution: A bug creates a matching Bug work item in the correct Azure DevOps org, attachments included. Status and comments flow back to ServiceNow when it's resolved. Each connection runs independently, so the first-line team stays in ServiceNow without needing access to the other side. 6. Project-to-Hypercare Handover Current setup: During a build, everyone works in Azure DevOps. Once it goes live and moves into maintenance, incidents and requests need to land in ServiceNow, sometimes a brand-new instance. Problem: Teams used to living in Azure DevOps now need a maintenance process in ServiceNow, with no link back to the developers who built the thing. Solution: Incidents raised during hypercare reach the dev team in Azure DevOps, and fixes flow back to ServiceNow. Because the connection is independent of either team's existing workflow, you can add it without disrupting how people already work. 7. Bidirectional Field and Lifecycle Sync Current setup: A demand owner in ServiceNow needs to track a Feature as it moves through scoping, active work, testing, and deployment in Azure DevOps. Problem: If effort, status, and assignment only live in Azure DevOps, the ServiceNow record goes stale. Fields on each side use different names and values, so a raw pass-through just creates mismatches. Solution: Key fields sync in both directions with explicit mappings. From Azure DevOps: iteration path, change reference, estimated effort, assignment, and lifecycle status. From ServiceNow: design documents, portfolio area, demand type, and requirement details. As the Feature moves through its stages, the ServiceNow record updates in real time. 8. Multiple Azure DevOps Orgs to a Central ServiceNow Instance Current setup: Each business unit runs its own Azure DevOps org, often from an acquisition or separate supplier setup. A central ServiceNow layer needs visibility across all of them without forcing a shared workflow. Problem: Without a sync, someone manually pulls data between systems and chases updates. It doesn't scale as orgs get added. Solution: Each org gets its own connection, configured independently, feeding the central ServiceNow instance. Every org keeps its own states and fields while leadership gets a single view across all of them. 9. Selective Field Sharing Between Separately Hosted Environments Current setup: One side runs cloud-hosted, the other on-prem or in a regulated environment, and neither can open full network-level access to the other. Problem: A basic integration either oversprays fields it shouldn't, or requires a network connection security won't approve. Each side wants control over exactly what leaves its environment. Solution: Outgoing and incoming rules configured independently on each side let each admin decide what leaves and what gets accepted. The two environments sync over a secured channel without either side getting direct access to the other's system. 10. Handling Closed and Read-Only Tickets Cleanly Current setup: ServiceNow access controls block updates to closed incidents. Your sync runs across tickets through their full lifecycle, including closure. Problem: A basic sync throws errors every time it tries to write to something already closed. Solution: Filter closed tickets out of the sync entirely so they never trigger a write, or let the errors surface where your team can see and review them. Which approach you pick is a team decision, not a technical constraint. 11. MSP Routing by Assignment Group Current setup: An MSP runs ServiceNow as its operational layer. Clients work in their own delivery tools, some in Azure DevOps, some elsewhere. Manual handoffs work for a couple of clients and fall apart past a handful. Problem: An engineer resolves an incident and forgets to update the client's system. A comment added on one side never reaches the other. Status shows "in progress" on one side long after it's resolved on the other. As client count grows, the gap between what your team knows and what clients see widens. Solution: An automated rule sends each incident to the right client system based on the ServiceNow assignment group. Set a filter (for example, database issues route to one client's system, network issues to another), and connections run independently with no crossover between clients. The original incident reference gets written into the client ticket, and status values map across cleanly. A couple of related patterns worth knowing: Internal notes can be filtered separately from customer-facing updates, so only what the client should see crosses over. A new client typically reuses your existing ServiceNow authentication, so onboarding is closer to registering their system and setting a routing rule than rebuilding the integration from scratch. 12. Conditional Escalation from Multiple ServiceNow Instances Current setup: Several ServiceNow instances feed a single Azure DevOps org. Only tickets that genuinely need developer attention should reach the board. Problem: Escalating everything floods the board with tickets the dev team shouldn't be handling. Solution: A conditional trigger escalates only tickets meeting a specific condition, so agents push what actually qualifies and everything else stays put. Multiple instances can each feed the same Azure DevOps org under their own trigger logic. 13. Demand Management to Feature Delivery Current setup: A demand process runs in ServiceNow end to end: submission, review, approval, and an approved Requirement. The build happens in Azure DevOps as a Feature, through scoping, active work, testing, deployment, and closure. Problem: Once a Requirement's approved, there's no automatic handoff. Someone recreates the Feature by hand and keeps both sides updated manually. The demand owner can't see effort, status, or assignment as work progresses, so the Requirement goes stale. When the Feature closes in Azure DevOps, the Requirement stays open until someone remembers to close it. Solution: A bidirectional sync connects the full flow. Feature creation: A Requirement creates a Feature automatically, carrying demand context (design sign-off, demand reference, portfolio area, stakeholders, description) so developers get what they need without opening ServiceNow. Field sync: Updates flow both ways, each field mapped to a specific direction. Azure DevOps to ServiceNow: iteration path, change reference, effort, priority, assignment, lifecycle state. ServiceNow to Azure DevOps: the demand and design fields above. Lifecycle feedback: As the Feature moves through its stages, effort, status, and assignment feed back into the Requirement in real time. Closure: When the Feature closes, the linked Requirement closes with it, and the demand gets marked fulfilled. ServiceNow stays the system of record for demand, Azure DevOps for execution, and each side keeps authority over what it owns. What Actually Makes These Work A few capabilities show up across almost every use case above: Attachment sync. Bugs and incidents depend on screenshots and logs. If attachments don't carry over, developers end up back on email. Custom field mappings. Out-of-the-box mappings only go so far. Real setups need custom fields like portfolio area or demand type mapped explicitly, with values transformed, not just copied. State mappings. ServiceNow states and Azure DevOps states don't share vocabulary. Map them explicitly, and decide upfront which side is authoritative when a state changes after creation. Selective sync. Filter by assignment group, area path, work item type, or a custom field. Fewer records crossing means less to govern and less risk of leaking internal data across a boundary. Security and access. For most Azure DevOps admins, this comes down to what gets checked in a security review anyway: Entra ID or OAuth over shared credentials, role-based access, audit logging, and real isolation between connections when multiple clients or companies are involved. For a single team with clean, one-direction mappings, a native option usually covers it. Once you're crossing orgs, crossing companies, or running a full demand-to-delivery flow with real field transformations, that's when a dedicated integration layer kind of becomes necessary. Let's discuss whether any of these match what you're dealing with, or if you've hit an edge case that isn't on this list.Deploying hosted agents in Foundry Agent Service via Terraform
Background Your Terraform workflow already manages your Azure infrastructure but deploying hosted agents still requires manual SDK calls or REST API scripts. This post shows you how to bring agent deployments into your existing IaC pipeline using the AzAPI provider, so your entire Foundry stack can be versioned, reviewed, and deployed together. For this post we will focus on leveraging Foundry Hosted Agents. At a high level hosted agents will abstract the overhead of managing your agents compute. Conceptually, think of taking the compute today, that might be in Azure Container Apps (ACA) or Azure Functions and moving it into Foundry. For more information can check out my previous blog on this topic. In this example Foundry runs the agent code on managed compute from a container image. For this specific example we need to use Azure Container Registry to house our code artifact. If wanting to deploy directly from source refer to my previous blog Deploying Foundry Hosted Agents from Source Why an Infrastructure as Code Approach? Hosted agents today in Foundry support SDK and REST API deployments, why should we look at leveraging an IaC provider to handle our agents today? Many organizations subscribe to an IaC strategy for managing their Azure Resources. A hosted agent, at its core, is configuring and allocating infrastructure resources behind Foundry. This would be similar to how we configure plan sizes for products like App Services. Additionally, anything defined by IaC makes it easier to version the configuration in source control and incorporate it into repeatable CI/CD pipelines. Production workflows should also account for remote state, approval controls, and image-version promotion. Another added benefit for anything under IaC is the ability to apply custom policies, Azure or otherwise, over the codebase. Prerequisites An Azure subscription with permission to create resources and role assignments. Access to a region and model deployment with sufficient quota for Foundry Hosted Agents. Azure CLI, Terraform, Git, and Docker installed. Docker must support building linux/amd64 images. Permission to push images to Azure Container Registry and create agents in the Foundry project. The provided sample creates or configures the supporting Azure Container Registry, Foundry account and project, model deployment, managed identity, project connection, and hosted-agent deployment. Hosted agents require a Linux AMD64 (linux/amd64) container image. When building from an ARM-based workstation, including Apple Silicon, explicitly target linux/amd64 and ensure Docker cross-platform emulation is available. See Microsoft’s hosted-agent container requirements. docker build --platform linux/amd64 -t <registry-name>.azurecr.io/<image-name>:<tag> To get started quickly I have a repository w/ all the prerequisites and reviewed code at simple-hosted-agent-deploy-azapi Deploy the Sample To deploy the sample: Clone the repository and reopen it in the included development container. Authenticate to Azure and select the target subscription. Copy and update the example Terraform variable files with your environment-specific values. Run the included deployment script to provision the base resources, build and push the container image, and create the hosted agent. Confirm that the generated agent version reaches an active state before invoking it. Refer to the repository README for the current commands, configuration values, and cleanup steps. Process Overview Let’s level set on what our end-to-end process may look like. In many large organizations, the agent deployment process could be decoupled from the Foundry base architecture. Components such as the Foundry account, project, connections, and model may be controlled by a centralized team. These shared components often follow a different deployment lifecycle from an individual agent. A development team may own the code. We need the code to deploy the hosted agent. Quite the chicken-and-egg problem. So let’s break it down from a day 1 perspective: Deploy Foundry Base Architecture Foundry Account Foundry Project Model Project Connection Application Insights Build and Push code to Azure Container Registry Deploy the hosted agent pointed to the image defined in Azure Container Registry For this example, I assume that Azure Container Registry is managed outside the Foundry lifecycle because many organizations prefer to consolidate container images into a smaller number of shared registries. For illustration purposes, the provided example includes the registry deployment. Day n perspective would potentially look like: Build and Push code to Azure Container Registry Deploy the hosted agent pointed to the image defined in Azure Container Registry Updating the hosted-agent configuration creates a new agent version under the existing logical agent. Foundry manages the version history, while Terraform manages the logical agent configuration represented by the azapi_data_plane_resource. After each deployment, confirm that the new version reaches an active state before directing workloads to it. Technical Details At this time, let’s take a minute and discuss some of the technical details around how the hosted agent is created in Foundry. The Foundry project and its connections are Azure Resource Manager control-plane resources. The logical agent is created through the Foundry project’s data-plane API, while Foundry manages the supporting deployment resources required to host it. This is in contrast to services represented directly as Azure Resource Manager resources, such as App Service (Microsoft.Web/sites) and Azure Container Apps (Microsoft.App/containerApps). Here is a visual that depicts the data plane vs control plane objects: The Foundry project is the agent’s logical parent and provides the data-plane endpoint through which the agent is created. The project itself is deployed as the Azure Resource Manager resource Microsoft.CognitiveServices/accounts/projects Foundry connections can be deployed as Microsoft.CognitiveServices/accounts/projects/connections. In this case, the connection is used for connecting and authenticating to Azure Container Registry. At this point, the project and connection resources can be deployed through AzAPI or Bicep. The next step requires a data-plane call. For Terraform deployments, this operation can be managed declaratively with the AzAPI provider’s azapi_data_plane_resource. Foundry also supports agent deployment through its SDKs and REST API. azapi_data_plane_resource The AzAPI provider’s azapi_data_plane_resource resource is the key component for deploying a hosted agent in Foundry Agent Service through Terraform. Per official MS Learn documentation: Some Azure services expose a separate data plane API—a service-specific HTTPS endpoint where you interact directly with the service rather than through ARM. Examples include the Key Vault secrets API at {vaultName}.vault.azure.net, the Azure AI Search index API at {searchServiceName}.search.windows.net, and the Synapse workspace pipeline API at {workspaceName}.dev.azuresynapse.net. azapi_data_plane_resource bridges this gap by enabling Terraform to manage resources on these data plane endpoints using the same AzAPI provider authentication and lifecycle model. https://learn.microsoft.com/en-us/azure/developer/terraform/concept-azapi-data-plane-framework So how would a terraform implementation for this work? First let’s create the appropriate resource type, name and parent reference, in this case the Foundry Project: resource "azapi_data_plane_resource" "hosted_agent" { type = "Microsoft.Foundry/agents@v1" name = var.agent_name # AzAPI data-plane parents use the endpoint host/path without a URI scheme. parent_id = trimprefix(var.project_endpoint, "https://") …} Now we need to pass in the dedicated parameters as part of the body. To find these parameters refer to the Foundry REST API documentation. body = { name = var.agent_name definition = { kind = "hosted" container_configuration = { image = var.image_uri } cpu = var.cpu memory = var.memory protocol_versions = [ { # The hosted container must implement this Foundry Responses contract. protocol = "responses" version = "2.0.0" } ] environment_variables = merge(var.environment_variables, { AZURE_AI_MODEL_DEPLOYMENT_NAME = var.model_deployment_name }) rai_config = { # Hosted agents require the full policy ARM ID; model deployments use its name. rai_policy_name = var.rai_policy_id } } } For the entire reusable module check out https://github.com/JFolberth/simple-hosted-agent-deploy-azapi/tree/main/simple_agent/azure/infra/modules/hosted_agent Conclusion Hosted Agents in Foundry Agent Service provides a way to run custom agent code on Foundry-managed compute while reducing the operational overhead of managing the underlying hosting infrastructure. By using the AzAPI provider’s azapi_data_plane_resource, teams can incorporate the logical agent deployment into an existing Terraform workflow alongside the Foundry project, model, connections, identity, and container registry resources it depends on. This approach is especially useful when platform and application responsibilities are separated. A platform team can manage the shared Foundry and Azure infrastructure, while application teams independently build, publish, and deploy new versions of their agent container. With the appropriate remote state, access controls, image-versioning strategy, and deployment validation in place, the same pattern can be extended into a repeatable CI/CD workflow for both initial deployment and ongoing agent updates. The linked sample demonstrates this end-to-end pattern, from provisioning the supporting Azure resources and publishing the container image through creating the hosted agent with Terraform. Use it as a starting point, then adapt its state management, access controls, artifact promotion, and validation steps to meet your organization’s production requirements.
