The uncomfortable part is not the patch
A Dynamics advisory lands in the inbox. Two vulnerabilities fixed. One of them is CVE-2026-65772 with a CVSS score of 8.80 and arbitrary code execution. The other, CVE-2026-77897, is a privilege escalation issue with a CVSS of 7.00.
The easy reaction is familiar: create a ticket, note the maintenance window, move on.
That reaction is also the problem.
Because a vendor patch does not tell you whether the affected path exists in your environment, who owns it, or whether anyone still relies on it in production. It only tells you the vendor has closed one door. It says nothing about whether your organization still has the keys, the side entrance, or the forgotten corridor behind three integrations and a service account nobody has touched in a year.
That is the real test for software leaders. Not whether the bulletin is serious. It is. The test is whether your team can answer, within minutes, where the advisory lands and whether the affected path is actually used.
If they cannot, you do not have a patching problem. You have an ownership problem.
The place where advisories get translated into business damage
Most companies do not run Dynamics as a single neat application. They run it as a mesh of customer records, automations, approvals, reporting jobs, and integrations that grew around the business one request at a time.
That is why advisories like this matter more than their headline suggests.
Dynamics 365 is not just a screen for sales or service teams. It is often connected to workflows that touch pricing, customer status, case handling, and downstream systems that trust whatever comes out of it. Power Automate sits in the same neighborhood: quiet, useful, and easy to forget until it is the thing moving data between systems with more authority than anyone intended.
So when Microsoft patches a Dynamics issue with a route to arbitrary code execution, the question is not abstract. It becomes practical very quickly:
Who can tell you where that instance is?
Who knows whether it is online or on-premise?
Who can say which integrations depend on it, and which of those still matter?
If the answer lives in a Slack thread, a half-finished spreadsheet, or one engineer’s memory, the organization is already behind the actual problem.
What I would check first
Before anyone starts a programme, I would check three things.
First: where the advisory lands. Not the vendor category, the actual deployment. Online, on-premise, hybrid, test clone, forgotten instance. If you cannot place it, you cannot prioritize it.
Second: who owns the path. Not the product owner in theory. The person who can say what business process breaks, who gets paged, and what downstream system depends on it. Ownership is not a title here. It is reachability.
Third: whether the affected capability is actually used. A vulnerability in a feature nobody exposes is different from one sitting under a live workflow that handles customer or internal data every hour. The distinction matters because software teams are full of unused surface area that looks important on a diagram and is irrelevant in practice.
That is the first check I would make before any broad response.
Not because it is elegant. Because it is faster than pretending every advisory deserves the same treatment.
Why this keeps happening in mature teams
The deeper issue is that most organizations still organize around systems, while the exposure lives in paths.
A system can be owned. A path is usually shared.
One team owns Dynamics. Another owns the integration into the ERP. A third owns the Power Automate flow that pushes approvals to finance. Security gets the advisory. Operations gets the ticket. The business gets told there is a fix. Everyone is technically involved, and nobody is fully responsible for the route the issue actually travels.
That is how a patch becomes a coordination exercise instead of a decision.
And coordination is expensive when the question is not “is it patched?” but “what else did this component touch before the patch, and what still depends on it now?”
The practical consequence is not dramatic. It is worse than dramatic. It is ordinary.
A stale permission model stays in place because it was “part of the rollout.” A legacy on-prem instance remains reachable because it still feeds a report. A workflow keeps running because no one wants to break month-end.
None of that is unusual. That is exactly why it matters.
The consequence for leaders is clarity, not volume
The temptation after a bulletin like this is to widen the blast radius in your mind until everything looks urgent.
That is a weak response.
A better response is narrower and harder: force clarity on reachability, ownership, and use. If your team can answer those three things quickly, the advisory becomes manageable. If they cannot, the issue is not the CVE. The issue is that your software estate still depends on tribal knowledge to tell you where the real exposure sits.
That is where leadership shows up.
Not in how many patches you approve. Not in how many tickets you open.
In whether your organization can distinguish between a vendor bulletin and an actual business path that still matters.
Because the difference decides how long you spend reacting, how much trust you burn internally, and whether the next advisory becomes a routine change or a scramble to reconstruct your own environment.
The Microsoft Dynamics advisory is a useful reminder for exactly that reason. CVE-2026-65772 is not just a number with an 8.80 score. It is a signal that the old habit of treating patch notes as proof of safety is too shallow for the systems we now run.
The first question is not whether it is fixed.
It is whether anyone in your organization can answer, within minutes, where it lands and who owns the path it touches.