Comment

The past couple of weeks have been quite eventful for the Apple Developer community, with multiple notable announcements from Apple that I’d like to discuss today.

First, let’s touch (pun intended) on the subject of the new MacBook with Touch and the increasingly blurry boundaries between macOS and iPadOS. After rewatching the accompanying tech talks, Bring Touch to your Mac app in particular, I noticed two important details that eluded me on the first viewing.

For one, gesture recognizers have become a shared input language across SwiftUI, Mac Catalyst, and now AppKit. This means that iPadOS and macOS apps can handle interactions through a common high-level abstraction.

Second, we can directly touch macOS apps on an iPad connected via Sidecar. For all intents and purposes, the experience of using Mac apps on an iPad is now blessed by Apple, even if only for testing purposes.

All this reinforces the idea that macOS and iPadOS are on a collision course, and revives the age-old question: when will we finally see native Mac apps running on iPads?

Then there’s the announcement that’s making waves in the dev community right now. Apple has opened Siri AI to all developers and published the (uncharacteristically well-documented) Siri AI Developer Preview.

I always struggled to get excited about using App Intents to integrate with Siri, and not only because of Siri’s subpar performance. There was something else. Jordan Morgan’s post, Finally, Apple Frees us from Domains, helped me find the right words to express my reservations. My apps never neatly fit into the predefined schemas and domains Siri understood. The new paradigm, in which apps can expose arbitrary functionality as tools using the @AppIntent(.tool) macro and bundle App Skills to help Siri understand how to use them, should finally lift those subtle constraints.

That said, I doubt that businesses that rely on people spending time in their apps will be too keen on opening up to this more capable Siri performing tasks on users’ behalf. I suspect we’ll see a significant split in Siri AI adoption across different app categories.

– Alex Ozun

Sponsored Link

More Swift. More builds. Less waiting.

More AI-assisted commits mean more builds to pay for. WarpBuild runs your Xcode jobs on M5 Pro Macs, with up to 3x faster builds and pricing from $0.08 per minute. Get feedback sooner as your build volume grows. Try one GitHub Actions workflow with $50 in free credits using code iosdev2026.

News

WebKit.org | Introducing Adaptive Dark Mode

Another notable announcement came from the WebKit team: Introducing Adaptive Dark Mode. While not too relevant to native app development, I think it’s fantastic news nevertheless, and I wish this capability had been around when I agonized over dark-mode CSS for my blog (time I will never get back). As a Safari user, I’m hoping to also see the opposite feature, Adaptive Light Mode, that inverts dark-only websites that unfortunately are trendy these days (is AI to blame here?).

---

Good bye to Swift

NASA confirmed that the Swift observatory spacecraft re-entered Earth’s atmosphere and mostly burned up during re-entry. RIP, aged 22.

Code

The simulator is crackling again: what changed with Device Hub and how to fix it

Somehow, the simulator bug that messes up your audio returned!

Karolina Samorek explains why the workaround of redirecting the simulator’s audio into the BlackHole no longer works in Device Hub, and proposes two alternative fixes. Thank you for your service!

---

iPhone Duo collection | Nil Coalescing

Nil Coalescing have been publishing high-quality articles on adapting apps for iPhone Duo over the past few weeks, so having them neatly assembled in a collection is helpful indeed! It’s a great place to start if you’re just getting into iPhone Duo adoption.

---

Interesting ways of using Swift optionals

What’s the best way to prevent AI-induced deskilling? To regularly go back to basics! John Sundell’s latest article offers just that, and maybe even more! Optionals have been Swift’s workhorses since day one, but you may still be surprised by some lesser-known uses for the humble Optional.

Tools

PictureWriter | a Mac video editor

Pasi Salenius just announced the launch of PictureWriter, a small, native Mac video editor. The app is another testament to just how optimized unapologetically native Mac apps can be. It’s faaast and lightweight at ~25MB, with lots of effects and presets that will be particularly interesting to app developers working on App Store listings and promo materials.

---

Stream for Mac | A Feed Reader

What, another blazing-fast and lightweight Mac-assed app in the same issue? Is the holiday season approaching? Oh yeah, I guess it is!

Rob Fahrni just released Stream for Mac, a unified feed reader for news and RSS subscriptions. I like how you can just drop in a website URL and it’ll find a way to subscribe without me needing to hunt down the exact RSS feed page. Cheers, Rob!

---

DeviceMCP | MCP for your iPhone

Noah Tran, the developer behind the popular Proxyman app, just launched a new tool that allows AI agents to connect to physical iPhones and iPads via an MCP server. This lets agents control devices with actions like tapping, swiping, and opening apps. Something similar was already possible with DeviceHub, but the new MCP-based approach promises better token efficiency and control accuracy.

Business and Marketing

App Store 2026 in numbers

Obelisk Club analyzed 178,637 apps that appeared in the App Store top charts across 173 countries and presented some interesting insights. About 10% of these apps mention AI in their App Store listings. Meanwhile, about ~20% haven’t been updated for a year or more, and ~10% for three years or more. Wow, that’s a lot of abandonware in the top charts. Granted, not every app needs regular updates, but the number is still higher than I expected. I know that Apple’s been sending out delisting notices for abandoned apps lately. I wonder how many of those charting apps will be affected.

Videos

Apple Intelligence Group Lab | 11/4/26 | Meet with Apple

Hot on the heels of the Siri AI Developer Preview, we got an Apple Intelligence Group Lab session.

Anton Gubarenko created a helpful timestamped Q&A summary, which is increasingly becoming my preferred way to catch up on these labs without sitting through the entire session.

And finally...

Swift programmers love static typing. But what about duck typing?

European organizations have had to make a trade-off with Claude models in Microsoft Copilot. They could use Claude, or they could keep the Microsoft regional data-processing commitments they rely on. Many chose the commitments and kept Claude switched off.

That trade-off is going away. That trade-off is going away. Microsoft has announced that Claude models in Copilot will move into the EU Data Boundary by the end of 2026. That covers Copilot Cowork too.

What was announced

On November 5, 2026, Charles Lamanna announced in Bringing Claude models in Microsoft Copilot into the EU Data Boundary that Claude models by Anthropic in Microsoft Copilot are coming into the EU Data Boundary.

The key points:

• Timing: by the end of 2026.
• Who: organizations in the European Union (EU) and the European Free Trade Association (EFTA).
• Where: across Copilot experiences, including Copilot Cowork. Data is processed inside the EU Data Boundary, where it’s already stored.
• Why it matters: organizations won’t need to choose between Claude models and Microsoft’s regional data-processing commitments any more.

The last point is the important one. For many organizations in Europe, that has been a real choice. Now it won’t be.

Remember that is a model is in Frontier / preview, it very likely runs outside of EUDB!

Why this matters – no more either-or

The EU Data Boundary is Microsoft’s commitment to store and process data for Microsoft 365 and other online services inside the EU and EFTA. A few things worth remembering:

Claude models already run work across many Copilot experiences: Chat, Copilot in Microsoft 365 apps, Copilot Cowork and Copilot Code. But for organizations that rely on the EU Data Boundary, using Claude meant stepping outside the commitments their compliance work is built on.

For a lot of organizations, especially in the public sector and regulated industries, that was enough to say no. Or at least “not yet”.

Once Claude is inside the boundary, it joins the other leading models already processing data there, including Microsoft-operated models. Claude becomes one more option in the Copilot model line-up, with the same data commitments as the rest. Organizations can then scale the latest AI across the organization without making an exception for one model provider.

Model choice with the same protections

Copilot brings models from Anthropic and other providers into one governed experience that is grounded in your work. The idea is simple: people can pick the right model for the task at hand.

Claude in Copilot comes with the same protections as the rest of Copilot:

• Microsoft’s enterprise data protection covers Claude models in Copilot.
• Customer data isn’t used to train generative AI foundation models.
• Admins decide who can use them.

This is what makes model choice work at enterprise scale. Security, compliance and governance stay the same whichever model does the work. For how Microsoft protects and limits access to customer data, see Microsoft Data Access on the Microsoft Trust Center.

What admins need to know

The admin side is easy to follow:

• Already using Claude in Copilot? You don’t need to do anything. Once processing is available inside the EU Data Boundary, it moves there automatically.
• Not enabled yet? You can turn Claude on at any time. Processing moves into the EU Data Boundary once it’s available.
• Default setting: In the EU and EFTA, the setting is disabled by default.
• Who gets access: Admins can enable Claude for all users or for selected users and groups in the Microsoft 365 admin center.

The setup details are on Microsoft Learn: Anthropic models in Microsoft Online Services. Microsoft has said it will share more details as availability gets closer.

A practical tip: don’t wait until the end of the year to start the discussion. If your organization kept Claude off because of data processing location, now is a good time to revisit that decision. You can also plan which users or groups should get it first.

Model choice becomes a governance question

AI is moving fast, and the best model for a task can change. Copilot’s approach is to give organizations one governed experience for adopting leading models as they evolve. Security, compliance and admin controls stay the same throughout. See Understanding AI functionality and models in Microsoft Online Services for the bigger picture.

For that to work in Europe, every model needs to have the same data commitments. Otherwise model choice is only real in some regions. Bringing Claude into the EU Data Boundary closes one of the biggest gaps.

Model choice in Copilot is turning into an admin and governance decision more than a technology one. Is your organization ready to make that call when Claude moves inside the boundary?

Learn more

• Bringing Claude models in Microsoft Copilot into the EU Data Boundary – the announcement on the Microsoft Copilot blog
• EU Data Boundary – Microsoft Learn
• In-country data residency – Microsoft Learn
• Enterprise data protection in Microsoft 365 Copilot – Microsoft Learn
• Claude models in Microsoft Online Services – Microsoft Learn
• AI models in Microsoft Copilot – Microsoft Learn
• Microsoft Data Access – Microsoft Trust Center

Last week, I gave a talk at GitHub Universe 2026 about context. The question behind it: when a coding agent changes one API, how does it know what else that change breaks?

The demo answers it with two agents building on a healthcare app, each in its own session with no shared memory. Agent A uses the Postman Context Graph to find which services supply the data for a claims-review API, builds a simulation of those dependencies, and publishes it to a Postman workspace. Agent B pulls that simulation, runs the existing tests, and extends the API. The checks go from 10 passing assertions to 14, and Agent B never has to rediscover a dependency.

The part nobody talks about

My talk was called “Agentic SDLC with Context Graph and API Simulations.” The premise: all of us use coding agents to do engineering work, and it’s rare for that work to have no downstream dependencies that also need updating. The agent writes the code, silently breaks a bunch of other things, and you get paged for an incident tied to your change. That’s the part nobody talks about. The agent does the engineering work, but I’m the one keeping track of everything around it: the context, the dependencies, what’s been verified, and what else needs to be updated. The talk was about handing more of that tracking to the agent, using the Postman plugin.

The endpoint is the fast part

An agent can write an endpoint quickly. The work around the endpoint is what takes longer. I framed it with four items:

What takes longer	What it means for an agent
Contract	Understanding what the API promises
Dependencies	Finding every service the change touches
Tests	Checking the behavior, not only whether it compiles
Handoff	Leaving the next person or agent a setup they can use

The Postman plugin gives an agent skills for API engineering. Each skill holds instructions the agent can read for a task: which tools to use, which files to work with, and how to check the result. The full plugin covers development, testing, documentation, CI, and monitoring, so it reaches every phase of the SDLC. For this talk I picked two skills:

• api-discovery, which includes the Context Graph, helps the agent understand the APIs and relationships involved.
• api-simulation gives the agent an environment where it can develop against those dependencies.

Then I added a constraint to make the demo honest: two agents working on consecutive tasks, in separate sessions, with a Postman workspace as the only thing carrying work between them.

A librarian, a catalog, and a lot of shelves

To explain why the Context Graph comes first, I used a library.

Imagine you walk in and ask the librarian to find everything about chess. There’s no computer catalog, so the only way to answer is on foot. The librarian walks the building, searches every shelf, and inspects individual books. A more experienced librarian might do that faster and notice more, but they’re still searching the entire building from scratch.

Now give the librarian the catalog. Instead of starting at the first shelf and working aisle by aisle, book by book, page by page, they search once and get a list of relevant books with exact shelf locations. The catalog tells them where to begin, which books to pull, and which sections deserve a closer look. It can also point to a chapter inside a book with an unrelated title, a book stored at another location, or a resource that isn’t on a physical shelf at all, like an audiobook. The librarian then opens the books and verifies they contain what you need.

In the analogy	In the agent workflow
The librarian	The model
The shelves	The checked-out repositories
The catalog	The Context Graph

The Context Graph tells the model which services, APIs, endpoints, and relationships are likely to matter and where to focus its search. Instead of exploring hundreds of repositories one by one and burning countless tokens, the model starts with a specific set of candidates and verifies those leads in the code wherever it can. Postman’s own writing on why AI coding agents need context graphs makes the same argument with more depth.

The analogy also answers the question I get most about model quality. A better model is a faster, more experienced librarian. It searches the shelves more efficiently, but it still can’t find something that isn’t on those shelves. The Context Graph gives the agent a starting point: which APIs are relevant to the task, where to find them, and which relationships to verify.

Develop against dependencies you can’t run

Knowing where an API lives doesn’t mean its service is available to run on your laptop. That’s the gap api-simulation fills.

Say my service calls four other APIs. To develop it locally, I need to exercise those calls, including their responses and failures, without bringing up all four real services. A Postman simulation groups the dependency mocks into one runnable setup. Each mock represents an API, and the simulation defines how to reach them together. My real service runs locally and sends its dependency calls to that setup, and I can add delays, errors, and rate limits to see how the service behaves when a dependency has a bad day.

Then comes the handoff. I save the requests and assertions as a Postman Collection and publish the simulation and the collection to a workspace. Another agent can retrieve both, start the same dependency setup, and rerun the existing checks before it changes anything.

The demo: two agents, one workspace

The demo used a hospital app, myhealthcare.dev, with services that manage patients and billing. The goal was to add an insurance service so a user can view claims and approve or deny them. I split the work between two agents and drew the whole thing on a whiteboard first.

The whiteboard sketch from the talk. Claim data is spread across services, so Agent A has to find out which ones supply it.

Agent A builds the API for viewing claims. Each claim needs an insurance ID, a patient’s name, and a billing amount, and that information lives in different services. The patient’s name comes from the patient service. Agent A asks the Context Graph where to get each piece and which dependencies it needs.

Here’s the start of the prompt I gave it:

You can watch the whole run in the recording below.

The demo from my GitHub Universe session: two agents in separate sessions, a Context Graph query, a shared simulation, and a Postman workspace in the middle.

Here’s what happens in the video:

1. Agent A uses the api-discovery skill to ask the Context Graph which services supply the claim and patient data, and how billing connects to the decision.
2. It uses api-simulation to simulate those dependencies locally, so it can build and test without running every service on my machine. The Postman skills guide it through creating a collection and adding tests.
3. All 10 assertions pass, and all four dependencies take traffic. Agent A publishes the simulation and the collection to a shared Postman workspace.
4. I switch to Agent B in a separate session. It has no memory of Agent A’s work, so it pulls the shared assets from Postman and runs the existing tests before making any changes.
5. Agent B’s task is an endpoint that lists claims by payer. It checks the Context Graph for the relevant APIs, then develops against the simulation Agent A already created.
6. Agent B adds tests for the new endpoint and reruns the collection. There are now 14 passing assertions, and it pushes the updated assets back to the workspace.

In the original plan on the whiteboard, Agent B approves or denies claims and has to tell billing about each decision. The recorded run uses a smaller task, but the principle holds: Agent B asks the Context Graph which downstream service needs to know about a change, then uses the simulation to check that the right update reaches it.

The shared simulation in the Postman workspace. Four mocks stand in for the services the claims API depends on.

The moment I care about most is step 4. Agent B doesn’t have to figure out those dependencies or set them up again. The Context Graph helps each agent understand what its change touches, and the shared simulation lets the second agent build on the first agent’s work. That’s the agentic SDLC I wanted to show: discover dependencies, simulate them, build, test, and share the result so the next agent can keep going.

Try it yourself

You can run the same loop on your own services. I ran the demo in GitHub Copilot, but the Postman plugin installs into other coding agents too, so use whichever one you already have. One command installs it:

npx @postman/postman-plugin

The installer adds the plugin to each supported agent it detects on your machine, including GitHub Copilot and Claude Code. To install into a single agent, pass its ID, and check where the plugin is installed with status:

npx @postman/postman-plugin install --agent copilot
npx @postman/postman-plugin status

The plugin install guide covers the per-agent options if you’d rather use an agent’s own marketplace. Next, connect your repository to a Postman workspace:

postman init

Then sign in and ask the Context Graph a question about a service you own:

postman login
postman context-graph ask "What depends on billing-api?" --wait

Swap billing-api for one of your services. The --wait flag prints the answer inline, and without it the command returns an ask ID you can check later with postman context-graph status. From there, try this prompt in your agent, adapted from the demo:

Run the collection, publish the simulation and collection to a workspace, and start a second agent session. Ask it to pull the shared assets and run the existing checks before it changes anything. If it can do that without you explaining the dependencies again, the handoff works.

Resources

• GitHub Universe 2026 announcement on the GitHub Blog
• Postman plugin skills
• Install the Postman plugin
• Postman plugin on GitHub
• Context Graph commands in the Postman CLI
• Query the Context Graph with an MCP client
• Why AI coding agents need context graphs
• Create and run a simulation in Postman
• Announcing the Postman Plugin for Claude Code

The post The Real MVP of GitHub Universe 2026: Context appeared first on Postman Blog.

The Angular community is firing on all cylinders! From shaving milliseconds off your Core Web Vitals to deploying server-side rendered apps in production, mastering professional form submissions, and architecting enterprise Nx monorepos, this week’s lineup is packed with practical engineering gems.

Dive into these expert-led resources to level up your workflow:

Web Core Vitals in Angular (Spanish)

Kevin Dávila breaks down how to optimize your Angular applications for Core Web Vitals (LCP, INP, and CLS). Learn tactical patterns to enhance real-world user experience and skyrocket your performance scores.

• Read the guide: https://www.codeabien.com/es/blog/web-core-vitals-en-angular

Angular SSR Deployment (Spanish with English Subtitles)

Alejandro Cuba Ruiz, Antonio Cárdenas, and Ricardo Chavarría join forces to break down the complexities of taking Server-Side Rendering to production. Discover hosting options, pipeline setups, and critical deployment pitfalls to avoid.

• Watch the deployment panel: https://youtu.be/wIaThYaieUA

Submit Like a Pro with Angular Signal Forms

Fanis Prodromou walks through how to handle form submission flows cleanly using the modern Signal Forms API. Learn how to manage loading flags, submission states, and error feedback with pure reactive ergonomics.

• Watch the tutorial: https://youtu.be/6Jr6AN6gOfY

Beyond Clean Code: Scalable Architecture with Nx Monorepos

Fanis Prodromou also delivers a must-read architectural deep dive on Angular.love. Discover how to structure large-scale enterprise frontends using Nx monorepos, establishing domain boundaries, shared libraries, and maintainable module graphs.

• Read the architecture article: https://angular.love/beyond-clean-code-building-a-scalable-angular-frontend-architecture-with-nx-monorepos

Road to Angular 22: Debounce Signal

Davide Passafaro previews what’s coming on the horizon with native Debounce Signals. See how built-in reactive debouncing primitives streamline state management without relying on third-party utilities or complex operator chains.

• Read the preview: https://medium.com/@davidepassafaro/road-to-angular-22-debounce-signal-74d76eb48384

How are you tuning your Core Web Vitals and SSR pipelines this year? Have you already started structuring your Signal Form submissions with these modern primitives?

Keep the knowledge moving. Use #AngularSparkles to share your favorite tips, benchmarks, and architectural setups with the community 👇

---

Core Vitals Optimization, SSR Deployments, and Signal-First Architecture ⚡🚀📊 was originally published in Angular Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello Windows Insiders, Today, we’re releasing new Windows 11 Insider Preview builds to the Beta and Experimental channels. New builds this week Select your channel below to view its release notes:

• Beta: Build 26320.9876
• Experimental: Build 26340.9882

For those on other specific Windows build versions, here are today’s new builds and release notes:

• Beta (26H1): Build 28020.3445
• Experimental (26H1): Build 28120.3454
• Experimental (Future Platforms): Build 29704.1000

Experimental (Future Platforms) synthetic payload releases Insiders in the Experimental (Future Platforms) channel will begin to notice in the coming weeks that we will be releasing a new build version on a weekly basis, in-between our usual weekly Insider preview builds. These in between releases are just synthetic latest cumulative updates (LCU's), and do not contain any new features or payload. They are helping us test backend flighting and updating services. As such, we will not publish weekly release notes or blogs for these updates, but will keep track of versions in Flight Hub. 

Notable new features:

[Windows Hello]

Release channel: Experimental Windows Hello sign-in improvement

• Sign-in and unlock now behave more consistently and give clearer guidance. You no longer have to wait for face or fingerprint recognition to finish before entering your PIN. Use whichever method works first. At certain times, such as after a restart, you'll need your PIN first. After that, biometrics work as usual.

[caption id="attachment_179264" align="aligncenter" width="1920"] Sign in with face, fingerprint, or PIN, whichever works first.[/caption] Thanks, Stephen and the Windows Insider Program team

Windows is evolving vulnerability management as advances in AI make it possible to discover and analyze security vulnerabilities faster and at greater scale. AI is accelerating vulnerability discovery on both sides. It can help defenders find and fix vulnerabilities earlier. It can also help attackers search for vulnerabilities before fixes are available and analyze published fixes after release. All of this increases the importance of timely protection. Our approach is straightforward: lead across the vulnerability management lifecycle. We’re using advances in AI to find and fix vulnerabilities earlier, while maintaining a high-quality bar so you and your organization can deploy updates with confidence. We’re promptly publishing information about what we fix so security teams can take action. Just as importantly, we’re strengthening the systems that help organizations deploy updates quickly and respond when issues arise. Since our last communication on this topic, we have continued to advance this work across vulnerability discovery, remediation, validation, and deployment.

Finding vulnerabilities earlier

Identifying vulnerabilities before they can be exploited remains the best opportunity to reduce exposure. Microsoft receives vulnerability findings through responsible disclosure from security researchers and partners, while our engineering and security teams find issues internally. These paths come together through the Microsoft Security Response Center (MSRC), which serves as Microsoft’s central hub for vulnerability reporting, security updates and coordinated response. We are increasingly using AI to help security and engineering teams identify vulnerabilities and act on them more efficiently. One example is MDASH, an agentic code scanner that uses multiple AI models and specialized agents to find and validate potential vulnerabilities. Security and engineering teams then review the findings and determine the appropriate response, keeping human judgment and accountability central to the process. The objective is not simply to find more issues. The goal is to identify meaningful vulnerabilities earlier and make the findings more actionable. By using AI-assisted capabilities, we can distinguish relevant findings from false positives. We can give our engineers better information. As vulnerability discovery accelerates, these capabilities help us focus engineering resources on vulnerabilities that have the potential to affect customers more efficiently.

Moving from discovery to remediation faster

Finding vulnerabilities more quickly only helps if engineering processes can keep pace. We are applying AI assistance across the remediation process to help engineers assess impact, determine which versions of Windows are affected, identify variants in related code, evaluate remediation options, develop backport strategies for different versions of Windows, and build security and regression tests. Engineers remain responsible for reviewing the work, making the engineering decisions, and owning the final output. This distinction matters. Our goal is to use automation and AI to help engineers investigate and remediate issues more efficiently, not to remove engineering judgment from security decisions.

Strengthening validation

Increased discovery and remediation also require validation systems that can operate at greater scale. Windows validation combines multiple sources of evidence. Today, it’s internal flighting, functional testing, security proof-of-concept testing, application compatibility testing, and validation with OEMs, security vendors, ISVs, and customers through the Security Update Validation Program. We also apply AI-assisted capabilities to areas including test selection, test creation, triage, analysis, and reporting. Together, those signals provide evidence for engineers making release-quality decisions. Optional non-security preview updates remain an important part of this process. Organizations can install these updates on select devices before the content becomes part of the following month’s security update, providing additional real-world validation across devices, applications, hardware and configurations.

Making vulnerability discovery actionable

AI-assisted discovery is helping us find more vulnerabilities, across more code and earlier in the development process, so we can address more of them through Windows security updates. In fact, the October 2026 monthly security update addressed more than 1,100 Common Vulnerabilities and Exposures (CVEs) for Windows. The number of CVEs doesn’t tell the full story, though. We are using AI to examine more code, more deeply. The research community continues to find and report vulnerabilities. And we are prioritizing fixes in real time as vulnerabilities are identified. A higher number of CVEs does not mean Windows has become less secure. It means more vulnerabilities have been discovered and closed, reducing the opportunities attackers have to exploit them. Transparency makes those fixes more actionable. We publish CVE information for the vulnerabilities we address, whether they are reported by external researchers or identified by our own teams and AI systems. The Security Update Guide provides details on severity, impact, exploitability, and guidance for each CVE. We also make this data available in machine-readable formats, including Common Security Advisory Framework (CSAF) advisories, Vulnerability Exploitability eXchange (VEX) documents, and API, so it can flow straight into your vulnerability management and compliance tools. Security teams can use CVE information to:

• Track which vulnerabilities are addressed on each device.
• Prioritize which devices receive updates first based on exposure, starting with internet-facing systems, identity infrastructure, and high-value assets.
• Measure protection in days from release, not in patch cycles.

Because Windows security updates are cumulative, prioritization should decide which devices update first, not which fixes get deployed.

When protection becomes available, the clock starts

On Patch Tuesday, Microsoft releases monthly security updates and the information and resources you need to evaluate and deploy them. This includes release notes, vulnerability information (available in the Security Update Guide), cumulative updates (through Windows Update and other deployment channels), and updated servicing media. Releasing an update changes what information is publicly available. Before an update is released, vulnerabilities are triaged through coordinated disclosure. Once the update and associated guidance become public, the fix itself can be analyzed. That means attackers might be able to use a published fix to better understand the underlying vulnerability and develop an exploit—potentially within hours. That’s why our work doesn’t stop when an update is released. We monitor diagnostic data and rollout reporting, customer support and inquiries, and feedback from social channels and forums. Automated systems help us correlate those signals and identify patterns for engineering investigation. Engineers investigate potential issues, validate their cause, and determine the appropriate response. Depending on the cause and impact, that response can include updated documentation or guidance, a workaround, Known Issue Rollback (KIR) to mitigate an affected change, or an out-of-band update. This is the lifecycle in practice: discover vulnerabilities earlier, develop and validate protections, publish them transparently, monitor their performance after release, and respond quickly when needed. But there is one part of that lifecycle Microsoft cannot complete alone: getting those protections onto devices.

Reducing your exposure window

Microsoft engineering systems are one half of the equation. Deployment is the other. The time between an update becoming available and reaching your devices is part of your security posture. A recent article by Anthropic¹ noted that N-day exploits (the time between when vulnerabilities are disclosed but only patched on some devices) is a “patch gap”, as large language models now accelerate developing N-day exploits in hours not days as in the past. This has created a heightened risk threat for devices in the “patch gap”. Yet some organizations still take weeks to deploy updates. Diagnostic data from August 2026 showed that, among a measured Windows enterprise sample, fewer than half of devices had installed the security update two weeks after release, and about one in four still had not installed the update after four weeks. That gap between available protection and deployed protection is the exposure window we need to close. We are seeing organizations move in the right direction, accelerating rollout, moving to supported versions of Windows, and adopting newer update management and servicing capabilities. But faster deployment needs to become the standard, not the exception. Organizations should focus on four practical areas:

• Stay on supported versions and install updates promptly after they are released.
• Reduce unnecessary exposure and use security baselines to implement well-tested, industry-proven configurations.
• Maintain endpoint detection and apply available mitigations.
• Establish effective response and recovery practices.

Of those, staying current is foundational. Shortening the time between when Microsoft publishes a fix and when devices receive it reduces how long a known vulnerability remains unpatched. Newer, supported versions of Windows and modern management tools provide capabilities designed to make updating faster and less disruptive. For Windows 11, Windows Autopatch provides update management through Microsoft Intune, including staged deployments and reporting. For eligible devices, hotpatching can apply monthly security updates without a restart, while standard cumulative baseline updates are required periodically. Hotpatching also provides a path to faster protection for Windows Server while reducing restart requirements. Windows Server 2025 supports hotpatch updates² across eligible Azure, Azure Local, and Azure Arc-connected environments, with Azure Update Manager providing patch orchestration. Organizations running older supported versions of Windows client or Windows Server should continue to keep those environments current and use the update management capabilities available to them. Where extended security updates are necessary, treat them as a bridge while moving to a supported version, not as a substitute for modernization. The goal is simple: turn an available fix into deployed protection as quickly as possible. Reduce the update deployment window wherever possible instead of treating security updates as a task that can routinely wait.

Leading at the pace of change

AI is changing the pace of vulnerability management. It gives defenders new ways to find vulnerabilities, analyze code, and develop protections. At the same time, it can shorten the time between public disclosure and potential exploitation. At Microsoft, our commitment is to stay ahead of that change. We are expanding AI-assisted vulnerability discovery, helping engineers move more efficiently from validated findings to fixes, strengthening validation, and monitoring updates after release. We are also investing in the tools and servicing capabilities that help organizations deploy protection faster. As we apply AI across this lifecycle, human judgment and accountability remain fundamental to how we build and service Windows. Our request of every organization is to move with urgency. Stay on supported versions, maintain layered protections, monitor security guidance, and make reducing the time from release to deployment a security priority. Vulnerability management will continue to evolve as AI advances. We intend to lead that evolution, share what we learn along the way, and give customers the information and tools they need to act. But protection ultimately depends on both sides moving quickly: our ability to find, fix, validate, and publish protections, and your ability to deploy them.

---

1. Measuring LLMs’ impact on N-day exploits. Jun 8, 2026. Anthropic 2. Hotpatch updates for eligible Windows Server 2025 machines connected through Azure Arc are available at no additional cost. Windows Server 2025 Datacenter: Azure Edition does not require Azure Arc for hotpatching and has hotpatch updates enabled by default.