Recent Discussions
Defender for Identity health issues - Not Closing
We have old issues and they're not being "Closed" as reported. Are we missing something or is this "Microsoft Defender for Identity" Health Issues process broken? Thanks! Closed: A health issue is automatically marked as Closed when Microsoft Defender for Identity detects that the underlying issue is resolved. If you have the Azure ATP (workspace name) Administrator role, you can also manually close a health issue.
IdentityLogonEvents - IsNtlmV1
Hi, I cannot find documentation on how the IdentityLogonEvents table's AdditionalFields.IsNtlmV1 populated. In a demo environment, I intentionally "enforced" NTLMv1 and made an NTLMv1 connection to a domain controller. On the DC's Security log, event ID 4624 shows correct info: Detailed Authentication Information: Logon Process: NtLmSsp Authentication Package: NTLM Transited Services: - Package Name (NTLM only): NTLM V1 Key Length: 128 On MDI side however it looks like this: (using the following KQL to display relevant info here: IdentityLogonEvents | where ReportId == @"f70dbd37-af8e-4e4e-a77d-b4250f9e0d0b" | extend todynamic(AdditionalFields) | project TimeGenerated, ActionType, Application, LogonType, Protocol,IsNtlmV1 = AdditionalFields.IsNtlmV1 ) TimeGenerated ActionType Application LogonType Protocol IsNtlmV1 Nov 28, 2025 10:43:05 PM LogonSuccess Active Directory Credentials validation Ntlm false Can someone please explain, under which circumstances will the IsNtlmV1 property become "true"? Thank you in advance
Windows Hello passkeys dialog appearing and cannot remove or suppress it.
Hi everyone, I’m dealing with a persistent Windows Hello and passkey issue in Chrome and Brave and yes this is relevant as they're the only browsers having this issue whilst Edge for example is fine, and at this point I’m trying to understand whether this is expected behavior, a bug, or a design oversight. PS. Yes, I'm in contact with related browser support teams but since they seem utterly hopeless i'm asking here, since its at least partially Windows Hello issue. Problem description Even with: Password managers disabled in browser settings, Windows Hello disabled in Chrome/Brave settings, Windows Hello PIN enabled only for device login, Passkeys still stored under chrome://settings/passkeys (which I cannot delete since its used for logging on the device), The devices are connected to Entra ID but this is not required to reproduce the issue although a buisness account configuration creates a Passkey with Windows Hello afaik. Observed behavior When I attempt to sign in on office.com, Windows Hello automatically triggers a dialog offering authentication via passkeys, even though: I don’t want passkeys used for browser logins, passkeys are turned off everywhere they can be, Windows Hello is intended only for local device authentication. The dialog cannot be suppressed, disabled, or hidden(trust me, i tried for weeks). It effectively forces the Windows Hello prompt as a primary option, which causes problems both personally and in business contexts (wrong credential signaling, misleading users that are supposed to use a dedicated password manager solution insted of browser password managers, enforcing an unwanted authentication flow, etc.). What I already verified Many, many, (too many) Windows registry workarounds that never worked. Dug through almost all flags on those browsers. Chrome/Brave → Password Manager: disabled Chrome/Brave → Windows Hello toggle: off Looked through what feels like almost every related option in Windows Settings. Tried gpedit.msc local rules System up to date Windows Hello configured to use PIN, but stores "passkeys used to log on to this device" Why this is a problem Windows Hello automatically assumes that the device-level Windows Hello credentials should always be available as a WebAuthn authenticator. This feels like a big security and UX issue due to: unexpected authentication dialogs, Inability to controll where and how passkey credential are shared to applications, inability to turn the feature off, no administrative or local option to disable Hello for WebAuthn separately from device login. Buisness users either having issues with keeping passwords in order (our buissnes uses a dedicated Password Manager but this behaviour covers its dialog option) or not having PIN to their devices (when I disable windows hello entierly, since when there is no passkeys the option doesn't appear) Questions Is there any supported way to disable Windows Hello as a WebAuthn/passkey option in browsers, while keeping Hello enabled for local device login? Is this expected behavior from the Windows Hello, or is it considered a bug? Are there registry/policy settings (documented or upcoming) that allow disabling the Windows platform authenticator specifically for browsers like Chrome and Brave? Is Microsoft aware of this issue? If so, is it tracked anywhere? Additional notes This issue replicates 100% across (as long as there are passkeys configured): Windows 11 devices i've managed to get my hands on, Chrome and Brave (latest versions), multiple Microsoft accounts and tenants, multiple clean installations. Any guidance or clarification from the Windows security or identity teams would be greatly appreciated. And honestly if there is any more info i could possibly provide PLEASE ask away.Add Privacy Scrub Service to Microsoft Defender?
Microsoft Defender protects accounts against phishing and malware, but attackers increasingly exploit nuisance data broker sites that publish personal information (names, emails, addresses). These sites are scraped to personalize phishing campaigns, making them harder to detect. I propose a premium Defender add‑on that automatically files opt‑out requests with major data brokers (similar to DeleteMe).
Azure Cloud HSM: Secure, Compliant & Ready for Enterprise Migration
Azure Cloud HSM is Microsoft’s single-tenant, FIPS 140-3 Level 3 validated hardware security module service, designed for organizations that need full administrative control over cryptographic keys in the cloud. It’s ideal for migration scenarios, especially when moving on-premises HSM workloads to Azure with minimal application changes. Onboarding & Availability No Registration or Allowlist Needed: Azure Cloud HSM is accessible to all customers no special onboarding or monetary policy required. Regional Availability: Private Preview: UK West Public Preview (March 2025): East US, West US, West Europe, North Europe, UK West General Availability (June 2025): All public, US Gov, and AGC regions where Azure Managed HSM is available Choosing the Right Azure HSM Solution Azure offers several key management options: Azure Key Vault (Standard/Premium) Azure Managed HSM Azure Payment HSM Azure Cloud HSM Cloud HSM is best for: Migrating existing on-premises HSM workloads to Azure Applications running in Azure VMs or Web Apps that require direct HSM integration Shrink-wrapped software in IaaS models supporting HSM key stores Common Use Cases: ADCS (Active Directory Certificate Services) SSL/TLS offload for Nginx and Apache Document and code signing Java apps needing JCE provider SQL Server TDE (IaaS) via EKM Oracle TDE Deployment Best Practices 1. Resource Group Strategy Deploy the Cloud HSM resource in a dedicated resource group (e.g., CHSM-SERVER-RG). Deploy client resources (VM, VNET, Private DNS Zone, Private Endpoint) in a separate group (e.g., CHSM-CLIENT-RG) 2. Domain Name Reuse Policy Each Cloud HSM requires a unique domain name, constructed from the resource name and a deterministic hash. Four reuse types: Tenant, Subscription, ResourceGroup, and NoReuse choose based on your naming and recovery needs. 3. Step-by-Step Deployment Provision Cloud HSM: Use Azure Portal, PowerShell, or CLI. Provisioning takes ~10 minutes. Register Resource Provider: (Register-AzResourceProvider -ProviderNamespace Microsoft.HardwareSecurityModules) Create VNET & Private DNS Zone: Set up networking in the client resource group. Create Private Endpoint: Connect the HSM to your VNET for secure, private access. Deploy Admin VM: Use a supported OS (Windows Server, Ubuntu, RHEL, CBL Mariner) and download the Azure Cloud HSM SDK from GitHub. Initialize and Configure Edit azcloudhsm_resource.cfg: Set the hostname to the private link FQDN for hsm1 (found in the Private Endpoint DNS config). Initialize Cluster: Use the management utility (azcloudhsm_mgmt_util) to connect to server 0 and complete initialization. Partition Owner Key Management: Generate the PO key securely (preferably offline). Store PO.key on encrypted USB in a physical safe. Sign the partition cert and upload it to the HSM. Promote Roles: Promote Precrypto Officer (PRECO) to Crypto Officer (CO) and set strong password Security, Compliance, and Operations Single-Tenant Isolation: Only your organization has admin access to your HSM cluster. No Microsoft Access: Microsoft cannot access your keys or credentials. FIPS 140-3 Level 3 Compliance: All hardware and firmware are validated and maintained by Microsoft and the HSM vendor. Tamper Protection: Physical and logical tamper events trigger key zeroization. No Free Tier: Billing starts upon provisioning and includes all three HSM nodes in the cluster. No Key Sharing with Azure Services: Cloud HSM is not integrated with other Azure services for key usage. Operational Tips Credential Management: Store PO.key offline; use environment variables or Azure Key Vault for operational credentials. Rotate credentials regularly and document all procedures. Backup & Recovery: Backups are automatic and encrypted; always confirm backup/restore after initialization. Support: All support is through Microsoft open a support request for any issues. Azure Cloud HSM vs. Azure Managed HSM Feature / Aspect Azure Cloud HSM Azure Managed HSM Deployment Model Single-tenant, dedicated HSM cluster (Marvell LiquidSecurity hardware) Multi-tenant, fully managed HSM service FIPS Certification FIPS 140-3 Level 3 FIPS 140-2 Level 3 Administrative Control Full admin control (Partition Owner, Crypto Officer, Crypto User roles) Azure manages HSM lifecycle; customers manage keys and RBAC Key Management Customer-managed keys and partitions; direct HSM access Azure-managed HSM; customer-managed keys via Azure APIs Integration PKCS#11, OpenSSL, JCE, KSP/CNG, direct SDK access Azure REST APIs, Azure CLI, PowerShell, Key Vault SDKs Use Cases Migration from on-prem HSMs, legacy apps, custom PKI, direct cryptographic ops Cloud-native apps, SaaS, PaaS, Azure-integrated workloads Network Access Private VNET only; not accessible by other Azure services Accessible by Azure services (e.g., Storage, SQL, Disk Encryption) Key Usage by Azure Services Not supported (no integration with Azure services) Supported (can be used for disk, storage, SQL encryption, etc.) BYOK/Key Import Supported (with key wrap methods) Supported (with Azure Key Vault import tools) Key Export Supported (if enabled at key creation) Supported (with exportable keys) Billing Hourly fee per cluster (3 HSMs per cluster); always-on Consumption-based (per operation, per key, per hour) Availability High availability via 3-node cluster; automatic failover and backup Geo-redundant, managed by Azure Firmware Management Microsoft manages firmware; customer cannot update Fully managed by Azure Compliance Meets strictest compliance (FIPS 140-3 Level 3, single-tenant isolation) Meets broad compliance (FIPS 140-2 Level 3, multi-tenant isolation) Best For Enterprises migrating on-prem HSM workloads, custom/legacy integration needs Cloud-native workloads, Azure service integration, simplified management When to Choose Each? Azure Cloud HSM is ideal if you: Need full administrative control and single-tenant isolation. Are migrating existing on-premises HSM workloads to Azure. Require direct HSM access for legacy or custom applications. Need to meet the highest compliance standards (FIPS 140-3 Level 3). Azure Managed HSM is best if you: Want a fully managed, cloud-native HSM experience. Need seamless integration with Azure services (Storage, SQL, Disk Encryption, etc.). Prefer simplified key management with Azure RBAC and APIs. Are building new applications or SaaS/PaaS solutions in Azure. Scenario Recommended Solution Migrating on-prem HSM to Azure Azure Cloud HSM Cloud-native app needing Azure service keys Azure Managed HSM Custom PKI or direct cryptographic operations Azure Cloud HSM SaaS/PaaS with Azure integration Azure Managed HSM Highest compliance, single-tenant isolation Azure Cloud HSM Simplified management, multi-tenant Azure Managed HSM Azure Cloud HSM is the go-to solution for organizations migrating HSM-backed workloads to Azure, offering robust security, compliance, and operational flexibility. By following best practices for onboarding, deployment, and credential management, you can ensure a smooth and secure transition to the cloud.Enterprise Strategy for Secure Agentic AI: From Compliance to Implementation
Imagine an AI system that doesn’t just answer questions but takes action querying your databases, updating records, triggering workflows, even processing refunds without human intervention. That’s Agentic AI and it’s here. But with great power comes great responsibility. This autonomy introduces new attack surfaces and regulatory obligations. The Model Context Protocol (MCP) Server the gateway between your AI agent and critical systems becomes your Tier-0 control point. If it fails, the blast radius is enormous. This is the story of how enterprises can secure Agentic AI, stay compliant and implement Zero Trust architectures using Azure AI Foundry. Think of it as a roadmap a journey with three milestones - Milestone 1: Securing the Foundation Our journey starts with understanding the paradigm shift. Traditional AI with RAG (Retrieval-Augmented Generation) is like a librarian: It retrieves pre-indexed data. It summarizes information. It never changes the books or places orders. Security here is simple: protect the index, validate queries, prevent data leaks. But Agentic AI? It’s a staffer with system access. It can: Execute tools and business logic autonomously. Chain operations: read → analyze → write → notify. Modify data and trigger workflows. Bottom line: RAG is a “smart librarian.” Agentic AI is a “staffer with system access.” Treat the security model accordingly. And that means new risks: unauthorized access, privilege escalation, financial impact, data corruption. So what’s the defense? Ten critical security controls your first line of protection: Here’s what a production‑grade, Zero Trust MCP gateway needs. Its intentionally simplified in the demo (e.g., no auth) to highlight where you must harden in production. (https://github.com/davisanc/ai-foundry-mcp-gateway) Authentication Demo: None Prod: Microsoft Entra ID, JWT validation, Managed Identity, automatic credential rotation Authorization & RBAC Demo: None Prod: Tool‑level RBAC via Entra; least privilege; explicit allow‑lists per agent/capability Input Validation Demo: Basic (ext whitelist, 10MB, filename sanitize) Prod: JSON Schema validation, injection guards (SQL/command), business‑rule checks Rate Limiting Demo: None Prod: Multi‑tier (per‑agent, per‑tool, global), adaptive throttling, backoff Audit Logging Demo: Console → App Service logs Prod: Structured logs w/ correlation IDs, compliance metadata, PII redaction Session Management Demo: In‑memory UUID sessions Prod: Encrypted distributed storage (Redis/Cosmos DB), tenant isolation, expirations File Upload Security Demo: Ext whitelist, size limits, memory‑only Prod: 7‑layer defense (validate, MIME, malware scanning via Defender for Storage), encryption at rest, signed URLs Network Security Demo: Public App Service + HTTPS Prod: Private Endpoints, VNet integration, NSGs, Azure Firewall no public exposure Secrets Management Demo: App Service env vars (not in code) Prod: Azure Key Vault + Managed Identity, rotation, access audit Observability & Threat Detection (5‑Layer Stack) Layer 1: Application Insights (requests, dependencies, custom security events) Layer 2: Azure AI Content Safety (harmful content, jailbreaks) Layer 3: Microsoft Defender for AI (prompt injection incl. ASCII smuggling, credential theft, anomalous tool usage) Layer 4: Microsoft Purview for AI (PII/PHI classification, DLP on outputs, lineage, policy) Layer 5: Microsoft Sentinel (SIEM correlation, custom rules, automated response) Note: Azure AI Content Safety is built into Azure AI Foundry for real‑time filtering on both prompts and completions. Picture this as an airport security model: multiple checkpoints, each catching what the previous missed. That’s defense-in-depth. Zero Trust in Practice ~ A Day in the Life of a Prompt Every agent request passes through 8 sequential checkpoints, mapped to MITRE ATLAS tactics/mitigations (e.g., AML.M0011 Input Validation, AML.M0004 Output Filtering, AML.M0015 Adversarial Input Detection). The design goal is defense‑in‑depth: multiple independent controls, different detection signals, and layered failure modes. Checkpoints 1‑7: Enforcement (deny/contain before business systems) Checkpoint 8: Monitoring (detect/respond, hunt, learn, harden) AML.M0009 – Control Access to ML Models AML.M0011 – Validate ML Model Inputs AML.M0000 – Limit ML Model Availability AML.M0014 – ML Artifact Logging AML.M0004 – Output Filtering AML.M0015 – Adversarial Input Detection If one control slips, the others still stand. Resilience is the product of layers. Milestone 2: Navigating Compliance Next stop: regulatory readiness. The EU AI Act is the world’s first comprehensive AI law. If your AI system operates in or impacts the EU market, compliance isn’t optional, it’s mandatory. Agentic AI often falls under high-risk classification. That means: Risk management systems. Technical documentation. Logging and traceability. Transparency and human oversight. Fail to comply? Fines up to €30M or 6% of global turnover. Azure helps you meet these obligations: Entra ID for identity and RBAC. Purview for data classification and DLP. Defender for AI for prompt injection detection. Content Safety for harmful content filtering. Sentinel for SIEM correlation and incident response. And this isn’t just about today. Future regulations are coming US AI Executive Orders, UK AI Roadmap, ISO/IEC 42001 standards. The trend is clear: transparency, explainability, and continuous monitoring will be universal. Milestone 3: Implementation Deep-Dive Now, the hands-on part. How do you build this strategy into reality? Step 1: Entra ID Authentication Register your MCP app in Entra ID. Configure OAuth2 and JWT validation. Enable Managed Identity for downstream resources. Step 2: Apply the 10 Controls RBAC: Tool-level access checks. Validation: JSON schema + injection prevention. Rate Limiting: Express middleware or Azure API Management. Audit Logging: Structured logs with correlation IDs. Session Mgmt: Redis with encryption. File Security: MIME checks + Defender for Storage. Network: Private Endpoints + VNet. Secrets: Azure Key Vault. Observability: App Insights + Defender for AI + Purview + Sentinel. Step 3: Secure CI/CD Pipelines Embed compliance checks in Azure DevOps: Pre-build: Secret scanning. Build: RBAC & validation tests. Deploy: Managed Identity for service connections. Post-deploy: Compliance scans via Azure Policy. Step 4: Build the 5-Layer Observability Stack App Insights → Telemetry. Content Safety → Harmful content detection. Defender for AI → Prompt injection monitoring. Purview → PII/PHI classification and lineage. Sentinel → SIEM correlation and automated response. The Destination: A Secure, Compliant Future By now, you’ve seen the full roadmap: Secure the foundation with Zero Trust and layered controls. Navigate compliance with EU AI Act and prepare for global regulations. Implement the strategy using Azure-native tools and CI/CD best practices. Because in the world of Agentic AI, security isn’t optional, compliance isn’t negotiable, and observability is your lifeline. Resources https://learn.microsoft.com/en-us/azure/ai-foundry/what-is-azure-ai-foundry https://learn.microsoft.com/en-us/azure/defender-for-cloud/ai-threat-protection https://learn.microsoft.com/en-us/purview/ai-microsoft-purview https://atlas.mitre.org/ https://digital-strategy.ec.europa.eu/en/policies/european-approach-artificial-intelligence https://techcommunity.microsoft.com/blog/microsoft-security-blog/microsoft-sentinel-mcp-server---generally-available-with-exciting-new-capabiliti/4470125Microsoft Sentinel Graph with Microsoft Security Solutions
Why I Chose Sentinel Graph Modern security operations demand speed and clarity. Attackers exploit complex relationships across identities, devices, and workloads. I needed a solution that could: Correlate signals across identity, endpoint and cloud workloads. Predict lateral movement and highlight blast radius for compromised accounts. Integrate seamlessly with Microsoft Defender, Entra ID and Purview. Sentinel Graph delivered exactly that, acting as the reasoning layer for AI-driven defense. What's new: Sentinel Graph Public Preview Sentinel Graph introduces: Graph-based threat hunting: Traverse relationships across millions of entities. Blast radius analysis: Visualize the impact of compromised accounts or assets. AI-powered reasoning: Built for integration with Security Copilot. Native integration with Microsoft Defender and Purview for unified security posture. Uncover Hidden Security Risks Sentinel Graph helps security teams: Expose lateral movement paths that attackers could exploit. Identify choke points where defenses can be strengthened. Reveal risky relationships between identities, devices, and resources that traditional tools miss. Prioritize remediation by visualizing the most critical nodes in an attack path. This capability transforms threat hunting from reactive alert triage to proactive risk discovery, enabling defenders to harden their environment before an attack occurs. How to Enable Defense at All Stages Sentinel Graph strengthens defense across: Prevention: Identify choke points and harden critical paths before attackers exploit them. Detection: Use graph traversal to uncover hidden attack paths and suspicious relationships. Investigation: Quickly pivot from alerts to full graph-based context for deeper analysis. Response: Contain threats faster by visualizing blast radius and isolating impacted entities. This end-to-end approach ensures security teams can anticipate, detect, and respond with precision. How I Implemented It Step 1: Enabling Sentinel Graph If you already have the Sentinel Data Lake, the graph is auto provisioned when you sign in to the Microsoft Defender portal. Hunting graph and blast radius experiences appear directly in Defender. New to Data Lake? Use the Sentinel Data Lake onboarding flow to enable both the data lake and graph. Step 2: Integration with Microsoft Defender Practical examples from my project: Query: Show me all entities connected to this suspicious IP address. → Revealed lateral movement attempts across multiple endpoints. Query: Map the blast radius of a compromised account. → Identified linked service principals and privileged accounts for isolation. Step 3: Integration with Microsoft Purview In Purview Insider Risk Management, follow Data Risk Graph setup instructions. In Purview Data Security Investigations, enable Data Risk Graph for sensitive data flow analysis. Example: Query: Highlight all paths where sensitive data intersects with external connectors. → Helped detect risky data exfiltration paths. Step 4: AI-Powered Insights Using Microsoft Security Copilot, I asked: Predict the next hop for this attacker based on current graph state. Identify choke points in this attack path. This reduced investigation time and improved proactive defense. If you want to experience the power of Microsoft Sentinel Graph, here’s how you can get started Enable Sentinel Graph In your Sentinel workspace, turn on the Sentinel Data Lake. The graph will be auto provisioned when you sign in to the Microsoft Defender portal. Connect Microsoft Security Solutions Use built-in connectors to integrate Microsoft Defender, Microsoft Entra ID, and Microsoft Purview. This ensures unified visibility across identities, endpoints, and data. Explore Graph Queries Start hunting with Sentinel Notebooks or take it a step further by integrating with Microsoft Security Copilot for natural language investigations. Example: “Show me the blast radius of a compromised account.” or “Find everything connected to this suspicious IP address.” You can sign up here for a free preview of Sentinel graph MCP tools, which will also roll out starting December 1, 2025.Know MCP risks before you deploy!
The Model Context Protocol (MCP) is emerging as a powerful standard for enabling AI agents to interact with tools and data. However, like any evolving technology, MCP introduces new security challenges that organizations must address before deploying it in production environments. Major MCP Vulnerabilities MCP’s flexibility comes with risks. Here are the most critical vulnerabilities: Prompt Injection Attackers embed hidden instructions in user input, manipulating the model to trigger unauthorized MCP actions and bypass safety rules. Tool Poisoning Malicious MCP servers provide misleading tool descriptions or parameters, tricking agents into leaking sensitive data or executing harmful commands. Remote Code Execution Untrusted servers can inject OS-level commands through compromised endpoints, enabling full control over the host environment. Unauthenticated Access Rogue MCP servers bypass authentication and directly call sensitive tools, extracting internal data without user consent. Confused Deputy (OAuth Proxy) A malicious server misuses OAuth tokens issued for a trusted agent, performing unauthorized actions under a legitimate identity. MCP Configuration Poisoning Attackers silently modify approved configuration files so agents execute malicious commands as if they were part of the original setup. Token or Credential Theft Plaintext MCP config files expose API keys, cloud credentials, and access tokens, making them easy targets for malware or filesystem attacks. Path Traversal Older MCP filesystem implementations allow navigation outside the intended directory, exposing sensitive project or system files. Token Passthrough Some servers blindly accept forwarded tokens, allowing compromised agents to impersonate other services without validation. Session Hijacking Session IDs appearing in URLs can be captured from logs or redirects and reused to access active sessions. Current Known Limitations While MCP is promising, it has structural limitations that organizations must plan for: Lack of Native Tool Authenticity Verification There is no built-in mechanism to verify if a tool or server is genuine. Trust relies on external validation, increasing exposure to tool poisoning attacks. Weak Context Isolation Multi-session environments risk cross-contamination, where sensitive data from one session leaks into another. Limited Built-In Encryption Enforcement MCP depends on HTTPS/TLS for secure communication but does not enforce encryption across all channels by default. Monitoring & Auditing Gaps MCP lacks native logging and auditing capabilities. Organizations must integrate with external SIEM tools like Microsoft Sentinel for visibility. Dynamic Registration Risks Current implementations allow dynamic client registration without granular controls, enabling rogue client onboarding. Scalability Constraints Large-scale deployments require manual tuning for performance and security. There is no standardized approach for load balancing or high availability. Configuration Management Challenges Credentials often stored in plaintext within MCP config files. Lack of automated secret rotation or secure vault integration makes them vulnerable. Limited Standardization Across Vendors MCP is still evolving, and interoperability between different implementations is inconsistent, creating integration complexity. Mitigation Best Practices To reduce risk and strengthen MCP deployments: Enforce OAuth 2.1 with PKCE and strong RBAC. Use HTTPS/TLS for all MCP communications. Deploy MCP servers in isolated networks with private endpoints. Validate tools before integration; avoid untrusted sources. Integrate with Microsoft Defender for Cloud and Sentinel for monitoring. Encrypt and rotate credentials; never store in plaintext. Implement policy-as-code for configuration governance. MCP opens new possibilities for AI-driven automation, but without robust security, it can become an attack vector. Organizations must start with a secure baseline, continuously monitor, and adopt best practices to operationalize MCP safely.
Change password for krbtgt account
What is the criteria that MDI uses to determine whether the https://learn.microsoft.com/en-us/defender-for-identity/security-posture-assessments/accounts#change-password-for-krbtgt-account recommendation has been completed? I'm working with an org where the passwordLastSet attribute on the krbtgt account says "never", yet this recommendation is showing "Completed".
sensor service fails to start
Hello, i've installed MDI on all of our domain controllers and everything went fine. I am trying to install MDI our Entra connect server and our certificate authority server (which are not domain controllers) and the service is continually failing to start. Could someone please point me in the right direction on how to rectify this? I've tried: recreating the service account (3x), checking the service account with Test-ADServiceAccount (works fine from both member servers) verified the service account is given the right to log on as service. The error log is very vague: 2025-11-13 19:05:30.0968 Error DirectoryServicesClient+<CreateLdapConnectionAsync>d__49 Microsoft.Tri.Infrastructure.ExtendedException: CreateLdapConnectionAsync failed [DomainControllerDnsName={FQDN of DC}] at async Task<LdapConnection> Microsoft.Tri.Sensor.DirectoryServicesClient.CreateLdapConnectionAsync(DomainControllerConnectionData domainControllerConnectionData, bool isGlobalCatalog, bool isTraversing) at async Task<bool> Microsoft.Tri.Sensor.DirectoryServicesClient.TryCreateLdapConnectionAsync(DomainControllerConnectionData domainControllerConnectionData, bool isGlobalCatalog, bool isTraversing) 2025-11-13 19:05:30.1124 Error DirectoryServicesClient Microsoft.Tri.Infrastructure.ExtendedException: Failed to communicate with configured domain controllers [ _domainControllerConnectionDatas={FQDN of DC}] at new Microsoft.Tri.Sensor.DirectoryServicesClient(IConfigurationManager configurationManager, IDirectoryServicesDomainNetworkCredentialsManager domainNetworkCredentialsManager, IDomainTrustMappingManager domainTrustMappingManager, IRemoteImpersonationManager remoteImpersonationManager, IMetricManager metricManager, IWorkspaceApplicationSensorApiJsonProxy workspaceApplicationSensorApiJsonProxy) at object lambda_method(Closure, object[]) at object Autofac.Core.Activators.Reflection.ConstructorParameterBinding.Instantiate() at void Microsoft.Tri.Infrastructure.ModuleManager.AddModules(Type[] moduleTypes) at new Microsoft.Tri.Sensor.SensorModuleManager() at ModuleManager Microsoft.Tri.Sensor.SensorService.CreateModuleManager() at async Task Microsoft.Tri.Infrastructure.Service.OnStartAsync() at void Microsoft.Tri.Infrastructure.TaskExtension.Await(Task task) at void Microsoft.Tri.Infrastructure.Service.OnStart(string[] args)
Unified detection rule management
Hi, I attended the webinar yesterday regarding the new unified custom detection rules in Defender XDR. I was wondering about the management of a library of rules. As with any SOC, our solution has a library of custom rules which we manage in a release cycle for a number of clients in different Tenants. To avoid having to manage rules individually we use the JSON approach, importing the library so it will update rules that we need to tune. Currently I'm not seeing an option to import unified detection rules in Defender XDR via JSON. Is that a feature that will be added? Thanks ZivMicrosoft Sentinel device log destination roadmap
I just attended the 11/5/2025 Microsoft webinar "Adopting Unified Custom Detections in Microsoft Sentinel via the Defender Portal: Now Better Than Ever" and my question posted to Q&A was not answered by the team delivering the session. The moderator told us that if our question was not answered we were to post the question in this forum. Here is the question again: "Will firewall and other device logs continue to go to Azure Log Analytics indefinitely? By Indefinitely I mean not changing in the roadmap to something else like Data Lake or Event Grid/Service Bus, etc." Thank you, JohnQuestion malware detected Defender for Windows 10
Why did my Microsoft Defender detect a malicious file in AppData\Roaming\Secure\QtWebKit4.dll (Trojan:Win32/Wacatac.C!ml) during a full scan and the Kaspersky Free and Malwarebytes Free scans didn't detect it? Was it maliciously modifying, corrupting, or deleting various files on my PC before detection? I sent it to Virus Total, the hash: 935cd9070679168cfcea6aea40d68294ae5f44c551cee971e69dc32f0d7ce14b Inside the same folder as this DLL, there's another folder with a suspicious file, Caller.exe. I sent it to Virus Total, and only one detection from 72 antivirus programs was found, with the name TrojanPSW.Rhadamanthys. VT hash: d2251490ca5bd67e63ea52a65bbff8823f2012f417ad0bd073366c02aa0b3828Using Microsoft Graph Security API for Custom Security Automations
Hi Security Experts, I’ve recently started exploring the Microsoft Graph Security API to centralize and automate security operations across different Microsoft 365 services. The idea is to build a single automation layer that can: Collect alerts from Defender for Endpoint, Defender for Cloud, and Identity Protection; Enrich them with context (user, device, and location data); And automatically push them to an external system like Jira, n8n, or a custom SOAR workflow. I was able to authenticate and list alerts using the endpoint: “GET https://graph.microsoft.com/v1.0/security/alerts” However, I’m still trying to understand the best practices for handling rate limits, pagination, and permissions — especially when integrating continuous polling or real-time ingestion into external tools. Has anyone here implemented Graph Security API automations in production? I’d love to hear about your experiences — specifically around performance, alert filtering, and authentication (App Registration vs Managed Identity). Thanks in advance, LucaHigh CPU Usage by Microsoft Defender (MsMpEng.exe) on Azure Windows Server 2019
Hi everyone, I’ve been seeing consistent CPU spikes from MsMpEng.exe (Antimalware Service Executable) on several Windows Server 2019 Datacenter VMs hosted in Azure. The usage reaches 100% for about 10–15 minutes daily, always around the same time. No manual scans are scheduled, and limiting CPU usage with Set-MpPreference -ScanAvgCPULoadFactor didn’t help. Could this be related to Defender’s cloud protection update cycle, or possibly a backend maintenance task from Defender for Cloud? Is there a recommended way to throttle or schedule these background Defender tasks in production environments? Appreciate any insights, LucaDefender for Endpoint Conflicting with Internal Firewall Authentication
Hi Security Experts, After onboarding a few devices into Defender for Endpoint, I noticed that those machines started having connection drops to the company’s internal firewall. They constantly re-authenticate before regaining web access. Devices not onboarded into Defender don’t experience this issue. Could Defender’s network protection or proxy policies be interfering with the internal firewall authentication flow? Any recommendations on how to keep Defender active while keeping the internal firewall as the primary control point? Thanks for any suggestions, Luca
Recent Blogs
- 5 MIN READThe updated CAF 4.0 raises expectations around control A2.b - Understanding Threat. Rather than focusing solely on awareness of common cyber-attacks, the framework now calls for a sector-specific, ...Dec 10, 2025
- Are you passionate about Microsoft security, compliance, and collaboration? Do you want to connect directly with product engineering teams and peers to shape the future of Microsoft solutions? If so,...Dec 08, 2025
