October 12 – October 19, 2026

Act by

• November 2026 — SAP SuccessFactors plans to deprecate basic authentication for its APIs, which breaks any Microsoft Entra provisioning job still authenticating to SuccessFactors with a username and password. Entra now supports Workload Identity-based authentication for SuccessFactors provisioning, replacing long-lived credentials with Entra-managed credentials and short-lived standards-based access tokens. The reason this is an Act by rather than a nice-to-have is the failure mode: a provisioning job that stops authenticating does not announce itself as a security problem, it announces itself as joiners and leavers not landing in the directory, which is a leaver still holding access. The upgrade path is deliberately gentle — you can change authentication in place on existing provisioning jobs without recreating or restarting them — and it covers inbound provisioning to Active Directory and to Entra ID as well as writeback. Find the jobs first, then convert them. (Microsoft Entra Blog)

What changed

October's Patch Tuesday, released on 13 October, is the largest Microsoft has published. The release document for October 2026 Security Updates carries 2,135 CVE entries, 201 of them rated Critical, and exactly one is flagged as exploited: CVE-2026-96951, a Windows Shell security feature bypass, CVSS 8.8, rated Important, which gets around the Mark of the Web protection. Read the attack vector before you argue about its Important rating — network reachable, low complexity, no privileges required, user interaction required — which is the signature of a file a user opens from somewhere untrusted and Windows does not flag. Mark of the Web is load-bearing for a lot of downstream protection, including Office protected view and SmartScreen decisions, so a bypass makes every other mail and web delivery control that much thinner until the patch lands. Two more are publicly disclosed but not flagged as exploited: CVE-2026-108398, a .NET Framework security feature bypass, and CVE-2026-92707, a denial of service in MessagePack-CSharp. Patch the Shell bypass on user-facing Windows first; the other two are the same day's work in a different queue. (Microsoft Security Update Guide)

The same day MSRC published something more useful than another prioritisation lecture: a method for triaging a release of that size without reading 1,400 CVEs one at a time. The idea is risk cohorts — provisional groups of CVEs that need the same assessment from you, even when they share no root cause and no CVSS score. They are explicitly not official Microsoft vulnerability categories, they do not change update guidance, and they are not a replacement for per-CVE analysis. What they change is the unit of work. Instead of asking the same environmental question 65 times, you answer it once and apply the answer across the group, while keeping the differences between CVEs visible. The illustrative cohorts from this release give you a sense of scale: Windows filesystems and backup at 136 CVEs, Office document and mail clients at 135, graphics and media at 131, kernel privilege boundaries at 109, and remote access and RDP at 65, with a per-cohort CVE list published as a PDF. The RDP worked example is the one to copy, because the shared question is one your team can actually answer: which client, gateway and server roles are deployed and exposed. Internet-reachable gateways or session hosts push the server-side CVEs up; managed devices that connect out push the client-side ones up; access only via VPN or a Zero Trust path may push some down. Severity, exploitability and user-interaction requirements still decide the order inside a cohort. Microsoft is candid about the limits — the cohorts are provisional, not formal Primary and Related CVE relationships, one update may not cover every CVE in a group, and the Security Update Guide does not display these relationships today — and it is asking for feedback rather than announcing a framework. (Microsoft Security Response Center)

Microsoft Threat Intelligence and the Digital Crimes Unit published a disruption write-up on 14 October that is worth a full read, because the infrastructure it describes is probably behind mail your users reported last month. The ecosystem is Chinese-language and has three tiers: phishing kit developers, an infrastructure broker, and buyers. Storm-2990 is the cluster behind three kits — CoGUI (also called NX or FA), Haozi (also called Phoenix), and Iron Man System, advertised from June 2026. Storm-3119, trading as YAM Store, is an underground marketplace and initial access broker that resells compromised or fraudulently obtained Microsoft and Google cloud environments. Since January 2026 those kits are linked to over a billion phishing emails and SMS messages sent to more than 75,000 organisations, with victims concentrated in healthcare, financial services, wholesale distribution and IT across Japan, the United States, Australia and India. Iron Man System ships over 2,335 templates covering more than 139 countries, and most of the US lures are transportation or government themed, which tells you what a convincing one looks like. The YAM Store tradecraft is the part to brief your identity team on: reconnaissance tooling run over Tor to profile cloud-enabled organisations and their licensing, environment takeover through actor-controlled admin panels using stolen application credentials to silently reset passwords and assign licences, and then a compromised Global Administrator used to add a PnP Management Shell service principal with broad Graph permissions and abuse SharePoint and OneDrive for bulk hosting. That is app-level persistence that survives a password reset. Downstream the kits are used for credential theft, device code phishing to capture tokens, and payment fraud, and the kits themselves carry geofencing, fake CAPTCHA gates, IP allow and block lists, and a WebSocket channel that lets an operator watch a victim live and choose what they see next. Microsoft's mitigation list is the familiar one and all the better for it: passkeys and phishing-resistant MFA enforced for privileged accounts through Conditional Access, MFA and passkey registration limited to trusted locations and devices, tight control of who holds Global Administrator, the recommended Exchange Online Protection and Defender for Office 365 settings with Safe Links enabled for internal recipients, and network protection turned on. Existing coverage spans Entra ID Protection, Defender for Office 365, Defender for Endpoint, Defender for Identity and Defender XDR, plus a threat analytics report titled Evolving phishing threats. (Microsoft Security Blog)

Defender for Identity published its October batch on 18 October, and it is the biggest alert drop in months — roughly twenty new detections, weighted heavily toward Active Directory Certificate Services. On the AD CS side there are now alerts for suspicious certificate requests, machine certificate issuance abuse mapped to ESC8, machine certificate issuance over RPC mapped to ESC11, misconfigured certificate template abuse mapped to ESC1, and theft of a Certificate Authority certificate and private key. If your AD CS estate has been a known gap that nobody could get telemetry on, that gap just narrowed considerably, and the first thing to do is not tuning but inventory: know which templates and CAs exist before the alerts start naming them. The Kerberos additions are equally pointed — privilege escalation using a diamond ticket, malicious Kerberos activity and CVE-2025-33073 exploitation attempts, suspicious PKINIT authentication on the AS-REQ, and suspicious Kerberos ticket authorization data. Rounding out Active Directory are malicious requests for the DPAPI master key and possible data exfiltration over DNS. On the Entra side there is a new alert for suspicious sign-in via Temporary Access Pass, which pairs neatly with the earlier reciprocal TAP creation alert and with the help-desk social engineering that makes TAP attractive to an attacker in the first place. And there are seven new Okta alerts: anomalous volume of failed authentications, an MFA method added for a privileged account, access or refresh token grant from a risky context, anomalous privileged account authentication, consent grant from a risky context, a privileged account password reset by another account, and a secondary identity provider added. Multi-IdP shops should check who owns triage for those before the first one fires. (Microsoft Defender for Identity what's new)

Microsoft Entra reorganised its monthly what's new on 16 October, and the change is more than cosmetic. Yina Arenas, CVP and Chief Product Officer of Identity and Network Access, says the post will now be structured around the outcomes customers are trying to achieve rather than around product architecture, with four headings: keep my organization trusted and resilient, give users and agents secure access without friction, reduce the cost and complexity of access management, and adopt AI safely at enterprise scale. Worth knowing if you read that post as a feed, because the shape you scan for has changed. The headline capability under the first heading is a public preview that extends Universal Continuous Access Evaluation in Global Secure Access to new signal types: user-risk signals and device-revocation signals, including when a device is deleted, disabled, or becomes noncompliant. That matters because it closes the slowest gap in device-based Conditional Access. Marking a device noncompliant in your MDM has historically been a decision that takes effect on the next token refresh, which is not the timeframe you want during an active incident; feeding it into CAE makes it a session-kill signal instead. The post also flags Microsoft Ignite, 17 to 20 November, as where the Entra and Agent 365 agent story gets filled in. (Microsoft Entra Blog)

Two Global Secure Access items in the same Entra post are worth separating out because they remove deployment blockers rather than adding features. Microsoft-managed certificates for TLS inspection went to public preview, and the point is what it deletes: TLS inspection previously required you to provision and manage your own inspection certificate and trust chain, so the feature was gated on operating a certificate authority or PKI. Microsoft now provisions the inspection certificate itself. If TLS inspection has been on your roadmap and stuck behind a PKI conversation, that conversation just got shorter. Separately, B2B guest access with Global Secure Access reached public preview: a guest user signed in to their home organization's Entra ID account can now connect through Global Secure Access, with the client detecting partner tenants where the user is a guest and offering to switch to the customer tenant context, after which private traffic routes through the customer's Global Secure Access service. For anyone running contractors or partner staff on private apps, that is the scenario that previously needed a VPN exception. Both are previews, so pilot accordingly. (Microsoft Entra Blog)

The guided migration from Microsoft Entra Connect Sync to Microsoft Entra Cloud Sync went generally available in the same post, and this is the one to raise with whoever owns hybrid identity. It brings the whole move into a single workflow: assessing readiness, setting up the provisioning agent and the Cloud Sync configuration, activating Cloud Sync through a controlled transition, and validating the environment afterwards. The security argument for caring is not the feature, it is what Connect Sync is — a Windows server with directory synchronisation privileges, historically one of the most valuable targets in an on-premises estate and the subject of a long run of Defender for Identity alerts about suspicious sync-application behaviour. Replacing it with a lightweight agent and a cloud-side configuration removes a Tier-0 server from the board. The migration is still a migration and the guided tool only covers eligible organisations, so read the readiness assessment before promising a date. (Microsoft Entra Blog)

Microsoft Purview took Endpoint DLP monitoring of FTP and SFTP transfers to general availability in October, dated to the 16th on the what's new page. Endpoint DLP can now monitor sensitive data transferred over FTP and SFTP from managed Windows devices and enforce restrictive actions on it, configured as FTP and SFTP transfer activities within your existing Endpoint DLP policies. The reason to look at this even in a shop that considers FTP dead is that FTP is rarely dead, it is just undocumented — a scheduled job moving a file to a partner, a legacy appliance, a script someone wrote in 2017. Those paths have been a genuine blind spot in endpoint DLP coverage while every other egress channel got watched. Deploy it in audit first and read the inventory it gives you before enforcing anything, because the first run is as much a discovery exercise as a control. (What's new in Microsoft Purview)

Defender Vulnerability Management moved vulnerability assessment for Microsoft Store applications to general availability, dated 14 October on the Defender for Endpoint what's new page, after the preview in August. Defender Vulnerability Management detects supported Microsoft Store applications, adds them to the software inventory, and assesses them for vulnerabilities. Coverage is still limited to a selected set of commonly used applications, which is the caveat to carry into any conversation about completeness — Store-delivered software does not install or version like conventional Win32 software, which is exactly why it has been missing from inventory. The practical hook is unchanged from the preview: the software evidence area on the software page shows the file path for the vulnerable application along with a suggested query returning the app, version and file location, so a finding converts into a remediation target without a hunting detour. (Microsoft Defender for Endpoint what's new)

A small advanced hunting addition from Defender for Office 365, dated 15 October on its what's new page, closes an audit gap that has annoyed anyone who has had to reconstruct a remediation after the fact. The EmailPostDeliveryEvents table now includes an ApproverUpn field, identifying the user or administrator who approved a remediation action. Until now the table told you what happened to a message after delivery but not who authorised it, which meant cross-referencing the unified audit log or the action centre to answer a question an auditor asks routinely. One field, one fewer join. Add it to your post-delivery hunting queries and to whatever report you produce on remediation activity. (Microsoft Defender for Office 365 what's new)

Two hardware security module items went generally available in the window, and the second is the one with an operational consequence for monitoring. Hardware audit logging for Azure Cloud HSM, GA on 14 October, provides hardware-generated audit records for supported HSM management operations, delivered to Azure Monitor Log Analytics so they land in the workflows you already have. The detail that makes it more than another log source is verifiability: you get human-readable records alongside HSM-signed binary audit data, signatures and certificates, so you can independently verify the authenticity and integrity of signed audit batches. For an estate where the HSM is the root of trust, a tamper-evident audit trail is the difference between asserting that keys were not misused and demonstrating it. Alongside it, external key management for Azure Key Vault Managed HSM reached GA in all Azure public regions on 16 October, letting Azure services that support customer-managed keys with Managed HSM use keys held in a customer-operated HSM outside Microsoft infrastructure; Managed HSM delegates key wrap and unwrap through a customer-operated proxy and the external key material never enters Microsoft infrastructure. Read the fine print before anyone commits to it in a sovereignty conversation — access requires enablement through your Microsoft account team, GA covers connectivity to the proxy over the public internet while Azure Private Link integration is still public preview, and the external HSM, the proxy and their network availability are your responsibility and sit outside the Managed HSM SLA. (Azure updates)

KQL to try

Published on 13 October and squarely on theme for a week with two Key Vault items in it, this one chains an identity signal to a secrets-store action, which is the correlation most teams write by hand and get slightly wrong. It takes Entra sign-ins with a RiskLevelDuringSignIn of 10, 50 or 100 — low, medium or high — and joins them to Key Vault data plane activity on the sign-in's unique token identifier, so the Key Vault events it returns are provably from that session rather than merely from the same user around the same time. The author's triage advice is to review the account, source IP, user agent, sign-in error code, accessed vault and activity together, and to look at failed sign-ins as well as successful ones. Note that it scopes Key Vault events to AccountType "user", so service principal and managed identity secret access is deliberately out of frame here. (Risky Sign-in Followed by Key Vault Activity — Bert-Jan Pals)

EntraIdSignInEvents
| where RiskLevelDuringSignIn in (10, 50, 100)
| project SignInTime = Timestamp, IPAddress, UserAgent, AccountUpn, UniqueTokenId, ErrorCode
| join kind=inner (
    CloudKeyVaultEvents
    | where AccountType == "user"
    | extend UniqueTokenIdentifier = tostring(AdditionalFields.UniqueTokenIdentifier)
    | project KeyVaultEventTime = Timestamp, UniqueTokenIdentifier, AzureResourceId, ActivityName
) on $left.UniqueTokenId == $right.UniqueTokenIdentifier
| where KeyVaultEventTime >= SignInTime

From 15 October, five lines that answer a question most SOCs cannot currently answer at all: which of our UEBA anomalies came from an AI agent. It reads the Sentinel BehaviorAnalytics table, keeps events with an InvestigationPriority of 5 or higher, expands DevicesInsights to pull out the device user agent, and returns the ones whose user agent contains "mcp". The reasoning is that a Model Context Protocol client acting with a user's identity tends to look anomalous to UEBA by construction — new applications, unusual volumes, uncommon resources, atypical access patterns — and an attacker holding valid credentials can hide automated reconnaissance inside that same traffic shape. The author is clear about the limits and you should be too: the substring match will catch unrelated user agents, MCP clients that do not identify themselves are invisible to it, and the priority threshold wants tuning up or down depending on whether you are hunting or triaging. Treat the output as a list of agent-identity pairs to review, not as alerts. (UEBA High Priority Activity from MCP Client User Agents — Benjamin Zulliger)

BehaviorAnalytics
| where InvestigationPriority >= 5
| mv-expand DevicesInsights
| extend UserAgent = (DevicesInsights.UserAgent)
| where isnotempty( UserAgent)
| where tolower( UserAgent) contains "mcp"

Worth knowing

Microsoft and NVIDIA published a joint risk-management guide for open-weight models on 16 October, and its central claim is the one to take into your next architecture review: weight openness alone does not determine an AI system's risk. The guide offers a shared taxonomy across five categories — cybersecurity, data protection, content, human-AI interaction, and bias — built on ISO standards and the NIST AI Risk Management Framework, and argues that open- and closed-weight models share most underlying risks but express them differently depending on deployment. Three points generalise beyond AI governance. A risk may originate in the model while the most effective control sits in the inference environment, the application, or an operational process, so map each risk to a control at the layer that can actually enforce it. Running your own model deployment means inheriting controls a managed service would otherwise have provided, so be explicit about who owns each safeguard. And evaluating a model does not establish the safety of an agent built on it — permissions, data access, tools and runtime have to be assessed separately, which is the same argument the Defender and Entra agent-security work has been making from the product side. Microsoft Foundry is the platform capability named in the guide, for built-in and custom evaluations, automated red teaming, and configurable content-safety controls. (Microsoft Security Blog)

Merill Fernando published an Entra app hygiene piece on 17 October that reads like a description of most tenants: hundreds of app registrations and service principals, client secrets set to expire in a hundred years, permission grants nobody remembers approving, and test tenants that were never cleaned up. It is worth pairing with the phishing ecosystem research above, because the YAM Store persistence pattern — a compromised Global Administrator used to add a service principal with broad Graph permissions — only works quietly in a tenant where nobody could tell you what the normal service principal population looks like. If you do one thing with it, inventory client secret lifetimes and existing consent grants, in that order. (Entra.News)