The Control Your Insurer Requires Would Not Have Stopped This
On 20 August 2026, Microsoft disclosed a flaw in Entra ID, its cloud identity service, that scored 10.0 out of 10.0 on the industry's severity scale. CVE-2026-69836 let an attacker run code on Microsoft's own infrastructure without a password, a phishing email, or any action from the customer at all. There was no patch to deploy, because there was nothing on a customer's own systems to patch. Microsoft fixed it on its backend and told the world afterwards.[1][2][3]
For a New Zealand board that has spent 2026 hearing its cyber insurer talk about multi-factor authentication, endpoint detection and tested backups as the price of cover, that sentence should stop the meeting. Every one of those controls operates after a user starts to authenticate. CVE-2026-69836 sat beneath authentication itself, in the identity plane that decides whether a login attempt is even real. A board that had done everything its insurer now asks of it, multi-factor authentication on every account, backups tested, an incident response plan on file, would still have been exposed to this flaw for as long as it existed, because the control the insurer requires and the vulnerability that mattered this fortnight do not occupy the same layer of the stack.
Multi-factor authentication is not worthless, and nothing here argues that it is. But a board's assurance model rests on three assumptions this incident broke at the same time, and the checklist your insurer hands you at renewal was never built to catch a flaw like this one.
The Fix Nobody Could Verify
Entra ID is Microsoft's cloud identity service: the system that decides who gets into an organisation's email, files and applications. Because it runs on Microsoft's own infrastructure rather than on a customer's servers, Microsoft could fix CVE-2026-69836 without anyone else's cooperation, and did. Its own account of the incident stated that the issue had been identified and fixed, and that no action was required from customers. For once, a maximum severity vulnerability required nothing of the people it affected. That also meant there was nothing to audit: no patch log, no change ticket, no evidence a board could point to and say, we checked, this was fixed here.[1][2][3]
Microsoft's own bulletin then complicated the picture further. It initially stated the flaw was under active exploitation, then, within days, revised that to say it was not, without explaining what had changed or why. Independent outlets that tracked both versions of the bulletin do not agree on exactly when the correction landed. The vendor's own severity and exploitation status, the two numbers a security team briefs upward from, moved during the same week, and even the technology press could not settle on when.[1][2][3]
Consider a boardroom exchange that could plausibly happen at any insured New Zealand organisation this month. A director opens the renewal papers: "Our insurer's audit passed. MFA everywhere, tested backups, the lot. We're covered." The CISO answers: "We are, for what that questionnaire tests. It doesn't test what sits underneath the login screen itself. The flaw Microsoft found in Entra ID last month didn't need anyone's password. It ran before authentication even started." The director asks what would have caught it. "Nothing we controlled," the CISO says. "Microsoft found it, fixed it on their side, and told us about it afterwards. Our programme did not fail here. The flaw sat below where any programme like ours can reach."
No such conversation was recorded for this article. It is a composite of the argument the incident itself makes, not a transcript, but it is close to the conversation a lot of boards should be having.
Three Assumptions, One Week
Every board's cyber assurance model rests on three assumptions, whether or not anyone has said them out loud. A critical vulnerability produces an action you can take. A vendor's remediation produces evidence you can audit. A vendor's own severity and exploitation statements are stable enough to brief upward from. CVE-2026-69836 broke all three in the same week, on the single component that sits beneath nearly every New Zealand Zero Trust architecture as its root of trust.
Start with the first assumption. Prevention, in the language The Hamberger Report: Cyber Guide for New Zealand Boards uses, means treating an organisation's data as a sovereign asset that specific, deployable controls defend. Multi-factor authentication is the clearest example: a control a board can mandate, a vendor can implement, and an auditor can confirm is switched on. CVE-2026-69836 offered none of that. It lived in Microsoft's own backend, reachable by nobody outside Microsoft, fixable by nobody outside Microsoft. There was no control to deploy, because the vulnerability was never in a place a customer's controls could reach.[4]
The second assumption is where the book's own accountability framework earns its keep. The book sets out Fiduciary Risk Exposure as a formula: FRE equals the cost of remediation, multiplied by the probability of breach, plus the potential loss. In the book's own worked example, the fictionalised ManageMyHealth case, a NZD 1.5 million remediation figure is built from three specific actions: mandatory multi-factor authentication, a behavioural monitoring capability the book calls Audit of Intent, and a shift to zero trust architecture principles. ManageMyHealth's own failure, as the book records it, was that MFA had been optional rather than mandatory. New Zealand's cyber insurers have, over 2026, closed that particular gap: multi-factor authentication is no longer a discount lever, it is close to a condition of cover. CVE-2026-69836 shows what that closes and what it leaves standing. The probability of breach term in the FRE formula cannot be meaningfully reduced by a control that does not reach the layer a given flaw sits in. The duty a board carries does not disappear when the deployable action does. It converts into a duty about which vendors an organisation has concentrated its exposure in, a decision a board actually makes and can be asked to account for, even when patching the specific flaw was never on the table.[4]
That reframing is consistent with, rather than proof of, the book's own formula: FRE was built to price prevention, response and accountability as one continuous obligation, and a dependency a board cannot patch or audit is still a dependency the board chose to rely on. That is the accountability question this incident actually raises, not whether multi-factor authentication works.
The third layer, and the one worth being precise about, is Audit of Intent. The book defines it as a control that moves beyond authentication itself to examine the behavioural and contextual pattern of a transaction: it watches what happens after someone is already in the system, looking for activity that reads as wrong even when the credentials are right. CVE-2026-69836 was an unauthenticated flaw. There was no logged-in actor, and no transaction, for a behavioural layer to have anything to observe. That is not a defect in Audit of Intent so much as a boundary: it was designed to watch what happens after authentication, and this flaw never reached that far. Two of the book's own named controls, multi-factor authentication and Audit of Intent's behavioural layer, both presuppose that authentication has already happened. A flaw underneath authentication itself is invisible to both, by construction, not through any failure of implementation.[4]
Put the three together and the shape of the problem is plain. A vulnerability that offered no customer-side action, a remediation that produced no auditable evidence, and a vendor whose own severity and exploitation statements moved within the same week the flaw was disclosed. Microsoft fixed a maximum-severity flaw before most of its customers had heard of it, and none of this is a criticism of that engineering response. What it describes instead is what a board's assurance model looks like when the thing that needed governing was never within the board's reach to govern in the first place. Concentration, not remediation, was the lever that was actually available the whole time.
What New Zealand's Insurers Actually Require Now
The shift behind that renewal conversation is real, even where the numbers attached to it in the local market are not always as solid as the marketing around them suggests. Aon's Q1 2026 Global Insurance Market Insights describes risk qualification as remaining critical to underwriters, and states that capacity is limited where minimum security standards are not met, while separately describing New Zealand's cyber market that quarter as soft, with abundant capacity and flexible underwriting.[5] Insurance Business New Zealand's reporting in August 2026 describes local carriers requiring documented multi-factor authentication, incident response planning and framework alignment as preconditions of cover, and frames the market's central tension plainly: premiums are falling at the same time scrutiny is tightening.[6]
That is a genuine, internationally corroborated pattern rather than a New Zealand quirk. Aon's global report describes cyber pricing beginning to moderate after a prolonged period of softness, while underwriters keep risk qualification critical. Price and scrutiny are moving in different directions at once, here and everywhere else Aon covers.[5]
What that scrutiny actually checks varies by underwriter, and the limits of what can be said with confidence here matter. New Zealand brokers and managed service providers commonly describe a five-part checklist behind current eligibility decisions: multi-factor authentication on email, remote access and administrative accounts, endpoint detection on every device, tested and offline or immutable backups, enforced email authentication, and a documented incident response plan. That list is consistent across enough of the market to describe as illustrative current practice, but it traces mainly to vendors selling those same controls, so it reads as a picture of what insurers are asking for, not as an audited or independently verified standard.
New Zealand's National Cyber Security Centre has, separately, published guidance on third-party and supply chain security that predates and is unrelated to this specific flaw, addressed further below.[7] No New Zealand-specific incident or victim connected to CVE-2026-69836 has surfaced at the time of writing, and no dedicated New Zealand government advisory on this particular vulnerability was found either. That absence is not evidence the flaw did not matter here. Entra ID is used by the same proportion of New Zealand organisations as everywhere else Microsoft's cloud identity service runs. It simply means no New Zealand-specific monitoring was ever positioned to see it, because nothing about this flaw was New Zealand-specific to begin with.
The Question Boards Should Be Asking Instead
None of this argues against multi-factor authentication, tested backups or any control your insurer requires. It argues that passing the renewal questionnaire and being secure against the incidents that actually happen are two different claims, and a board that treats them as the same claim carries a blind spot exactly the size of CVE-2026-69836.
Four questions follow directly. First, ask which layer each control your insurer requires actually reaches. Multi-factor authentication governs who gets past the login screen. It says nothing about what sits beneath the login screen itself, in the identity provider's own infrastructure. Second, ask how many of the organisation's critical systems depend on a single identity provider, a single cloud platform, or a single managed service, and treat the answer as a Fiduciary Risk Exposure input in its own right, not as a procurement detail. Concentration is a decision the board makes, even when nobody frames it as one. Third, treat a vendor's own severity rating and exploitation status as provisional, not settled, for as long as the vendor itself keeps revising them. A number that moved twice in one week should not be the last thing briefed to the board before the papers close. Fourth, ask what would actually have to be true for the organisation to detect a flaw at this layer independently, rather than learning about it from the vendor's own disclosure. For most organisations, honestly answered, the answer is nothing would.
None of those four questions appears on a standard insurance renewal checklist, and that gap matters more than the CVE itself. The checklist your insurer hands you was built to price a different kind of risk: the risk that your organisation has not deployed known, deployable controls. CVE-2026-69836 was a different kind of risk again, one your organisation could not have deployed a control against no matter how good its programme was, because the layer it lived in was never yours to control. Naming that distinction, on the record, in board papers, is itself an act of governance. It is also the only one available.
The identity plane itself has an open alternative, and it is worth naming here. FIDO2 and WebAuthn, the passwordless authentication standard developed jointly by the FIDO Alliance and the World Wide Web Consortium since 2013, are published specifications that any vendor, auditor or independent researcher can inspect, implement and test, rather than a single company's proprietary control plane.[8] That does not make an open standard immune to flaws of its own, and CVE-2026-69836 sat beneath authentication entirely, in territory neither a proprietary nor an open scheme currently reaches. But it does mean the industry is not permanently dependent on trusting one vendor's account of its own severity and exploitation status. Coordinated, publicly reviewable disclosure is the same discipline the CVE numbering and disclosure system was built to provide, and boards should understand the difference between a control they can inspect and one they can only take on trust.
New Zealand's National Cyber Security Centre published supply chain guidance on 4 August 2026, stating that organisations are required under the Privacy Act 2020 to implement reasonable security safeguards, and that third-party suppliers can become the easier target when those safeguards are not in place.[7] Entra ID is the third-party dependency that guidance describes: a single identity provider now sitting beneath the authentication layer of most New Zealand organisations that run a Zero Trust architecture, critical infrastructure operators among them. The guidance predates this flaw and was not written in response to it, but it raises the same underlying question this incident does: how much of an organisation's security posture rests on a dependency it did not choose and cannot patch, and what that means when the root of trust for a jurisdiction's Zero Trust architecture sits inside one vendor's backend, invisible until it fails.
Where This Leaves the Boardroom
CVE-2026-69836 will eventually be fixed and forgotten, replaced by the next maximum-severity flaw sitting in whatever infrastructure the next insurer's checklist does not reach. The controls your insurer already requires remain worth having; the mistake is reading the checklist itself as a description of your organisation's actual exposure, rather than as a floor beneath it. The gap between the two is exactly where CVE-2026-69836 lived for however many days it existed before Microsoft found and fixed it, unseen by every board whose assurance model assumed a passed audit meant a covered risk.
So here is the boardroom question worth actually asking at the next renewal, not the one the questionnaire already answers for you: if your organisation's most critical dependency failed tomorrow in a way no control you have deployed could have caught, would anyone in the room already know which vendor that dependency is, and what it would take to find out?
If your board wants an independent AI and cyber risk briefing, or a review of what your vendor's assurance actually verified, message me and I will send the scope and the fixed fee.
The views expressed in this article are entirely my own, informed by morethan 30 years of professional experience in architecture, security, andtechnology leadership in New Zealand. I write as director of Te PonoLimited; the views are personal and do not represent the position of anyclient, any government agency, or the New Zealand government. My commentaryon legislation and policy is analytical, drawing on publicly availablesources and my professional expertise in architecture, security, and AIgovernance, and it is politically neutral.
Andreas Hamberger is a New Zealand leader in Architecture & Security and Associate Member of the Institute of Directors. The Hamberger Report: Cyber Guide for New Zealand Boards is the third book in The Hamberger Report series, providing board members and senior leaders with practical cyber resilience governance guidance. Through Te Pono he provides independent AI and cyber risk briefings and vendor assurance reviews to boards; contact andreas@thehambergerreport.com for the scope and fixed fee.
This article was produced with AI assistance under my direction. Research,drafting and images pass through a pipeline I built and govern: automatedgates for source verification, forbidden language and political neutrality,and my own review before anything is published. The tools include Claude,Gemini and Openart. The frameworks, arguments and editorial judgements aremine and are the same discipline I apply to the AI systems I audit forclients. AI accelerated the work; the thinking, and the responsibility forit, are mine.
[1] Help Net Security. "Microsoft Entra ID Vulnerability (CVE-2026-69836)." 21 August 2026. https://www.helpnetsecurity.com/2026/08/21/microsoft-entra-id-vulnerability-cve-2026-69836/
[2] The Hacker News. "Microsoft Entra ID Flaw Scores CVSS 10.0." August 2026. https://thehackernews.com/2026/08/microsoft-entra-id-flaw-cvss-100.html
[3] Cybersecurity Dive. "Microsoft Discloses Maximum-Severity Flaw in Entra ID, Then Revises Exploitation Status." 21 August 2026. https://www.cybersecuritydive.com/news/microsoft-maximum-severity-flaw-entra-id-exploitation/828501/
[4] Hamberger, Andreas. The Hamberger Report: Cyber Guide for New Zealand Boards. 2026. (Internal source file; no public URL.)
[5] Aon. Q1 2026 Global Insurance Market Insights. Published 4 May 2026. (No URL captured for this source.)
[6] Bolivar, Rod. "NZ Cyber Guidance Lands Just as Cheap Cover Gets Cheaper." Insurance Business New Zealand. 18 August 2026. (No URL captured for this source.)
[7] National Cyber Security Centre New Zealand. "Strengthening Your Supply Chain Security." 4 August 2026. https://www.ncsc.govt.nz/news/strengthening-your-supply-chain-security/
[8] FIDO Alliance and World Wide Web Consortium (W3C). WebAuthn specification. (No URL captured for this source.)