In This Article
On November 5, 2026, Microsoft published a critical vulnerability in Entra Device Registration, the service that gives laptops and phones an identity in your Microsoft 365 tenant. It scored 10.0, the top of the scale. The same record says there is nothing for you to install.
That pairing is new for a lot of IT teams. A CVSS 10 usually means a patch ticket, a change window and a late night. This one, CVE-2026-109469, was fixed on Microsoft's side before Microsoft announced it, so your team keeps its week. What it leaves is a short job: a look at who can add devices to your tenant, and a dated note of what you checked, ready for the day an examiner or auditor asks how you knew.
"Authorization bypass through user-controlled key in Entra Device Registration allows an unauthorized attacker to elevate privileges over a network." Critical. Elevation of Privilege. CVSS 3.1 base score 10.0. Not publicly disclosed, not exploited, exploitation less likely. "This vulnerability has already been fully mitigated by Microsoft. There is no action for users of this service to take."
This guide to the Entra Device Registration vulnerability is for IT, security and compliance leaders at credit unions, banks, and mortgage companies running Microsoft 365. ABT is a Tier-1 Microsoft Cloud Solution Provider serving 750+ financial institutions, and we manage Microsoft 365 tenants for many of them. Below: what Microsoft has said, how to record a cloud vulnerability you never had to patch, and the device registration settings worth a look while the topic is open.
What Microsoft published
The record is short. Microsoft titles it "Entra Device Registration Elevation of Privilege Vulnerability" and maps it to CWE-639, Authorization Bypass Through User-Controlled Key. In plain terms, that weakness class covers a service that trusts an identifier the requester supplies when deciding what the requester may touch.
The CVSS vector, AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, describes the worst case on paper: reachable over the network, low complexity, no account needed, no user interaction, with impact that crosses a security boundary. Microsoft's temporal score is 8.7, which reflects an official fix in place and no proven exploit code.
Three things in the record matter most for a financial institution:
- Status. Microsoft lists the flaw as not publicly disclosed and not exploited when it published.
- Customer action. The record carries "Customer Action Required: No" and says the fix is already in place.
- Timing. Microsoft published revision 1.0 on November 5. The National Vulnerability Database picked it up on November 6 and lists it as awaiting analysis.
Microsoft has described the flaw in one sentence. It has named no key, no operation and no privilege boundary, and it has published no indicators to hunt for. Any write-up that goes further than that sentence is guessing, and your records should stay with what Microsoft published.
Why a fixed cloud flaw still goes in your file
Microsoft started publishing CVEs for its own cloud services on purpose. In a June 27, 2024 post, the Microsoft Security Response Center said it would issue CVEs for "critical cloud service vulnerabilities, regardless of whether customers need to install a patch." Those records carry a tag, exclusively-hosted-service, that tells you no customer action is required.
We counted how often that happens. ABT read Microsoft's own Security Update Guide data for August through November 2026 through the public MSRC API on November 9.
That works out to roughly six a week. Most compliance programs were built around patches you deploy: a scanner finds a missing update, a ticket opens, a change closes it. A cloud service CVE skips every one of those steps, so it can pass through your program without leaving a trace. When an examiner or auditor pulls your vulnerability log and asks about a CVSS 10 in your identity provider, an empty row reads worse than a row that says "vendor-remediated, reviewed." At six a week, this is a standing lane in your program, and whoever manages your tenant should be able to show you how they work it.
Regulators have framed cloud oversight this way for years. The FFIEC's 2020 statement on cloud computing speaks to exactly this split between what the provider runs and what the institution watches:
"Ongoing oversight and monitoring of a financial institution's cloud service providers are important to gain assurance that cloud computing services are being managed consistent with contractual requirements, and in a safe and sound manner."
The same statement talks about "management's understanding of the shared responsibilities between cloud service providers and their financial institution clients." A cloud service CVE is a clean example of that split. Microsoft owns the fix. You own knowing about it, deciding whether anything in your tenant needs a closer look, and keeping a record of both.
Here is a lightweight way to record one, which works for this CVE and every one like it:
Add the CVE to your vulnerability register with the Microsoft link, the revision number and the date you saw it.
Copy the customer action line and the exploitation status, word for word, as they read on the day you reviewed.
Note which of your controls depend on the affected service and whether you reviewed them. For this one, that is device registration.
Close it as vendor-remediated, with the reviewer's name, and recheck the record if Microsoft issues a new revision.
If you already use Microsoft's tools to rank what you patch, our guide to Defender Vulnerability Management for financial institutions covers the patch side. Cloud service CVEs need this second, smaller lane next to it, because they never show up as a missing update on a device.
Why device registration matters to an institution
Device registration is the front door for every device-based control in Microsoft 365. When your Conditional Access policy requires a compliant device before someone opens member data from a laptop, the policy is trusting the device identity that registration created and the compliance status that Microsoft Intune reports against it. Our earlier guide to risk-based device compliance with Intune walks through how those policies grant access. Those compliance policies and Conditional Access gates are where M365 Guardian, ABT's operating model for Microsoft 365, does its device work. Guardian configures Intune compliance policies, BitLocker encryption, OS security baselines and conditional access gates in the tenants we manage, and monitors them for configuration drift.
That is why the settings around registration deserve a look now that a 10.0 has put the service in the news. The settings decide who can add a device, what they must prove first, and how many devices one account can hold. Microsoft's defaults favor getting people working over checking who is adding a device.
Third-party enrollment is a related path. Our piece on MDM enrollment attacks covers what happens when a device management service is the weak point. This article stays with the Entra side: the registration step that every Microsoft-managed device passes through first.
Five device settings to check this week
All five live under Entra ID, then Devices, then Device settings, plus one Conditional Access policy. Changing the device settings needs at least the Cloud Device Administrator role, and creating the Conditional Access policy needs at least the Conditional Access Administrator role. If a provider holds the admin accounts in your tenant, send them the table below and ask for the current value in each row. Here is what Microsoft sets by default and what to look for:
| Setting | Microsoft default | What to look for |
|---|---|---|
| Users may join devices to Microsoft Entra ID | All | A named group, such as IT staff, if only IT builds your Windows devices |
| Users may register their devices | All (fixed at All when Intune is configured) | Know which personal devices this lets in, and what your Conditional Access policies allow them to reach |
| Require MFA to register or join devices | No | Leave at No and enforce MFA with a Conditional Access policy instead, as Microsoft recommends |
| Conditional Access: Register or join devices | No policy | A policy for all users requiring MFA, with emergency access accounts excluded |
| Maximum number of devices per user | 50 | A lower number that fits how many devices one person really carries |
The third and fourth rows trip people up. Microsoft's guidance says that when you use the Conditional Access "Register or join devices" user action, the older device-settings MFA toggle must be set to No. Otherwise, Microsoft says, Conditional Access policies with that user action are not properly enforced. A tenant with both switched on can look stricter than it is.
In Device settings, change "Users may join devices to Microsoft Entra ID" from All to the group that actually builds your machines. Microsoft notes this setting does not cover hybrid joined devices, Entra joined Azure virtual machines or Autopilot self-deploying mode, so those paths need their own review.
Create a policy for all users, exclude your emergency access accounts, target the Register or join devices user action and require the built-in Multifactor authentication strength. Run it in report-only mode first, then turn it on.
Once the Conditional Access policy is in place, set "Require multifactor authentication to register or join devices" to No so the policy enforces as Microsoft intends.
The default of 50 devices per user is generous for a teller, a loan officer or a member service rep. A smaller number makes an unusual burst of registrations stand out.
Device settings also decide who becomes a local administrator on Entra joined devices. Confirm the tenant-wide list is short and that the person joining a device is added as local admin only if you intend it. Our guide to Intune Endpoint Privilege Management covers retiring standing local admin rights.
Each one narrows who can add a device to your tenant and what they must prove first, which is the part of device trust that you own.
"Microsoft fixed this one. Your file should still show how you knew and what you checked."
Serving 750+ financial institutions since 1999
See where device enrollment and compliance stand in your tenant
ABT's free Security Assessment reviews Intune enrollment status, compliance policies, OS patch levels and encryption across managed and unmanaged devices, then delivers a written report with specific findings and a prioritized hardening roadmap.
What your logs can show
Microsoft has published no indicators for this CVE, so there is no signature to search for. A review of your device inventory and device audit logs is still a reasonable piece of local evidence, and it is cheap.
Start with the inventory. On the All devices page, Download devices exports a CSV that includes each device's registration date, approximate last sign-in, join type, compliance status, managed status and owner. Sort by registration date and look at anything added recently that nobody can place, any device with no owner that should have one, and any account holding far more devices than its job needs.
Then the audit trail. Under Devices, Audit logs shows device creation, owners and users being added to a device, settings changes, and devices being updated or deleted. A change to the device settings themselves that nobody on your team made is worth a question to whoever holds admin rights.
Be clear in your notes about what this review proves. A clean result shows your inventory and settings are in order today. It neither proves nor disproves anything about the flaw, because Microsoft has said nothing about how it could have been used.
You find a device you cannot explain: a recent registration with no owner, an unfamiliar name, or an account with a sudden run of new devices.
Save the export and the audit entries first. Disable the device rather than deleting it: Microsoft says disabling stops it authenticating and revokes its Primary Refresh Token and refresh tokens, while deleting is nonrecoverable and removes details such as BitLocker keys. Then follow your incident response plan.
Your Microsoft 365 incident response plan should already say who makes that call and who talks to Microsoft support. If a device you cannot explain also has an account behind it that signed in from somewhere odd, our guide to the Microsoft 365 token replay campaign covers the session side. If you want a second set of eyes before you act, talk it through with an ABT financial services IT strategist.
Questions for your provider
If a provider manages your Microsoft 365 tenant, the questions below are fair to ask in writing, and the answers belong in your vendor file next to the CVE entry:
- Did you see CVE-2026-109469, and where did you record it?
- How do you track Microsoft cloud service CVEs that need no customer action, and how do you tell us about them?
- Who can join and register devices in our tenant today, and is MFA required at that step?
- What is our device limit per user, and who holds local admin on our Entra joined devices?
- When did you last review our device inventory for devices nobody can place?
These questions apply to ABT exactly as they apply to any provider. Put them to us on the same terms: bring them to an ABT financial services IT strategist and compare our answers with the ones you have. Our Microsoft 365 vendor due diligence guide covers how to document them.
Key Takeaway
CVE-2026-109469 needs no patch, and it still deserves three things from a financial institution: a line in your vulnerability register with Microsoft's own wording, a look at who can add devices to your tenant and what they must prove first, and a dated note of what you reviewed.
How ABT helps
ABT serves 750+ financial institutions and manages Microsoft 365 tenants for many of them. M365 Guardian covers the device side of this picture: its Device Compliance work includes "Intune compliance policies, BitLocker encryption, OS security baselines, conditional access gates," and its monitoring phase covers configuration drift detection, Secure Score tracking and policy gap alerts.
Guardian's Insights phase produces monthly Security Insights reports, executive summaries and examiner-ready documentation. Microsoft's record covers its side of a cloud service CVE. Those reports are your institution's dated documentation of its own tenant, and they belong in the same file.
The checklist above is the registration side, which your team or your provider sets once and revisits. The side that trusts a device after it is registered is where the ongoing work sits.
Microsoft runs the device registration service and fixed this flaw in it. The settings that decide who registers a device, and the Conditional Access policies that trust that device afterward, are configured in your tenant. ABT's Security Assessment reviews "Intune enrollment status, compliance policies, OS patch levels, and encryption settings across managed and unmanaged devices," with a gap analysis against FFIEC and NIST CSF frameworks.
The free ABT Security Assessment is a good first step for a fresh look at device enrollment and compliance. You get a written report with specific findings and a prioritized hardening roadmap.
Keep the policies that trust your devices configured and watched
M365 Guardian configures Intune compliance policies, BitLocker encryption, OS security baselines and conditional access gates in your tenant, watches for configuration drift, and delivers monthly Security Insights reports with examiner-ready documentation.
Frequently Asked Questions
CVE-2026-109469 is a critical elevation of privilege vulnerability in Microsoft Entra Device Registration, published by Microsoft in its Security Update Guide on November 5, 2026 with a CVSS 3.1 base score of 10.0. Microsoft describes it as an authorization bypass through a user-controlled key and lists it as not publicly disclosed and not exploited.
No patch is needed. Microsoft says the vulnerability has already been fully mitigated and there is no action for users of the service to take. Record the CVE in your vulnerability register with Microsoft's wording, then review your device registration settings as good practice.
Microsoft committed in June 2024 to issue CVEs for critical cloud service vulnerabilities whether or not customers need to install a patch, for transparency. These records carry the exclusively-hosted-service tag. ABT counted 81 such CVEs from Microsoft between August 1 and November 9, 2026, none marked exploited.
Log the CVE with Microsoft's link, revision and the date you saw it. Copy Microsoft's customer action and exploitation status word for word. Note which of your controls depend on the affected service and what you reviewed. Close it as vendor-remediated with the reviewer's name, and recheck if Microsoft revises the record.
Review who may join devices, which defaults to all users; whether MFA is required at registration, ideally through a Conditional Access policy on the Register or join devices user action; the device limit per user, which defaults to 50; and who becomes local administrator on Entra joined devices.
Your logs can show whether your device inventory and settings are in order, which is useful local evidence. They cannot prove or disprove exposure to this flaw, because Microsoft has published no indicators or technical detail. Review recent device registrations and device audit events, and keep the export with your CVE record.
