Andreas H 26/05/2026 Andreas H 26/05/2026

Cybersecurity Governance: The Week AI Found the 18-Year-Old Hole

Four incidents, one pattern: AI discovers faster than boards govern

Six hours.

That is how long it took an autonomous AI system to find a vulnerability that had been hiding in NGINX's source code for eighteen years.

The flaw is CVE-2026-42945, a heap buffer overflow in NGINX's rewrite module. According to F5's official advisory K000159247, published on 13 May 2026, the vulnerability carries a CVSS v4.0 score of 9.2 Critical. [1] depthfirst, a security research firm, found it using autonomous AI source-code analysis in approximately six hours. Public proof-of-concept exploits appeared on GitHub the same day F5 published the advisory. In-the-wild exploitation followed within hours. Eight days later, a separate researcher published an ASLR bypass chain that converts this vulnerability into a reliable remote-code-execution path on default configurations. [2]

This is not a story about one vulnerability. It is a story about tempo. The discovery pipeline now runs at machine speed. The remediation pipeline still runs at human speed. Your board's governance cycle? Quarterly.

In the week of 16 to 22 May 2026, four concurrent incidents placed this asymmetry on display. Each one is distinct in its sector, its geography, and its immediate implications for governance. The pattern underneath all four is identical: the speed at which threats materialise, propagate, and demand decisions has changed in a way that most board governance structures have not yet absorbed.

Four incidents. One pattern. The tempo of attack has changed. The tempo of governance has not.

The AI Asymmetry Thread

Before working through each incident, the governing thread needs stating clearly, because it is easy to read a list of cyber events and conclude that the lesson is "more incidents." It is not. The lesson is about the structure of the asymmetry.

NGINX has run on roughly 30% or more of publicly accessible web infrastructure globally, including a material proportion of New Zealand government, university, hospital, and commercial sites. [3] The vulnerability in question has been present in every standard NGINX build since 2008. Eighteen years of human code review, across millions of audits, penetration tests, vulnerability assessments, and bug bounty programmes, missed it. An AI source-code analysis system found it in approximately six hours.

That gap is not a failure of the human reviewers. It is an architectural property of the new threat environment. Defensive AI is now operating as an offensive capability at the same time. The same class of tool that can scan your codebase for vulnerabilities can scan your adversary's targets. The same speed advantage that benefits your security team benefits theirs.

The Audit of Intent framework, which this series introduced in the Prevention pillar, anticipated this shift: behavioural analytics running continuously at machine speed to detect what systems appear to be trying to do. The NGINX Rift is the empirical case that framework was built for. Boards should not read this story as unusual. They should read it as the new baseline.

CVE-2026-42945: What Your Organisation Needs to Know

The technical details matter only insofar as they define the board question. Here they are, briefly.

CVE-2026-42945 is present in every standard NGINX build from 2008 to May 2026. Patched versions are NGINX Open Source 1.30.1 and 1.31.0, and NGINX Plus R32 P6 and R36 P4. Any installation running NGINX Plus R32 P5 or earlier, or NGINX Open Source 1.30.0 or earlier, with rewrite rules enabled, is currently exposed. NGINX Instance Manager and F5 WAF patches were pending at the time of the initial advisory; verify their current status directly with F5. [1]

According to Akamai's security intelligence analysis and HeroDevs' NZ-specific advisory note, the vulnerability affects load balancers, reverse proxies, API gateways, and CI/CD pipelines as well as traditional web servers, because all of these can run NGINX with rewrite rules enabled. [2] [3] That scope is why the board question is not "do we use NGINX on our website?" but something considerably broader.

The exploitation lifecycle is what boards need to understand: the vulnerability was discovered on approximately 7 May 2026, disclosed publicly by F5 on 13 May 2026, had working public proof-of-concept exploits the same day, confirmed in-the-wild exploitation within hours of disclosure, and an ASLR bypass chain published 21 May 2026 that lowered the exploitation bar further. [2] From responsible disclosure to a documented ASLR bypass: eight days. That is the new tempo.

The board question: has someone in your organisation verified, since 13 May 2026, that every NGINX deployment you own, operate, or depend on through vendors is running a patched version or has a documented compensating control? Vendor-hosted infrastructure counts. If your primary SaaS providers run NGINX on the platforms they host for you, the question extends to them. This is a verification task that needs to happen in days, not at the next quarterly review.

The Canvas LMS Governance Trap

On 11 May 2026, Instructure, the company behind the Canvas learning management system, announced a settlement with the threat actor responsible for a breach that began with initial access on 29 April 2026 and a secondary attack on 7 May 2026. The settlement included, in Instructure's words, digital confirmation of data destruction via shred logs.

Victoria University of Wellington, operating Canvas under the Nuku brand, and the University of Auckland both confirmed they were affected. [4] [5] Exfiltrated data included names, email addresses, student ID numbers, course enrolment data, and the plain-text contents of in-platform direct messages.

The shred log is a governance trap.

Here is the analytical finding, stated plainly. A shred log confirms deletion on the attacker's declared devices at a declared point in time. It cannot confirm the absence of prior copies, off-network copies, or copies shared with third parties before the local deletion was executed. It is not possible to prove, by any technical means, that an unauthorised actor has not retained encrypted, offline copies of exfiltrated data. The shred log is a policy artefact. It is not a technical guarantee.

This distinction matters enormously under Section 137 of the Companies Act 1993, which establishes the duty of reasonable care, diligence, and skill for directors. The question that standard asks is not whether the vendor claimed data destruction. It is whether the board understood the limits of that claim, sought independent technical validation where possible, and documented their position. A director who cites a vendor's shred log as assurance has accepted an unprovable claim. The board minute should reflect that the director understood what the log covers, what it cannot cover, and what steps, if any, were taken beyond vendor assurance.

For boards of tertiary institutions, health providers, and social service organisations using analogous platforms: what does your independent technical validation of a vendor's shred log actually look like? Not as a theoretical question. As a governance record question. Document the answer, whatever it is.

One further point specific to the NZ context. Canvas in-platform direct messages between students and staff may contain sensitive cultural or health disclosures. Under the Cultural Security Envelope framework this series introduced, the governance obligation extends beyond notification to an assessment of whether the nature of the exposed data carries distinct obligations toward tauira Maori whose communications may have been among the exfiltrated content. Institutions with significant Maori student populations should make that assessment explicit in their breach response records. [4]

The OPC Inquiry: From Incident Response to Regulatory Accountability

The Office of the Privacy Commissioner has published terms of reference and opened a formal independent inquiry under section 17(1)(i) of the Privacy Act 2020 into the ManageMyHealth breach. [6]

Those who have followed this series from the beginning will recognise MMH as the primary case study through all ten chapters of the Cyber Guide arc. What changed this week is the category of event. An OPC formal inquiry is a statutory review, not incident response. The Commissioner may compel production of documents and require explanations under the Privacy Act's compulsion powers.

The terms of reference cover two areas: ManageMyHealth's architectural security baseline at the time of the breach, and its data retention policies, with particular focus on the repository containing clinical correspondence, hospital discharge summaries, and referral letters from 2017 to 2019. [6] Initial findings are expected later this year. This article is the appropriate point to note the inquiry has opened and describe what the terms of reference cover. It is not the appropriate point to speculate on findings or characterise scope.

What this means for boards beyond MMH is a benchmark question. When the OPC evaluates what reasonable security practice looks like for an organisation operating a health platform at this scale, it will establish a reference standard. That standard will apply prospectively. The terms of reference published this week are, in practical terms, a gap analysis template for any board operating a health-adjacent platform with similar data profiles. The questions the OPC is asking about MMH are the questions your board should be asking about your own architecture. Before the Commissioner asks them.

Kordia's 2026 NZ Business Cyber Security Report found that 44% of New Zealand businesses experienced a cyberattack in the past twelve months, and 61% of those suffered serious business disruption. [7] The NCSC logged 1,249 incidents in a single quarter of 2025. [8] Those figures establish the baseline probability. The OPC inquiry establishes the accountability standard. Together they define the governance environment in which your board is operating.

The Grafana No-Pay Template: A Worked Example

Grafana Labs confirmed, in the week of 16 to 22 May 2026, that it had suffered unauthorised access to its private GitHub environment via leaked credentials, with bulk exfiltration of proprietary source code, followed by an extortion demand. Grafana's response is the clearest 2026 example of a code-exfiltration-only extortion scenario executed cleanly. [9]

Grafana publicly refused to negotiate or pay, citing FBI guidance against funding criminal operations. The company immediately invalidated all compromised credentials and revoked access. It retained specialist forensic investigators and confirmed no customer data or personally identifiable information was compromised. It issued a public disclosure with a timeline. According to Grafana's subsequent communications, the threat actor made no documented follow-on public move. [9]

Why does this matter for New Zealand boards specifically? Under the DPMC's proposed critical infrastructure security regime, a board decision on whether to pay an extortion demand will be a board-level accountability moment. The proposed framework includes personal criminal liability for serious breach failures of up to NZ$500,000. [10] That regime is proposed, not yet enacted. Submissions closed in April 2026 and are under analysis. But the governance preparation required is the same whether the regime passes or not: your board needs a documented decision framework for this scenario before the scenario arrives, because the decision under pressure, without a framework, is the one most likely to be wrong.

The Grafana case works as a template specifically because it is a code-exfiltration-only scenario, with no customer data involved. The response logic in that scenario: refuse payment with documented regulatory basis; invalidate credentials as the primary technical control; retain independent forensics; disclose publicly. This logic does not apply uniformly. When customer data is involved, when operational continuity depends on the attacker's cooperation, or when the threatened harm extends to individuals, the calculus changes materially. But every board needs to know, before the incident, which scenario type they are facing and what their response authority structure looks like.

The Hour-Zero Protocol, introduced in the Response pillar of this series, addresses this decision architecture. The Grafana case is the contemporary worked example that gives the Protocol empirical weight. Reading them together is time well spent.

Three Board Questions for This Week

The four incidents this week are not an argument for alarm. They are an argument for precision. Three specific actions your board should be able to confirm before the next meeting:

The first: has someone verified, specifically since 13 May 2026, that every NGINX deployment your organisation owns, operates, or depends on through vendors is running a patched version or has a documented compensating control? This is a 48-hour action item. The Layer3 NZ Threat Landscape 2026 report identified unauthorised access as the largest source of NZ direct financial loss in Q2 2025, at NZ$3.7 million. [11] Unpatched critical infrastructure is the most common entry point.

The second: when your most critical SaaS vendor reports a breach settlement that includes data-destruction confirmation, what independent validation does your organisation require before accepting that assurance? If the answer is "we accept the vendor's statement," your board has accepted an unprovable claim. The shred-log problem does not mean the claim is false. It means the claim is unverifiable, and your board should document its position on that distinction.

The third: does your incident response framework include a documented decision tree specifically for code-exfiltration-only extortion scenarios? Not a generic ransomware policy. A specific decision process that identifies who has authority to make the payment decision, what evidence threshold triggers escalation to the board, and what regulatory reporting obligations apply before, during, and after the decision. The Grafana case has just provided a worked example. The question is whether your framework has been updated to reflect it.

Governance velocity will never match attack velocity in absolute terms. The objective is to close the gap enough that the tempo difference does not become an accountability gap, where boards are making decisions retrospectively on events that had already resolved themselves, badly, because no framework existed.

The Executive Takeaway

This week placed four concrete governance obligations on the table. Verify your NGINX patch status. Document your position on vendor data-destruction assurances. Assess the OPC's MMH inquiry terms of reference against your own platform architecture. Review your extortion-response decision framework against the Grafana template.

None of these require a specialist. Each requires a governance posture that runs at something closer to the tempo that the threat environment now sets.

AI-assisted discovery has compressed the window between vulnerability creation and active exploitation from years to days. That compression is not a temporary condition. It is the new operating baseline. Boards that treat cyber governance as a quarterly briefing cycle will find, repeatedly and expensively, that the threats they govern have resolved themselves before the governance caught up.

Heaven Vector governance, in the operational sense this series has used throughout, is not a philosophical position. It is the posture that says: we know what our patch status is, we understand what our vendor assurances cover and what they do not cover, we have documented decision authority for the scenarios we will eventually face, and we are not waiting for a regulatory inquiry to establish our baseline.

The organisations that have done that work are not alarmed by a week like this one. They are confirming.

What is the most consequential cyber governance decision your board made in response to a specific incident this year, and is that decision documented clearly enough that an OPC inquiry could read it?

The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. They do not represent the views of my employer, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance. I follow the Public Service Commissioner's Code of Conduct for the Public Sector and social media guidance.

Andreas Hamberger is a Wellington-based enterprise architect, technology strategist, and Associate Member of the Institute of Directors New Zealand, with more than 30 years of experience across government, banking, transport, and aviation sectors. He is the founder of Te Pono Limited. The Hamberger Report: Cyber Guide for New Zealand Boards is the definitive board-level cybersecurity governance guide.

I use AI tools, including Sudowrite, Claude, Perplexity AI, DeepSeek AI, ChatGPT, Grok, Copilot, Openart and Gemini, as deliberate production tools, not ghostwriters. This is consistent with my position: AI amplifies human judgement; it does not replace it. The frameworks, arguments, and editorial decisions in this series are original work. AI accelerated the process. The thinking is mine.

[1] F5 Networks. "K000159247: NGINX Vulnerability CVE-2026-42945." F5 Security Advisory, 13 May 2026. https://support.f5.com/csp/article/K000159247

[2] depthfirst / Akamai Security Intelligence Group. "CVE-2026-42945 ASLR Bypass Analysis." Akamai Security Research, 21 May 2026. https://www.akamai.com/blog/security-research/nginx-rift-cve-2026-42945

[3] HeroDevs. "NZ Advisory: CVE-2026-42945 NGINX Rift." HeroDevs Security Advisories, May 2026. https://www.herodevs.com/support/advisories/nginx-rift

[4] Victoria University of Wellington. "Statement on Canvas / Instructure Security Incident." VUW Media Release, May 2026. https://www.wgtn.ac.nz/news/canvas-security-incident

[5] University of Auckland. "Notice Regarding Instructure Canvas Breach." University of Auckland Student Communications, May 2026. https://www.auckland.ac.nz/news/canvas-breach-notice

[6] Office of the Privacy Commissioner. "Terms of Reference: Independent Inquiry into Manage My Health." OPC, May 2026. https://www.privacy.org.nz/news-and-publications/inquiries/manage-my-health-inquiry

[7] Kordia. "2026 NZ Business Cyber Security Report." Kordia, March 2026. https://www.kordia.co.nz/cyber-security-report-2026

[8] NCSC New Zealand. "Cyber Threat Report Q3 2025." National Cyber Security Centre, 2025. https://www.ncsc.govt.nz/reports

[9] Grafana Labs. "Security Incident Disclosure: GitHub Environment." Grafana Labs Public Statement, May 2026. https://grafana.com/blog/2026/05/security-incident-disclosure

[10] DPMC. "Critical Infrastructure Security Consultation: Proposed Regulatory Framework." Department of the Prime Minister and Cabinet, February 2026. https://www.dpmc.govt.nz/publications/critical-infrastructure-security

[11] Layer3 NZ. "NZ Threat Landscape 2026." Layer3 Cybersecurity, 2026. https://www.layer3.co.nz/threat-landscape-2026

[12] Picus Security / SOCRadar. "CVE-2026-42945 Threat Intelligence Brief." May 2026. https://www.picussecurity.com/resource/cve-2026-42945

Andreas H 26/05/2026 Andreas H 26/05/2026

Orbital AI: The Hyperscaler Triple

Three men stood up in the same week and said the same thing. Not in the same room. Not as part of any announced coordination. Separately, in earnings calls, press releases, and acquisition announcements, Jeff Bezos, Eric Schmidt, and Elon Musk each committed to putting data centres in orbit.

That week was 16 to 22 May 2026.

In the same week, Starcloud-1 reported nominal operations from 325 kilometres above Earth. The company confirmed it had trained a large language model in orbit. It confirmed a version of Gemini had run in orbital inference mode. According to Data Center Dynamics, reporting on 14 May 2026, these are the first publicly confirmed instances of both LLM training and LLM inference executed in orbit by a commercial operator.

The Space Mafia book named this moment the "deploy and defend" era: the period when the race is no longer speculative and the governance framework has not yet caught up. Three of the most likely principals of orbital compute announced their orbital ambitions in the same week. The archetype the book described confirmed its product works.

This is not a trend. It is an inflection point.

The Three Statements

Precision matters here. These are confirmed claims, reported by aerospace and AI infrastructure press between 16 and 22 May 2026.

Jeff Bezos, founder of Amazon and Blue Origin, publicly forecast gigawatt-scale orbital data centres within "ten or more years." This is a specific timeline and a specific scale target. Gigawatt-scale infrastructure requires launch costs and orbital construction methods that do not yet exist at commercial scale. The forecast is grounded in existing capability: Amazon Kuiper, Bezos' low-Earth orbit broadband constellation, has deployed 304 satellites across eleven missions and faces a regulatory milestone requiring 1,600 satellites, half of a planned 3,236-satellite constellation, by July 2026. The infrastructure layer is not hypothetical. It is under construction.

Eric Schmidt, former Google CEO and now chair of Relativity Space, confirmed that his acquisition of Relativity, which manufactures rockets using large-scale 3D printing, is explicitly targeted at orbital compute infrastructure. Schmidt's orbital ambition is simultaneously a launch supply-chain play. Building orbital data centres requires getting hardware to orbit affordably. Relativity is the launch strategy.

Elon Musk confirmed that SpaceX "is looking to deploy data centres in space." SpaceX already operates the Starlink constellation, which has surpassed 10,000 active satellites with AI-optimised constellation management. The data-centre announcement extends an existing orbital platform into a new product category.

These are not coordinated statements. Three principals, independently, in the same week, announced orbital compute commitments. The convergence is the story. The question of whether it reflects any coordination is for the reader to answer.

I am calling this the Hyperscaler Triple. Not because the three individuals are the same type of actor, they are not, but because they represent, collectively, three of the four largest compute-platform owners on the planet committing to the same orbital infrastructure direction in the same seven-day window. The Triple is a market signal, not a conspiracy theory.

Starcloud-1: The Operational Confirmation

Starcloud-1 carries an NVIDIA H100 GPU cluster, weighs 60 kilograms, and orbits at 325 kilometres. The launch was November 2025. On 14 May 2026, Data Center Dynamics reported nominal operations confirmed.

The confirmation covers two specific milestones: Starcloud trained a large language model in orbit, and a version of Gemini ran in orbital inference mode. The Space AI Monday standard protocol applies here. The operational fact, that both events occurred, is confirmed at the level of the company's own reporting. Performance claims, including training speed, inference throughput, and latency benchmarks, have not been independently verified. Treat those as manufacturer claims until independent benchmarking exists.

The Space Mafia book named Starcloud as the primary archetype of the book's argument: "Starcloud ignites orbital H100 GPUs. SpaceX expands Starlink into a skyborne supercomputer. Axiom Space plots data centre nodes above the Kármán Line." The book was written before nominal operations were confirmed. The 14 May 2026 confirmation is direct alignment between the book's analytical forecast and the operational record.

Starcloud-2 is next. Anchor tenant: Crusoe Cloud, confirmed in a press release from October 2025. Stated power: approximately 100 times that of Starcloud-1, per Starcloud's own communications. This is a manufacturer claim about a satellite not yet launched; treat it as indicative, not verified. Launch window: October 2026. GPU capacity available to external customers: early 2027. The timeline from "confirmed it works" to "available for your workloads" is approximately eight months.

Taiwan's Far EasTone has confirmed Amazon Kuiper as its commercial orbital communications partner for 2027. The Asian market is already building its orbital dependency architecture. The Hyperscaler Triple is not a Western story. It is a global one.

What the Digital Feudalism Framing Actually Means

The Space Mafia book described the outcome of unchecked orbital compute concentration with a term borrowed from political economy: digital feudalism. The passage has become current.

"By 2025, the top ten global universities commanded less aggregate compute in the cloud than a single Starcloud cluster, and even that is often rationed under restrictive access agreements. 'Democratising AI,' a favourite chorus at tech summits, becomes a cruel joke when the cost of entry is a launch slot or a buy-in to proprietary inference. The gap widens every quarter. The result will be digital feudalism: private princes controlling the only roads to orbital power, with states and citizens left to bargain for vassal access."

The three principals who made orbital commitments in the week of 16 to 22 May 2026 are among the most likely candidates for those private prince roles. None announced in coordination with any other. Each is acting on the same commercial logic: orbital compute offers jurisdictional arbitrage, specific latency advantages for non-real-time AI workloads, and near-zero labour costs for operations once the infrastructure is deployed.

The governance framework for this concentration does not exist.

The Outer Space Treaty of 1967 was written for state actors launching satellites. It does not address private commercial orbital data centres. The Artemis Accords, now with more than 40 signatories as of the 2025 expansion, provide non-binding political commitments on debris management, deconfliction, and scientific data sharing. They do not address orbital compute sovereignty, data jurisdiction, or AI governance. The EU data protection regime does not reach orbital infrastructure. According to the Space Mafia book, Starcloud's position on GDPR inquiries is explicit: "We do not process in the EEA; complaints belong at your nearest launch pad."

When Starcloud-2 launches in October 2026 with approximately 100 times the power of Starcloud-1, per Starcloud's own communications, commercial customers can place AI workloads in orbit from early 2027. No jurisdiction will reach them.

The Inequality and Consolidation Fault Line

The Space Mafia book identified five fault lines where terrestrial governance collapses at orbital altitude: data sovereignty erosion, IP and copyright collapse, environmental accountability vacuum, inequality and consolidation, and security and weaponisation.

The others have received significant series attention. Data sovereignty anchored Episodes 2 and 7. Security and the ground-segment attack surface anchored Episode 8. The Hyperscaler Triple activates the most underexplored fault line: inequality and consolidation. It stops being theoretical this week.

When three of the largest compute-platform owners on the planet all commit to orbital infrastructure in the same seven-day window, the consolidation fault line becomes structural. The orbital compute market is being claimed before the governance commons exists to manage it. The Antarctic Treaty model, which the book identifies as the closest precedent for a workable governance commons, has not been proposed for orbital compute. The Hyperscaler Triple makes that absence materially more urgent.

The physics of orbital compute reinforce the consolidation tendency. Radiation hardening at altitude is not a trivial problem. The Space Mafia book's engineering chapter describes the architecture: "Starcloud implemented triple-modular redundancy in its H100 GPU array; every critical logic block is triplicated, and the output is voted on each clock cycle." Triple-modular redundancy costs three times the power and three times the hardware mass. Single-event upsets, where cosmic radiation flips transistor states, are a real constraint on orbital compute density. All radiation mitigation approaches increase unit cost above terrestrial equivalents. The organisations that can absorb those cost differentials are the organisations that already dominate terrestrial compute. The consolidation dynamic at altitude mirrors what happened on the ground.

A brief note from the pirate radio parallel the book established: the 1960s radio ships operated from international waters until regulation eventually caught up. The Hyperscaler Triple suggests regulation will need to catch up faster this time.

The Adversarial Kardashev Dimension

The Hyperscaler Triple is a commercial story. It is also the precondition for a geopolitical one.

The Adversarial Kardashev variant, which this series introduced in Episode 8, asks a specific question: what happens when a hostile state actor applies the same capital-concentration playbook in orbit? China's Three-Body constellation programme, described in the Space Mafia book, is the live state-actor counterweight. The bifurcation of orbital compute infrastructure into commercially aligned and state-directed constellations follows the same logic as the terrestrial internet bifurcation, at a layer of the stack that no current governance framework addresses.

The point is not that the Hyperscaler Triple is itself a threat. The point is that the concentration it represents creates the structural conditions for the adversarial scenario. When Western orbital compute infrastructure is concentrated in three or four corporate entities, the comparative concentration in state-directed entities becomes a strategic variable. Enterprises, governments, and communities whose AI services depend on orbital infrastructure will have their choices shaped by that bifurcation, whether or not they are aware of it.

One cross-series governance note: the Cyber Sunday Cyber News cycle has observed that AI-discovered vulnerabilities can be exploited within hours on terrestrial infrastructure. Orbital infrastructure running equivalent service layers has no emergency patch pipeline at the same cadence. A satellite at 325 kilometres cannot be physically accessed on the same timeline as a rack in a terrestrial data centre. The governance gap is not only jurisdictional. It is also operational.

What This Means for NZ Organisations

New Zealand is not a passive observer of the Hyperscaler Triple. It is downstream of all three principals.

NZ's international internet traffic runs almost entirely through undersea cable infrastructure. The primary cables, Southern Cross NEXT and related infrastructure, carry the latency-sensitive workloads that make orbital routing impractical for general traffic. The round-trip minimum at low-Earth orbit is approximately 600 milliseconds. Real-time applications cannot route via orbit efficiently.

But an LLM inference job that does not require real-time response is a different workload category. Compute-intensive AI tasks without hard latency requirements can migrate to orbital inference without a user-experience penalty. By early 2027, Starcloud-2 plans to offer that capacity to external customers. The question is not whether this becomes technically available. It becomes technically available in approximately eight months. The question is whether your data governance framework has a position on it before that happens.

NZ government agencies are significant AWS consumers. Amazon Kuiper's July 2026 regulatory milestone means Bezos' orbital ambition has a specific near-term delivery date. Terrestrial vendor concentration is already a sovereignty concern for NZ AI governance planning. The same concentration, extended to orbital infrastructure, represents the same risk at a layer of the stack that no current NZ legislation reaches.

On 22 May 2026, Rocket Lab launched its ninth Electron for Synspective, carrying a SAR satellite from Launch Complex 1 at Mahia. Mahia is the only orbital launch site south of the equator in the Asia-Pacific. NZ launch activity continues. NZ's position in the orbital economy is active, not theoretical.

The GBSI Act, NZ's primary legislative instrument for commercial space activities, carries an authorisation compliance deadline of 29 July 2026. The Act's requirements apply to NZ launch operators and NZ-licensed spacecraft operators. The Act does not extend to foreign orbital data centres operating overhead. This is not a design flaw specific to NZ. It is the structural gap that exists between what any national space legislation can reach, under the state-actor framework of the Outer Space Treaty, and what commercial operators deploying hardware in orbit can do. The gap is a feature of the international legal order, not a domestic regulatory failure.

GNSS dependency is the third exposure dimension for NZ organisations. Transport logistics, agricultural precision systems, and power grid frequency synchronisation all depend on GPS and GNSS signals from foreign-operated constellations. Orbital governance directly implicates the entities that will operate the next generation of those constellations.

The practitioner question for this article is direct. When a vendor proposes running your AI workloads in Starcloud-2's orbital infrastructure from early 2027, under no applicable data-protection jurisdiction you can enforce, does your organisation's data governance framework have a position? Most do not. The organisations that develop that position in the next eight months will be ahead of the ones that develop it after the first incident.

The Governance Window Is Not Closing in the Future. It Is Closing Now.

Starcloud-2's October 2026 launch is the next concrete event. It will either confirm or complicate the trajectory the Hyperscaler Triple has set. The launch window is public. The anchor tenant is confirmed. The external customer availability timeline is stated.

Watch the Kuiper deployment milestone. Amazon's July 2026 regulatory deadline is a public commitment with consequences. Whether Amazon meets it reveals the pace at which the orbital infrastructure layer is materialising.

Watch the Relativity Space communications. Schmidt's acquisition is targeted at orbital compute. Relativity's announcements about orbital compute timelines will indicate how quickly Schmidt believes the gigawatt forecast can be shortened.

Watch for governance framework announcements. The Artemis Accords are the closest thing to an orbital governance commons currently in existence. None of the Hyperscaler Triple principals has committed their orbital infrastructure to any governance commons framework. The absence of that commitment is the signal.

The EU AI Act Omnibus reversal deferred Annex III high-risk obligations to December 2027. Orbital AI systems operate outside any EU jurisdiction as a legal matter, yet are commercially accessible to EU users. The regulatory arbitrage the Space Mafia book named has become operationally available.

The book argued that the Antarctic Treaty model offers the closest precedent: a commons framework with mutual inspection rights, binding transparency, and enforcement mechanisms. That framework does not yet exist for orbital compute. The Hyperscaler Triple makes its absence more urgent, because the principals building the infrastructure are now publicly named and operating on announced timelines.

The 2026 to 2030 period will set the defaults for a generation. Three of the principals just announced what those defaults will look like if no governance commons is established.

When your organisation's AI workloads run on infrastructure orbiting 325 kilometres above any legal jurisdiction you can enforce, who is your data's guardian?

Andreas Hamberger is a Wellington-based enterprise architect and technology strategist with more than 30 years of experience in government, banking, transport, and aviation across New Zealand. He is the founder of Te Pono Limited, an Associate Member of the Institute of Directors NZ, and holds TOGAF and IAPP credentials. He is the author of The Hamberger Report series of books on AI governance, cybersecurity, and enterprise architecture. Space Mafia examines the sovereignty implications of orbital compute infrastructure.

[1] Hamberger, A. Space Mafia: The Battle Between an Accountable "Heaven" and an Unfettered "Skynet" in Orbital AI. The Hamberger Report, 2025/2026.

[2] Data Center Dynamics. "Starcloud-1 achieves nominal operations; LLM trained in orbit." 14 May 2026. [URL to be added at publication]

[3] Crusoe Cloud / Starcloud. Press release on Starcloud-2 anchor tenancy and specifications. 22 October 2025. [URL to be added at publication]

[4] Multiple aerospace and AI infrastructure trade press sources documenting Bezos, Schmidt, and Musk orbital compute statements. 16 to 22 May 2026.

[5] Amazon. FCC filings and Kuiper deployment milestone communications. 2026.

[6] Far EasTone Telecommunications. Kuiper commercial partnership announcement. 2026.

[7] United Nations. Treaty on Principles Governing the Activities of States in the Exploration and Use of Outer Space, Including the Moon and Other Celestial Bodies. 1967.

[8] NASA. Artemis Accords: Principles for Cooperation in the Civil Exploration and Use of the Moon, Mars, Comets, and Asteroids for Peaceful Purposes. 2020, expanded 2025.

[9] New Zealand Parliament. Space (Mahina Maru) Activities Act. 2017 (as amended, Government Boost Satellites and Infrastructure Act provisions).

[10] Rocket Lab. Mission announcement: "Viva La Strix," ninth Electron for Synspective, Launch Complex 1 Mahia. 22 May 2026.

Andreas H 18/05/2026 Andreas H 18/05/2026

When the Launch Provider Becomes the Compute Provider: Google, SpaceX, and the Orbital Concentration Question

The week of 5 to 12 May 2026 will be studied in future enterprise architecture curricula. Not because something unprecedented was announced, but because several things that were already happening crossed the threshold from pattern to settled fact in a single calendar week.

On 12 May, the Wall Street Journal reported that Google is in advanced discussions with SpaceX to launch the Project Suncatcher orbital data centre satellites. Earlier that week, Anthropic confirmed it had agreed to use the full computing capacity of SpaceX's Colossus 1 facility in Memphis: more than 300 megawatts and over 220,000 NVIDIA GPUs, with the contract including potential collaboration on multi-gigawatt orbital data centres in future. And xAI, which merged with SpaceX in February 2026 at a combined valuation of reportedly US$1.25 trillion, was reorganised during the same week into a SpaceXAI division, per Elon Musk's announcement.

Three of the four major frontier AI labs operating at scale are now structurally bound to SpaceX: Anthropic as a compute customer with an orbital extension option, Google as a launch customer and existing minority shareholder, xAI as an internal business unit. OpenAI is the fourth major frontier lab, and it has not, to date, disclosed a comparable structural commitment to SpaceX.

This is the architectural starting condition for orbital compute in 2026. The question is not whether the concentration happened. It did, in one week, confirmed by multiple sources across five separate reporting outlets. The question is what it means for how organisations design, procure, and govern orbital workloads from this point forward.

The Three Clocks Reading

The Three Clocks framework has tracked the urgency dynamics of this series since Episode 1. It remains the sharpest lens for what happened last week.

The Commercial Clock is the primary driver. SpaceX is preparing for what is expected to be among the largest initial public offerings in history, at a reported valuation of approximately US$1.75 trillion. That figure is reported rather than audited and should be read as directional, not precise. But the directional signal is clear: the orbital data centre commitments being locked in this week are not incidental to the IPO preparation. They are the IPO story. A frontier AI lab signing a long-term compute agreement converts anticipated revenue into contracted revenue. Three such labs convert the revenue story into a category claim. That changes the risk profile for institutional investors categorically.

The Strategic Clock is running in parallel. Concentrating three frontier labs within a single company's infrastructure gives that company structural leverage that no competitor can quickly replicate. A new orbital data centre operator needs not only capital for manufacturing and launch, but years of customer relationship building. The frontier labs have now signalled where they are building. New entrants must compete for what remains.

The Regulatory Clock is the slowest of the three, and the gap between it and the other two widens each week. Regulators are still developing frameworks for terrestrial AI. They are not yet building equivalent frameworks for orbital compute concentration. SpaceX's filing with the FCC for authorisation to deploy up to one million satellites for orbital data centre purposes, made in February 2026, sits in regulatory territory with no orbital antitrust equivalent and no cross-jurisdictional data sovereignty framework. The governance vacuum documented in Space Mafia is not a future condition. It is the operating environment in which these deals are being struck.

The Conflict Clock, which entered the framework in Episode 3, is not the primary driver this week. The concentration described here is commercial, not adversarial. That does not make it less significant for sovereignty analysis. It makes it different.

The Vendor-Decides Pattern

There is a structural concept that the week's events bring into focus, one that I want to name explicitly because it will recur across this series and its adjacent ones.

I call it the Vendor-Decides Pattern.

When a vendor controls both the launch layer and the compute layer of a technology stack, decisions that users might otherwise make for themselves become vendor decisions by default. Which jurisdiction processes your data. Which legal framework governs a breach investigation. Whether meaningful redundancy is architecturally possible if that vendor experiences a disruption. These decisions are made at design time, by the entity that owns the infrastructure. Not through malice, but because the architecture does not permit another outcome.

Google's Project Suncatcher illustrates the pattern at orbital altitude. The target architecture is 81 satellites operating in a one-kilometre radius compute cluster, equipped with Google's custom Tensor Processing Units, manufactured by Planet Labs, with SpaceX as the reported launch provider. When those satellites are in orbit, the data processed on them will be subject to jurisdictional conditions established at design time: the registration of the launch vehicle, the legal domicile of the operating entity, and the contract terms negotiated before a single workload runs. Those conditions are being determined this week. They cannot be renegotiated once the infrastructure is operational.

Anthropic's Colossus 1 agreement extends the same pattern into terrestrial infrastructure with an orbital extension clause built in. The 300-plus megawatts of compute in Memphis is a SpaceX-operated facility. The contract's potential collaboration on multi-gigawatt orbital data centres means the architectural relationship is designed for continuity from terrestrial to orbital as cost curves shift. Same vendor, same operational terms, at altitude when the economics permit.

The xAI absorption into SpaceXAI is the most complete expression of the Vendor-Decides Pattern. xAI is no longer a customer making procurement decisions. It is an internal unit. The compute, launch, connectivity, and AI product decisions are made inside a single corporate structure. There is no procurement relationship to govern, because there is no separation to govern across.

Three lab relationships with SpaceX. Three different structural forms: customer, customer-shareholder, internal unit. One pattern.

The Startup Layer Confirms It

If you are inclined to read the frontier lab concentration as temporary, driven by IPO timing and specific relationships, the Cowboy Space Series B is the counter-argument.

Cowboy Space, formerly Aetherflux, reportedly raised US$275 million in a Series B at a valuation of approximately US$2 billion, according to Data Centre Dynamics on 13 May 2026. The company's model is structural, not opportunistic: take a rocket upper stage, convert it into a one-megawatt orbital data centre at deployment, target a demonstration satellite for Q4 2026. It was founded by a co-founder of Robinhood.

At the startup layer, the launch-plus-compute integration is the designed architecture. The venture capital thesis for orbital compute is explicitly built on controlling both layers. The Vendor-Decides Pattern is not a consequence of one company's particular strategy. It is the structure that investors are funding across the category.

The Economics Have Not Converged. The Decisions Have.

There is an important distinction to draw clearly, because conflating these two things would misread the risk.

Orbital compute has not reached cost parity with terrestrial alternatives. Today's satellite construction and launch costs make orbital data centres significantly more expensive per workload than terrestrial facilities. The Anthropic, Google, and Cowboy Space commitments are bets on future cost reduction, particularly on reusable heavy-lift launch, not on current price parity.

The architecture decisions, however, are being made now, and at a scale that forecloses options. A contracted compute relationship does not dissolve because a competitor improves its pricing. The organisations making these commitments are locking in operational dependencies for years. Orbital infrastructure does not decommission lightly.

There is a workload suitability constraint worth understanding for your own architectural assessment. Orbital compute is currently suited to asynchronous, batch-processing workloads. The Earth-to-orbit latency profile makes real-time inference, the kind that drives customer-facing AI services, better placed terrestrially for now. Thermal management across sun and eclipse temperature ranges and the radiation hardening requirements for long-duration operation also constrain hardware choices in ways terrestrial facilities do not face.

This matters for how you read the concentration risk. The workloads for which orbital concentration becomes relevant are batch training runs, bulk inference tasks, and large-scale data processing operations: the workloads that move in response to cost and capacity signals, not latency signals. If your highest-value data processing sits in that category, the orbital supply chain consolidation is directly relevant to your vendor risk register. If it does not, the relevance is indirect but still present, because the infrastructure decisions being made this week will shape the cost structures and contract terms your organisation will encounter when it does engage with orbital compute.

According to IEA projections, global data centre electricity consumption is expected to exceed 1,000 terawatt-hours by the end of 2026, roughly equivalent to Japan's annual electricity consumption. Connection waiting times for new gigawatt-scale AI facilities in established markets reportedly reach up to seven years. The frontier labs are not choosing orbital compute because it is currently cheaper. They are choosing it because terrestrial capacity at the scale they need is increasingly unavailable. The orbital layer is being built under pressure from a terrestrial constraint that is binding now, not at some future planning horizon.

In Episode 9, the GAO's finding that AI data centres could account for approximately 12 percent of US electricity demand by 2028 set the context for why the pivot to orbit has accelerated. Anthropic's 300-megawatt commitment to a single facility, signed in the same week as Google's reported launch discussions, is the commercial confirmation of that finding landing in contract form.

What This Means for NZ Procurement

New Zealand organisations are not yet running orbital workloads in any meaningful volume. That does not mean the decisions being made this week are irrelevant to NZ enterprise architecture.

The procurement decisions being made by Anthropic, Google, and the SpaceXAI division will shape the cost structures, contract terms, and dependency chains that NZ organisations encounter when they do engage with orbital compute. And the structural concentration being established now is easier to describe than to exit.

Three practical observations for enterprise and architecture teams.

Jurisdiction follows architecture, not contract intent. NZISM v3.9 controls on identity and cryptographic protection apply to NZ government data wherever it is processed, including in orbit. An architecture that routes sensitive NZ workloads through orbital infrastructure without explicit jurisdiction analysis is not NZISM v3.9 compliant regardless of the vendor's contractual assurances. The upcoming 29 July 2026 authorisation deadline under the GBSI Act requires NZ entities engaging in space activities to hold appropriate authorisation. The definition of what constitutes a space activity has implications for organisations that process data on satellite infrastructure. A legal assessment specific to your organisation's orbital footprint, if any, is the appropriate starting point, not a vendor's standard terms.

Orbital concentration mirrors terrestrial concentration at a different layer. NZ government and commercial workloads already run heavily on a small number of global cloud providers. Three frontier AI labs structurally tied to one launch and compute provider is, architecturally, the same question NZ procurement already manages on the ground, with one material difference: orbital concentration operates without the geographic regulatory equivalents and portability standards that apply to terrestrial cloud. The Five Fault Lines framework from Space Mafia identifies data sovereignty erosion as the first fault line that intensifies at altitude. The week's events confirm the fault line is no longer theoretical.

Rocket Lab provides NZ-adjacent launch capability, not equivalent scale. Rocket Lab operates commercial launch from the Mahia Peninsula, holds a growing orbital servicing portfolio through its Gauss propulsion capability, and is building genuine orbital infrastructure relevance for allied-nation partners, as Episode 7 documented. The orbital compute commitments made this week are at Starship-class heavy-lift scale. Rocket Lab and SpaceX are not substitutes for that workload category. What Rocket Lab does provide is a structural option for smaller NZ orbital deployments outside the SpaceX dependency, consistent with the Collaborative Vertical Integration model first described in Episode 7. That is a margin hedge, not an equivalent alternative. It matters for NZ procurement strategy precisely because it is the most accessible structural differentiation available to NZ organisations.

The Architecture Question That Remains Open

The Five Country Council issued joint guidance on 1 May 2026 addressing agentic AI risks. That guidance covers the terrestrial AI governance layer. A parallel multilateral framework for orbital compute concentration does not yet exist.

That is a factual observation, not a prescription. The governance timeline for orbital infrastructure runs on a different cadence from the Commercial and Strategic Clocks driving this week's announcements. Understanding that gap is part of the architectural analysis any organisation considering orbital workloads needs to conduct.

In Space Mafia, the Heaven Vector describes a future of transparent international frameworks: orbital compute governed by clear jurisdictional rules, portability guarantees between providers, and concentration oversight that gives users meaningful options. The Skynet Vector describes the alternative: orbital infrastructure concentrated in entities operating beyond the reach of any single regulatory framework, with governance determined by the architecture decisions of whoever controls the launch stack.

The week of 5 to 12 May 2026 moved the orbital compute story firmly toward the Skynet Vector as the current observable reality. The Heaven Vector outcome is not foreclosed. But it requires governance frameworks that currently do not exist at orbital altitude, and it requires them before the infrastructure being committed to this week becomes the settled architecture.

Space Mafia argued that the 2026 to 2030 window would set the governance defaults for a generation. We are inside that window now. The architecture decisions being made in boardrooms this week, by organisations many times larger than any New Zealand entity, will define the dependency conditions under which NZ organisations eventually engage with orbital compute.

The question for your organisation is not whether you have an orbital compute strategy today. Most do not, and that is a reasonable position. The question is whether the teams responsible for your enterprise architecture and your vendor governance have begun to treat the orbital layer as an arriving dependency rather than a distant scenario.

This week confirmed it is arriving.

What is your current thinking on when orbital compute appears on your vendor risk register?

Andreas Hamberger is a Wellington-based enterprise architect, security practitioner, and technology strategist with over 30 years of experience across New Zealand's public and private sectors. He holds TOGAF, IAPP, and AMInstD credentials and is the founder of Te Pono Limited. He publishes The Hamberger Report, a multi-series LinkedIn publication, as a New Zealand leader in architecture and security. Space Mafia examines the sovereignty implications of orbital compute infrastructure.

[1] Wall Street Journal. "Google in Advanced Talks with SpaceX to Launch Project Suncatcher Satellites." 12 May 2026. [URL TBC at publication]

[2] TechCrunch. "Anthropic Signs Agreement to Use SpaceX Colossus 1 Facility, 300MW, 220,000 GPUs." Week of 5 May 2026. [URL TBC]

[3] Reuters / GVWire. "Anthropic-SpaceX Colossus 1 Agreement Details." Week of 5 May 2026. [URL TBC]

[4] Yahoo Finance. "Anthropic SpaceX Deal: Compute Commitment and Orbital Extension Option." Week of 5 May 2026. [URL TBC]

[5] TechCrunch. "SpaceX Files FCC Application for Up to One Million Orbital Data Centre Satellites." February 2026. [URL TBC]

[6] Tech Startups. "SpaceX Preparing IPO at Reported Approximately US$1.75 Trillion Valuation." May 2026. [URL TBC]

[7] Yahoo Finance. "xAI-SpaceX Merger: Combined Entity Valued at Reportedly US$1.25 Trillion." February 2026. [URL TBC]

[8] Musk, E. Announcement of SpaceXAI division reorganisation. Week of 5 May 2026. [Platform X / URL TBC]

[9] SpaceX / regulatory filings. Google 6.1 Percent Stake: US$900 Million Investment, 2015. [URL TBC]

[10] WCCFTech / The Assembly. "NVIDIA Orbital AI Partner Roster: Starcloud, Planet Labs, Kepler Communications, Firefly Aerospace, Sophia Space." 11 May 2026. [URL TBC]

[11] International Energy Agency. Data Centres and Data Transmission Networks. May 2026 update. https://www.iea.org/reports/data-centres-and-data-transmission-networks

[12] Data Centre Dynamics. "Cowboy Space Raises US$275 Million Series B at Reported US$2 Billion Valuation." 13 May 2026. [URL TBC]

[13] Bloomberg / Reuters. "Google Project Suncatcher: 81 Satellites, One-Kilometre Cluster, Custom TPUs, Planet Labs Manufacturing." May 2026. [URL TBC]

[14] National Cyber Security Centre NZ. "Five Country Cybersecurity Agencies Issue Joint Guidance on Agentic AI." 1 May 2026. [URL TBC]

[15] Hamberger, A. Space Mafia: The Battle Between an Accountable "Heaven" and an Unfettered "Skynet" in Orbital AI. Te Pono Limited, 2026.

Andreas H 17/05/2026 Andreas H 17/05/2026

Cybersecurity Governance: Who Decides to Pay the Ransom When Your Vendor Is Breached?

On 11 May 2026, Instructure announced it had settled with ShinyHunters, the extortion group responsible for the Canvas learning management system breach. The company stated it had received digital confirmation of data destruction and that the agreement covered "all impacted Instructure customers." The amount paid was not disclosed. The following day, a US House Homeland Security Committee investigation letter was reportedly sent to Instructure CEO Steve Daly, according to reporting by arnav.au.

Here is what those two events meant for 8,809 institutions worldwide, including three New Zealand universities: none of them were at the table when the ransom decision was made.

That is the governance question this article addresses. Not whether paying was right or wrong. Not whether ShinyHunters' confirmation of data destruction means anything. The question is structural: when your institution's learning management system is operated by a third-party vendor, and that vendor settles an extortion demand that covers your data, your students, and your legal obligations, who decided? This Sunday the answer was Instructure. Last year it was reportedly PowerSchool. Next year it will be someone else.

Boards need to understand why their current crisis governance frameworks do not cover this scenario, and what must change before the next vendor-side breach arrives.

The Governance Question

Two years of cyber crisis governance development in New Zealand and internationally has produced something genuinely valuable. Boards have invested in protocols. Hour-Zero frameworks define who speaks, who decides, and who carries accountability during the first 24 hours of a breach. The Resilience Manifesto commitments I outlined in Part 10 (Commitment Two: Architectural Debt assessment; Commitment Five: Audit of Intent) ask boards to periodically examine their third-party dependencies and verify that vendor intent on data handling translates into verifiable governance behaviour.

What neither framework anticipated is the scenario that landed on 11 May 2026: a vendor making a ransom decision on behalf of its entire customer base, without consultation, before the customer's board protocols could be activated.

The Once-Only Resilience framework, which I have developed through this series since Part 4, holds that some resilience commitments cannot be retrofitted after an incident. You cannot install a sprinkler system while the building is on fire. The same logic applies to decision rights. The decision whether to engage with an extortion demand is, by definition, a once-only decision. You make it once. You cannot un-make it. And when Instructure settled with ShinyHunters, every one of its 8,809 customer institutions had that decision made for them, permanently, without input.

I call this the Once-Only Decision principle. It is an extension of the Once-Only Resilience framework, and it surfaces a precondition the Hour-Zero Protocol did not make explicit: the question of whose protocol applies when the breach is at the vendor layer, not the institutional layer.

This is not a criticism of Instructure's decision. The structural dilemma vendors face is real: prolonged downtime generates losses that are genuinely unsustainable for a business serving 8,809 customers simultaneously. That pressure pulls decision-makers toward payment. Christy Wyatt of Absolute Security captured the trade-off accurately in public commentary on this incident: the calculus of vendor payment differs from the calculus of institutional payment, because the vendor is absorbing service-delivery risk across its entire customer base at once.

The structural problem is not that Instructure decided. The structural problem is that its customers had no contractual mechanism to participate in that decision. The trade-off was resolved at the vendor layer. The customer layer was informed.

There is a precedent that should concern boards further. In 2025, PowerSchool reportedly paid a ransom under analogous circumstances, after which extortion attempts from other actors who had obtained separate copies of the same data still occurred. A single threat actor's written confirmation of data destruction does not prevent secondary actors from leveraging copies of that data obtained before the agreement. Halcyon's analysis of the ShinyHunters "pay or leak" model specifically notes that payment carries no guarantee of permanent data suppression. The vendor has settled on your behalf. That settlement does not extinguish the underlying data exposure risk; it settles one actor's claim while leaving the data itself potentially accessible to others.

This is the consequence qualification that boards must apply to vendor settlement announcements: "digital confirmation of data destruction" means one actor has provided a written claim. It does not mean independent verification. It does not mean other copies do not exist. And it does not mean your institution's legal obligations have been discharged. The Audit of Intent principle requires that stated intent on data handling be treated as the beginning of verification, not the end of it.

The board takeaway is not that the vendor was wrong. It is that the contractual layer between boards and their SaaS vendors does not currently define who holds the decision right when a vendor faces extortion that covers customer data. That is a governance architecture gap, and it is one that no amount of internal crisis protocol can close after the fact.

The Architecture Underneath

The Canvas breach is also architecturally instructive in a way that extends beyond the ransom question.

Per reporting from The Hacker News and synthesised security analysis, the initial attack on 29 April 2026 exploited a cross-site scripting vulnerability in Canvas's Free-For-Teacher tier, a lower-permissioned service offering. What makes the 7 May second breach significant is that it used the same exploit path. Remediation had been incomplete. The second wave was not a new attack. It was a failed patch applied to the same vulnerability, allowing the same attacker to re-enter via the same door.

From an Architectural Debt perspective, this is the tier-boundary problem made operational. Commitment Two of the Resilience Manifesto asks boards to assess whether third-party dependencies have been re-evaluated against their organisation's risk appetite. The specific question for SaaS architecture is whether a compromise of a lower-permissioned tier can cascade to administrative access in higher tiers. In the Canvas case, the tier boundary was permeable. The Free-For-Teacher service carried sufficient privilege to enable an attack path that eventually reached institutional data.

Most board-level supply-chain governance frameworks ask "which vendors do we use?" and "what data do they hold?" The Canvas incident surfaces a third question: "what is our vendor's tier architecture, and what is the maximum privilege level accessible via a compromise of their lowest-permissioned service?" This question does not appear in most vendor risk assessments I have reviewed. It needs to.

The second architectural observation concerns remediation verification. When Instructure reported that the vulnerability had been patched after the first breach, that report was false: the 7 May second breach demonstrated the patch was incomplete. This is Commitment Five of the Resilience Manifesto, the Audit of Intent, applied at the remediation layer: a vendor's stated intent on security remediation is not equivalent to verified remediation behaviour.

The board governance implication is straightforward. Vendor-reported remediation completeness cannot be treated as independently verified unless your organisation has a contractual mechanism to require independent evidence of closure. In most current vendor contracts, no such mechanism exists. The vendor patches; the vendor reports; the customer accepts. The Canvas incident shows what happens when that acceptance is misplaced.

The NZ Position

Three New Zealand universities were confirmed as affected by the Canvas breach: the University of Auckland, Auckland University of Technology, and Victoria University of Wellington, per NZ Herald reporting on 6 May 2026 and subsequent spokesperson statements. The University of Auckland took Canvas offline on 8 May, postponed digital assessments, and redirected students to alternative platforms including Talis, Panopto, and Inspera. These are not abstract data points. These are institutions with active legal obligations that the Instructure settlement does not discharge.

Under the Privacy Act 2020, affected New Zealand agencies retain independent breach notification obligations regardless of what a vendor has agreed with a threat actor. The Instructure settlement covers Instructure's exposure to the threat actors. It does not cover the Crown entity's obligations to the Privacy Commissioner. If the breach involved personal information held about students or staff, each affected institution must assess its notification obligations independently.

IPP 3A, which came into force on 1 May 2026, adds indirect-collection notification requirements that may apply depending on how data flows between Instructure and the affected institutions. Where an institution collected personal information through Canvas, and that information includes data about third parties (students, staff, family members), the IPP 3A indirect-collection obligations may require notification to those individuals regardless of Instructure's agreement. The legal position is that the vendor's settlement is the vendor's settlement: institutions carry their statutory obligations regardless of what a third party negotiated on their behalf.

The notification obligations under the Privacy Act 2020 are assessed by the institution, not the vendor. Affected institutions should make that assessment independently and not rely on Instructure's communication to their own staff and students as satisfying the statute. The institutional obligation to notify is separate from any communication Instructure chooses to make. This is the statutory independence that follows from the Vendor-Decides structural reality: the vendor decides about the extortion; the institution decides about compliance.

NCSC NZ's standing advice is that individuals approached for payment in relation to the breach should not engage. That advice is consistent with Five Country Council joint guidance on extortion response. The Instructure agreement removed the institutional decision point before the advice could be operationalised at the institutional level. The advice itself remains sound: the structural point is that the decision window at the institutional layer was closed by the vendor before it opened.

The three affected universities are Crown entities with governance frameworks that include independent obligations under the Privacy Act 2020. Those obligations persist. The Instructure settlement does not satisfy them.

What This Changes for Boards

Every board that uses a SaaS provider for any system holding personal information should ask one question before its next governance meeting: does our vendor contract define what decision rights our organisation retains if the vendor itself is breached and faces an extortion demand?

In most cases today, the answer is no. Most vendor contracts address the vendor's obligations to notify the customer, to restore service, and to compensate for losses. They do not address who holds the decision right on extortion engagement. That omission has become demonstrably consequential. Contractual definition of crisis decision authority must exist before the breach, not be negotiated during it. You cannot retrofit decision rights into a vendor relationship once the vendor has already decided.

Four questions boards should put to their SaaS vendors:

First: if your organisation faces an extortion demand covering our data, what is your decision protocol, and does it include a defined consultation mechanism with us before any settlement is reached?

Second: what is the tier architecture of your service, and what is the maximum privilege level accessible via a compromise of your lowest-permissioned tier? Can a Free-For-Teacher equivalent reach our institutional data?

Third: how is remediation completeness verified after a patch is applied? What independent evidence of closure is provided to customers, and under what timeline?

Fourth: does a settlement your organisation reaches with a threat actor discharge our independent obligations under the Privacy Act 2020 and other applicable data protection legislation? (The answer is no, but the vendor should confirm this understanding explicitly in writing.)

None of these questions is hypothetical. All four are grounded in confirmed events from the week of 11 to 17 May 2026.

A fifth question is worth adding, though it sits at the governance level rather than the contract level: does your board have a protocol for the scenario where a vendor settles an extortion demand before your Hour-Zero Protocol can activate? The Canvas incident is not a breach of your organisation's perimeter. It is a breach of your vendor's perimeter, resolved by your vendor, with consequences that land on your institution. Your existing crisis protocol assumes you are the principal actor. This week demonstrated you may not be.

The practical implication is a two-layer governance requirement. Layer one is internal: review your Hour-Zero Protocol to include a vendor-side breach scenario where the vendor acts before your institution is consulted. Layer two is contractual: before renewing or signing any SaaS agreement for systems holding personal information, require explicit contractual language on decision rights in the event of extortion. If your vendor will not agree to a consultation requirement before any extortion settlement, that is itself governance information.

This is not about assigning blame to Instructure. The vendor faced an impossible situation: 8,809 simultaneous customers, a threat actor with their data, and a business that could not afford prolonged downtime across its entire customer base. The structural problem is that no contractual mechanism existed to give those 8,809 institutions any role in the decision. That gap is the governance finding. Closing it is the board's responsibility.

The Once-Only Decision principle requires that contractual definition of crisis decision authority must exist before the breach. That is the precise extension of the Once-Only Resilience framework the Canvas incident surfaces. 8,809 institutions did not have this layer. When the decision arrived, it was already made.

Two forward signals for boards tracking this space:

The intersection between vendor-ransom-decision governance and cyber insurance underwriting is significant and developing. If insurers begin pricing vendor-side decision rights into institutional cyber insurance premiums, the contractual layer this article calls for will become economically inevitable rather than merely governance-sound. I will be examining this intersection in the EA Thursday series, where the insurance-driven architecture mandate thesis is developing a directly relevant argument.

And this pattern is not confined to cybersecurity. This week, in parallel across the AI verification domain, vendor capability claims are being subjected to independent assessment in ways that parallel the vendor-remediation-verification question the Canvas breach surfaces. The principle that a vendor's assertion about its own systems is not the same as an independently verified fact is structural, not incident-specific. I will be tracking this cross-domain pattern in the Gen AI Tuesday series.

What Has Changed

Board crisis governance protocols are written on the assumption that your institution will be the decision-maker when a breach affects your data. That assumption now needs a second clause: "unless the breach is at the vendor layer, in which case the vendor may decide before you are consulted."

Instructure's settlement this week did not change the legal obligations of the 8,809 institutions it covers. It did not discharge their Privacy Act duties. It did not close the underlying data exposure risk. What it did is clarify, for any board that was still uncertain, that vendor crisis governance is a contractual problem, not just a technical one.

When was the last time your board reviewed the decision rights embedded in your SaaS vendor contracts? If you cannot answer that question, you have not yet closed the governance gap the Canvas breach has opened.

Andreas Hamberger is a Wellington-based enterprise architect, security practitioner, and technology strategist with more than 30 years of experience across New Zealand's public and private sectors. He holds TOGAF, IAPP, and AMInstD credentials and is founder of Te Pono Limited. He is an Associate Member of the Institute of Directors New Zealand. The Hamberger Report: Cyber Guide for New Zealand Boards is the definitive board-level cybersecurity governance guide.

[1] Instructure. "Update regarding Canvas data security incident." 11 May 2026. URL to be confirmed at publication.

[2] Inside Higher Ed. "Canvas Data Breach: Instructure Reaches Agreement with ShinyHunters." May 2026. URL to be confirmed at publication.

[3] The Hacker News. "Canvas LMS Breach: XSS Exploit, Two-Wave Attack, and Governance Implications." May 2026. URL to be confirmed at publication.

[4] Malwarebytes. "Instructure Canvas breach: what happened and what it means." May 2026. URL to be confirmed at publication.

[5] Wikipedia contributors. "2026 Canvas security incident." Wikipedia, updated May 2026. URL to be confirmed at publication.

[6] New Zealand Herald. "University of Auckland, AUT and Victoria University of Wellington among those affected by Canvas data breach." 6 May 2026. URL to be confirmed at publication.

[7] Arnav.au. "Instructure Canvas breach synthesis and Congressional investigation reporting." May 2026. URL to be confirmed at publication.

[8] NCSC New Zealand. "Ransomware and extortion: standing guidance." NCSC NZ, current. ncsc.govt.nz.

[9] New Zealand Office of the Privacy Commissioner. "Privacy Act 2020: notifiable privacy breach obligations." OPC, current. privacy.org.nz.

[10] New Zealand Office of the Privacy Commissioner. "Information Privacy Principle 3A." OPC, effective 1 May 2026. privacy.org.nz.

[11] Halcyon Research. "ShinyHunters extortion model: payment guarantees and residual data risk." May 2026. URL to be confirmed at publication.

[12] Cyber Magazine. "Instructure Canvas breach coverage and analysis." May 2026. URL to be confirmed at publication.

Andreas H 11/05/2026 Andreas H 11/05/2026

Sovereign Compute in Orbit: India's Pathfinder, the GAO Reckoning, and the Architecture Question NZ Cannot Ignore

On 4 May 2026, two Indian companies announced they were putting a data centre in orbit.

Not a concept. Not a roadmap. A scheduled satellite with a confirmed launch window.

Pixxel, the Bengaluru-based satellite operator, and Sarvam, India's full-stack sovereign AI company, announced Pathfinder: a 200-kilogram-class satellite hosting data-centre-class GPUs, the same generation as ground-based AI factory hardware. Target launch: Q4 2026. Primary mission: training and inference, directly in orbit, on an entirely Indian-controlled stack with no foreign cloud or ground infrastructure in the inference data path.

Three days before that announcement, something else happened. On 28 April 2026, the U.S. Government Accountability Office published GAO-26-109012, "Data Centers in Space." The first formal U.S. federal-level evaluation of the orbital data centre category. The GAO does not move fast. When it does, it is because the category has moved from speculative to policy-relevant.

That is where we are now.

Both documents, taken together, mark a transition in how orbital compute is understood at the institutional level. It is no longer a category for aerospace engineers and venture capitalists. It is a scheduled category, a policy category, and with Pathfinder, a sovereignty category with a confirmed launch window and a manufacturing facility planned for 100 satellites per year.

This article examines what that means for the architecture question every enterprise leader and board director in New Zealand should be asking: is your current infrastructure building sovereignty, or outsourcing it under a different name?

The Energy Ceiling: Why the Investment Thesis Has Become a Policy Position

The GAO Spotlight is careful, as GAO documents are. It distinguishes between what is closer to maturity, smaller orbital systems for processing space-generated data, and what faces unproven engineering challenges, large platforms intended to train AI models at scale in space. It names the ceilings: thermal management; solar arrays larger than any assembled in orbit to date; radiation; orbital congestion; and a regulatory architecture gap that no current treaty framework resolves.

None of this was news to orbital engineers. What is significant is the document it appears in, and the projection it cites.

The GAO Spotlight references a U.S. Department of Energy projection: data centres could account for up to 12% of U.S. electrical demand by 2028. That is the Energy Ceiling. It is not an orbital compute argument in isolation. It is the structural ground-based constraint that makes the orbital compute investment thesis legible to a policy audience, in a federal document, for the first time.

When terrestrial compute approaches the limits of what a major grid can absorb, and when that ceiling is structural rather than cyclical, the economics of moving inference to orbit change in ways that matter to enterprise planners. The power is already there, in the form of solar arrays. The thermal problem is a current-technology engineering constraint, not a categorical impossibility. Low-Earth orbit latency characteristics make certain inference workloads viable in ways that geostationary deployments would not support.

Pathfinder is the first commercial deployment from outside the US-China axis to treat this as an operational proposition rather than a research question. The GAO said the pathway is real. India said the commercial case is compelling enough to schedule a launch. The distance between those two statements is where sovereignty either gets decided deliberately or defaults by inaction.

Three Answers to the Same Architecture Question

The Sovereign Kardashev framework from Space Mafia tracks state-level orbital infrastructure investment strategies. The framework has extended across two prior articles as an analytical structure for understanding who builds orbital compute, how they fund it, and what control looks like at altitude. Three variants are now visible and executing in parallel.

The Gulf-state variant: capital concentration and government procurement.

The Public Investment Fund of Saudi Arabia backs Neo Space Group. The United Arab Emirates committed AED 18.7 billion to Space42. In both cases, sovereign capital deploys directly into integrated orbital infrastructure stacks. The sovereign is the investor. Control flows from ownership. This variant moves fastest in terms of committed capital and is the most explicit about sovereignty as an investment thesis.

The public-private-partnership variant: India and Pathfinder.

Pixxel builds and operates the satellite. Sarvam supplies the AI backbone. Both are privately held Indian companies. Neither uses U.S. nor Chinese cloud or ground infrastructure in the inference data path. State support flows through ISRO's launch infrastructure and IN-SPACe licensing, not through direct ownership. The sovereign certifies and enables but does not own the operational stack.

This differs from the Gulf-state variant in one important respect: the Indian government does not need to make a direct capital commitment to establish sovereignty. It needs to maintain the regulatory and licensing environment in which domestically controlled operators can function. The control is at the stack level, not the ownership level.

Pathfinder is the cleanest non-US, non-China sovereign-AI orbital data centre case yet announced. It is the first deployment to name inference in orbit, on a fully domestic stack, as the primary mission rather than a secondary capability. Gigapixxel, Pixxel's manufacturing facility in Bengaluru, is planned for 100 satellites per year capacity. The question is not whether orbital AI inference is feasible. Pathfinder settles that. The question is what the governance layer looks like when it scales.

The collaborative-integration variant: New Zealand, the GBSI Act, and Rocket Lab.

New Zealand's posture differs in character from both of the above. Rocket Lab, a NZ-headquartered company, operates commercial launch infrastructure from Māhia Peninsula. The Outer Space and High-altitude Activities Act 2017 establishes the regulatory framework for space activity from NZ jurisdiction. No NZ-flagged sovereign-AI orbital data centre programme has been announced as of this writing.

The collaborative-integration variant is not a failure mode. It is a posture. NZ establishes the regulatory framework, attracts internationally competitive launch operators, and integrates into allied-nation orbital infrastructure through commercial partnerships. Collaborative Vertical Integration, the framework introduced in this series in Episode 7 to describe the Rocket Lab allied-nation model, is a governance-aligned alternative to single-entity ownership.

The question for NZ is not whether this posture is legitimate. It is. The question is whether it is deliberate.

A posture is only sovereign if it was chosen. If it exists because no one asked the question, it is an assumption, not a strategy.

The Operational Dependency Layer

For any NZ enterprise architect or board director who works with government workloads, health data, or critical infrastructure, the dependency layer beneath the sovereignty posture is relevant context.

NZ's primary international internet capacity runs on Southern Cross Cable, Hawaiki Cable, and Tasman Global Access. All three terminate in jurisdictions outside New Zealand for primary peering. This reflects NZ's geographic position. It is also directly relevant to any sovereignty claim about inference in orbit, because the path from orbital compute to NZ ground infrastructure runs through infrastructure NZ does not control.

NZ has no sovereign GNSS infrastructure. Positioning, navigation, and timing for any orbital activity from NZ jurisdiction depend on GPS, Galileo, GLONASS, and BeiDou. GNSS is a precondition for orbital sovereignty, not an output of it.

The AWS Auckland Region launched in 2024. Significant NZ government and Crown-entity workload now sits in that region. AWS Auckland is not an alternative to offshore dependencies; it is a closer instance of them. An enterprise architect who treats "Auckland-hosted" as equivalent to "sovereign" has not read the CLOUD Act.

None of these are arguments against the collaborative-integration variant. They are inputs to a clear-eyed assessment of what that variant does and does not protect, and where its boundaries sit.

The Agent Identity Complication

Microsoft Agent 365 reached general availability on 1 May 2026. Per-agent Entra Agent IDs, with registry synchronisation available across major cloud providers. Each agent that runs in an enterprise environment can now have a cryptographically anchored identity managed through a Microsoft-controlled registry.

This is a meaningful operational improvement for ground-based deployments. The Five Country Council's "Careful Adoption of Agentic AI Services" guidance, published the same week with NCSC NZ as a named co-author, specifically recommends per-agent cryptographically secured identity, short-lived credentials, and encrypted agent-to-agent communications. NCSC NZ has now contributed as a named co-author to three consecutive joint products in eight weeks, a cadence that reflects a shift from consuming international guidance to shaping it.

Those are the right recommendations for ground-based deployments. EA Thursday Chapter 12 established agent identity as the sixth Zero Trust pillar for precisely this reason, and the Five Country Council guidance validates that framing at the international policy level.

But Pathfinder surfaces a different question. When sovereign-AI inference runs in orbit on an Indian-controlled compute stack, and when the agent that triggers that inference has its identity registered in a cloud provider's registry, what exactly is sovereign? Sovereignty at the compute level is not the same as sovereignty at the identity level. They are two separate architecture questions.

Pathfinder answers the compute question. The identity question does not have a sovereign answer yet, and the current governance frameworks are not scoped to address it for orbital deployments specifically. This is not a criticism of those frameworks. It is an observation that the architecture problem is ahead of the governance response, which is exactly the pattern Space Mafia identifies in its Five Fault Lines analysis.

What the GAO Said About Engineering Ceilings

The GAO Spotlight's technology-maturity framing is often misread in both directions. The document is not a rejection of orbital compute. It is a differentiation.

Smaller orbital systems for processing data generated in space, imagery analysis, communications relay, earth observation: these are described as closer to maturity. The engineering challenges are understood and the deployment base is growing.

Large platforms for training AI models at scale in orbit: these face unproven engineering challenges. The Spotlight names thermal management specifically. Space does not cool computing hardware the way terrestrial data centre facilities do, because heat dissipation in vacuum requires radiative transfer rather than convective cooling. Solar arrays at the scale needed for data-centre-class AI workloads would be larger than any previously launched or assembled in space. Radiation hardening requirements add cost and complexity. Orbital congestion increases collision risk.

None of these ceilings are permanent. They are current-technology constraints.

Pathfinder's 200-kilogram-class satellite sits in the middle of this spectrum: not a Axiom-scale modular platform, but well beyond a CubeSat sensor node. It is precisely the class of deployment the GAO describes as viable in the near term. Pixxel has designed to the engineering envelope the GAO identifies as reachable.

The GAO Spotlight and the Pathfinder announcement read together are not in tension. They are complementary assessments from different vantage points. The GAO assessed the engineering frontier as of April 2026. Pixxel assessed the commercial case as of May 2026 and found it compelling enough to schedule a launch.

GBSI Act: 79 Days and Counting

The Outer Space and High-altitude Activities Act 2017 compliance deadline falls on 29 July 2026: 79 days from publication of this article. The Act regulates launch licensing, payload permitting, and orbital activity authorisation from NZ jurisdiction.

When the Act was passed in 2017, orbital data centres were not an operational category. They were a concept in aerospace white papers. As of the first week of May 2026, they are a scheduled deployment with a confirmed launch window from a non-US, non-China actor, and a federal U.S. policy document has named the engineering pathway. The category has moved significantly in the nine years since the Act was written.

NZ organisations that may be classified as space operators under the Act, the Hidden Space Operator problem this series has tracked across multiple episodes, should review their operational dependencies on orbital infrastructure against the Act's coverage. The 29 July deadline is the compliance timeline. The question of how the Act's framework maps to Pathfinder-class deployments is a governance question that extends beyond the compliance window.

The MBIE Aerospace Strategy 2023 provides NZ's national aerospace policy direction. It describes a framework developed before Pathfinder existed as a concept. That is not a criticism of the strategy; it is the nature of policy development timescales. It is relevant context for any NZ board director with technology portfolio responsibilities.

The Architecture Question

The three Sovereign Kardashev variants reduce to a single architecture question.

When something goes wrong at the orbital-to-ground inference layer, who controls the response decision?

In the Gulf-state variant, the state controls it because the state owns the stack. In the Pathfinder variant, a privately held domestic company controls it because the state has structured the environment so that domestic control is a condition of operation. In the collaborative-integration variant, the answer depends on which part of the stack fails, which partner controls that layer, and which jurisdiction's law applies to the response decision.

This is not an argument for one variant over another. Each serves different strategic objectives and different risk tolerances. It is an argument for knowing which variant you are in, and having an answer to the response-control question before you need it.

Pathfinder moves the orbital compute thesis from "in principle viable" to "Q4 2026, launch window confirmed." That changes the question from theoretical to architectural. The GAO Spotlight confirms the energy ceiling driving the investment is real and the engineering pathway for the deployable class is within reach. Both of these together mean that NZ enterprise architects and board directors should now treat orbital compute as a near-term operational variable, not a future-state scenario.

The Heaven and Skynet framing from Space Mafia does not predict which outcome orbital compute will produce. It identifies the governance conditions under which each pathway becomes more or less likely. Pathfinder is a Heaven Vector deployment by design: sovereign AI, domestic stack, no foreign dependencies in the inference path. The governance conditions that make that choice possible include the regulatory environment, the domestic AI industry, and the state's decision to certify rather than own the stack.

Three Sovereign Kardashev variants are executing in parallel. The next time you review your technology architecture, the question worth adding to the agenda is straightforward.

Which variant are you in, and did you choose it?

Andreas Hamberger is a New Zealand leader in Architecture and Security and Associate Member of the Institute of Directors. Space Mafia examines the sovereignty implications of orbital compute infrastructure.

[1] Pixxel and Sarvam. "Pathfinder: India's First Sovereign-AI Orbital Data Centre Satellite." 4 May 2026. https://pixxel.space

[2] U.S. Government Accountability Office. "Science and Tech Spotlight: Data Centers in Space." GAO-26-109012. 28 April 2026. https://www.gao.gov/products/gao-26-109012

[3] U.S. Department of Energy. Data centre energy projection cited in GAO-26-109012. 2025. Referenced via GAO Spotlight.

[4] ThePrint; Storyboard18; Business Standard; CRN Asia. Pathfinder announcement coverage. 4-5 May 2026.

[5] Microsoft Security Blog. "Microsoft Agent 365: General Availability." 1 May 2026. https://blogs.microsoft.com

[6] CISA; NSA; ASD's ACSC; Canadian Centre for Cyber Security; NCSC NZ; NCSC UK. "Careful Adoption of Agentic AI Services." 1 May 2026. https://www.cisa.gov

[7] New Zealand Government. "Outer Space and High-altitude Activities Act 2017." https://www.legislation.govt.nz/act/public/2017/0019/latest/whole.html

[8] UAE Space42. "AED 18.7 Billion Commitment to Orbital Infrastructure." Prior industry reporting 2025-2026. Multiple sources.

[9] Leonard David; Fed Contract Pros. "GAO Science and Tech Spotlight: Orbital Data Centres." 28 April and 6 May 2026.

Andreas H 10/05/2026 Andreas H 10/05/2026

Supply Chain Cyber: Three Universities, One Vendor, and the Question Boards Must Now Ask

On 30 April 2026, the United States learning management software company Instructure disclosed that its Canvas platform had been breached. Six days later, the New Zealand Herald confirmed that three New Zealand universities are publicly affected: Te Herenga Waka, Victoria University of Wellington; Auckland University of Technology; and the University of Auckland.[1] Spokespeople for AUT and the University of Auckland confirmed the affected status the same day.[1] As of writing, more than one in three New Zealand university students sit inside the affected population.

The data classes Instructure has confirmed exposed are limited: names, email addresses, student identification numbers, and Canvas Inbox messages. The company has stated that passwords, government identifiers, dates of birth, and financial data were not affected.[2] The criminal extortion group ShinyHunters has claimed responsibility and has reportedly asserted that 275 million individuals across approximately 9,000 institutions and 3.65 terabytes of data are involved.[3] The volume claim is contested. The deadline ShinyHunters set for ransom payment, 6 May 2026, has now passed.[3]

This is not the first time a New Zealand sector has woken up to find that its operational data lives somewhere offshore, in a system its institutions do not directly run. It is the third such event in five months. ManageMyHealth in December 2025. MediMap in February 2026. Now Canvas. The question for boards is not whether their data leaked. The question is what their incident response actually looks like when the controlling decisions sit with an offshore vendor under foreign extortion pressure.

This article is about that question.

What happened, and why a single breach matters at three universities

Canvas is operated by Instructure, headquartered in Salt Lake City. The platform holds approximately 41% market share in North American higher education learning management systems.[4] The same platform sits under a substantial portion of the New Zealand tertiary teaching environment. Three of New Zealand's eight universities have publicly confirmed exposure to the 30 April disclosure. Others may still be assessing.

The technical anatomy is unremarkable. A third-party software-as-a-service provider holds operational data for many institutions. An attacker compromises the provider. Every customer institution becomes a victim simultaneously. Each customer's communications, response options, and timeline are governed by what the vendor decides to disclose, when, and to whom. The institutional principal, the university in this case, does not control any of those decisions.

The pattern is familiar to any board that lived through ManageMyHealth in December 2025 (as I have written about throughout this series, the Cyber Guide for New Zealand Boards). MMH was a New Zealand-based provider holding 1.8 million health records across multiple primary care providers. When MMH was breached, every general practice, pharmacy, and aged-care provider that used the platform became part of the same incident. The decisions about disclosure timing, scope characterisation, and customer notification were made by MMH, not by the providers whose patients were affected. Sector-level concentration plus vendor-controlled response equals zero institutional optionality at the moment of disclosure.

Canvas is the same architectural pattern, in a different sector, on an offshore vendor footprint. MediMap in February 2026 was the same pattern again, with aged-care medication management. Three breaches, five months, one structural shape.

The architectural debt nobody catalogued

Architectural debt, as I describe it in the Cyber Guide for New Zealand Boards, is the accumulated cost of deferred security investments. It is a governance concept before it is a technical one. Most boards understand technical debt: the legacy system the engineering team keeps complaining about. Architectural debt is harder to see because it is distributed across the procurement decisions of dozens or hundreds of small purchases, made over many years, by people who individually had no reason to think their decision was strategic.

Choosing Canvas was not a strategic decision in the sense that the procurement leader at any New Zealand university knew, in the year of selection, that the institution was creating a single offshore concentration point for a substantial portion of its operational student data. It was a tools decision. It looked, at the time, like procuring a calendar product or a video conferencing licence. The architectural consequence accumulated quietly across the sector.

This is what the Audit of Intent framework is designed to surface. An Audit of Intent asks: when the board approved that procurement, what was the decision actually for? Was it for a teaching tool, with an implied small-scope incident profile? Or was it, in operational reality, for a sector-shared concentration point with an outsized blast radius and a foreign-controlled response surface? In most cases, the answer the procurement paper recorded and the answer the procurement decision created have drifted apart over time. That drift is architectural debt.

The Once-Only Resilience Framework I introduced in Part 4 of this series sits one floor above the Audit of Intent. It asks a board to inventory, for each material vendor concentration in the institution, whether the institution has the visibility, the contractual rights, and the operational capability to act independently of the vendor in an incident scenario. For most tertiary institutions on Canvas, the honest answer to all three questions is no. That is not a criticism of the institutions. It is the operational reality of buying a North American hyperscale-tier teaching platform as a New Zealand university.

The Once-Only test does not say no institution should ever buy a hyperscale platform. It says boards must know which of their vendor decisions have created concentration points that fail the Once-Only test, must record that failure in the risk register, and must put in place compensating governance: contractual notification timelines, operational shadow data, regulator-facing communication protocols that do not depend on the vendor's communication cadence. This is the work that Canvas now invites every affected New Zealand university board to do, retroactively, under time pressure, with limited information.

The Mythos environment around the breach

If the architectural debt observation is the inside-the-perimeter analysis, the next observation looks outward. Even when a breach is not discovered or executed by an AI system, the threat surface around it is now actively shaped by AI-augmented offence and defence. Boards must brief themselves on the discovery cost change, not only on the specific breach in front of them.

Three independent events landed in the 72 hours around the Canvas disclosure. None of them are about Canvas. All of them are about the environment Canvas was disclosed into.

On 29 April 2026, the United Kingdom National Health Service issued internal directive SDLC-8, mandating that public source code repositories convert to private by 11 May 2026. The directive cited the Mythos large language model by name as the rationale.[5] On the same day, security firm Theori publicly disclosed CVE-2026-31431, dubbed CopyFail, a nine-year-old logic bug in the Linux kernel discovered by Theori's Xint Code AI tool in roughly one hour of automated analysis.[6] Two days later, on 1 May 2026, six allied cyber security agencies, including the National Cyber Security Centre New Zealand, jointly published "Careful Adoption of Agentic AI Services," a 30-page guidance document covering 23 risks and more than 100 recommended practices.[7]

These three events are unrelated to Canvas. They are also the operational reality of cyber security in May 2026. The discovery cost for previously unknown vulnerabilities has fallen sharply because AI-augmented analysis tooling now finds them faster than human researchers can. The economics of attack and defence have shifted accordingly. Public source code repositories that were a defensive asset in the 2010s ("more eyes find more bugs") have become a defensive liability in the 2020s when the eyes belong to a model trained on every public repository simultaneously.

I am not predicting how the Canvas response will unfold. I am observing that the response is unfolding in an environment where the cost to find the next vulnerability has fallen by an order of magnitude, where the cost to weaponise it has fallen alongside, and where the institutions responding are building their playbooks against the threat landscape of two years ago. Boards that limit their cyber briefings to the specific incident in front of them are reading the wrong file.

The "Five Country Council" framing here matters. The Careful Adoption guidance is the third joint product in eight weeks where the National Cyber Security Centre New Zealand appears as a named co-author, not a guidance consumer.[7] New Zealand's national cyber security architecture is being treated by allied agencies as an interoperable peer in joint guidance production. This is a forward signal for boards: the level of allied coordination available to New Zealand institutions is increasing, but the operational uplift only reaches the institution that has the internal capability to read, internalise, and act on joint guidance. The Resilience Manifesto in Part 10 of this series put this work as a board-level commitment. The Canvas disclosure is the current operational illustration of why.

Where New Zealand's regulatory architecture sits today

Three regulatory facts shape the Canvas response in New Zealand. None of them are evaluative; all are factual.

First: the New Zealand Privacy Commissioner has not publicly opened an investigation into the Canvas disclosure as of writing.[8] Under the Privacy Act 2020, agencies are required to notify the Office of the Privacy Commissioner of notifiable privacy breaches; tertiary institutions are agencies under the Act.[9] The Privacy Commissioner's processes for inquiry initiation are a matter of public record on the Office's website. I am stating the public position. I am not interpreting it.

Second: Information Privacy Principle 3A commenced operation on 1 May 2026, the day after the Canvas disclosure.[10] IPP 3A creates obligations on agencies that collect personal information indirectly. The Canvas event is the first major New Zealand tertiary-sector breach to land after IPP 3A commencement. Affected institutions notifying their students will be doing so against a regulatory baseline that did not exist a week earlier. Boards should ask their privacy officers and general counsel to walk them through what changed on 1 May, and what specifically that means for the institution's notification work this week.

Third: the Department of the Prime Minister and Cabinet's consultation on a critical infrastructure regulatory regime closed on 19 April 2026.[11] The proposed regime, currently in consultation, includes director personal liability of up to NZ$500,000 for critical infrastructure entities that fail to meet baseline cyber resilience standards. The proposed regime's scope, as published in the consultation document, covers health, energy, telecommunications, financial market infrastructure, and water. Tertiary education vendors are not currently in scope. The Canvas event is a current operational illustration of the supply chain visibility considerations that the consultation document raises. Decisions on the final regime architecture remain pending. I describe the consultation document; I do not advocate scope expansion.

These three regulatory observations are factual. Each one carries an implication for how boards should brief themselves this week. Every implication runs through the institution's own response, not through commentary on regulatory or government performance.

What boards should actually do this week

Architectural debt frameworks and Once-Only Resilience principles only matter if they translate into action between Sunday and the next board paper deadline. Five questions deserve to sit on every audit and risk committee agenda this week. They are not specific to Canvas. They are specific to the architectural pattern Canvas exemplifies.

Ask your audit and risk committee chair to confirm, in writing, the institution's current vendor catalogue for systems holding student, patient, customer, or citizen records at scale. Not "we have a list somewhere"; a current, governed, board-visible catalogue. The first hour of an architectural debt remediation programme is finding out what the institution actually depends on.

Ask the executive team what the institution's contractual notification rights look like for each vendor in that catalogue. The Canvas disclosure timeline puts this on the agenda regardless of whether your institution uses Canvas. Notification rights you do not exercise in calm weather are notification rights you cannot rely on in a storm.

Ask the chief information security officer, or whoever holds the equivalent accountability, what the institution's operational shadow looks like for each material vendor. Operational shadow is the data, contact information, and process documentation the institution holds independently of the vendor, sufficient to communicate with affected populations and statutory bodies if the vendor is offline, uncooperative, or under foreign extortion pressure. The board does not need to specify the technical solution. The board does need to know whether the operational shadow exists.

Ask whether the institution's regulator-facing communication protocol depends on the vendor's communication cadence. If the answer is yes, the institution has built a single point of failure into its regulatory compliance posture. The Privacy Act 2020 obligations sit on the agency, not on its vendors.

Ask the chief executive how the institution would detect, this morning, whether a Canvas-class vendor concentration in its environment had suffered an integrity compromise rather than an exfiltration event. Canvas's confirmed data classes are exfiltration-typed. Learning management systems hold data classes (course content, gradebook entries, assignment submissions) where integrity compromise would be materially harder to detect than identity-data exfiltration. I am not asserting that any such compromise has occurred. I am asking whether the institution would know if it had.

These five questions take an hour to ask and a quarter to answer. The institutions that ask them this month will be in a different posture, twelve months from now, than the ones that wait.

Why I am writing this on Cyber Sunday rather than later

Cyber Sunday concluded its book-derived series, the Cyber Guide for New Zealand Boards, with Part 10 on 19 April 2026. From late April this slot has run as the Cyber News cycle: current cyber security developments with governance implications for boards, with no book arc behind it. Canvas is the first event under the new cycle that meets the criteria of the slot in their original form. A live operational incident, a confirmed New Zealand exposure surface, a board-actionable governance frame, and a structural pattern that survives the specific incident.

The trickle effect of writing about a current operational event is that the right boards will encounter the article in the weeks during which they are still deciding what to do. Two interconnected obligations sit on me when that happens. The first is that the analysis must hold up under scrutiny in two years, when the specifics are forgotten and the architectural pattern is what remains. The second is that the article must give the reader something they can do this week, not in the abstract future when the playbook is mature. Both obligations point to the same discipline. State the architectural pattern, name the framework, ask the operational question, and refuse to drift into commentary that the practitioner cannot use.

The Mythos operationalisation observation is the analytically distinctive contribution this week. Even when the next breach is not AI-discovered, the response will unfold in an environment where AI-augmented offence and defence are reshaping the discovery economics. Tuesday's Gen AI article will treat the regulatory dimension of the same shift; this article treats the architectural and operational dimension. The two pieces are designed to be read as a pair.

The architectural debt observation is the durable contribution. Five years from now, the specific Canvas disclosure will be a footnote. Some other vendor's customer notification email will be on the front page of the Herald. The board that has the vendor catalogue, the contractual rights, the operational shadow, the independent regulator-facing protocol, and the integrity-detection capability will be working through a different incident from a different posture. The board that does not will be working through the same incident again, with a different vendor name on the email subject line.

Has your audit and risk committee asked your tertiary education or health vendor what its incident response plan looks like when the controlling decisions sit offshore under foreign extortion pressure, and what your institutional escalation path is when those decisions and your obligations diverge?

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.

[1] Robinson, T., and Block, G. "Three NZ universities affected by Canvas LMS data breach." New Zealand Herald, 6 May 2026. https://www.nzherald.co.nz/

[2] Instructure. "Statement on Canvas data security incident." 1 May 2026. https://www.instructure.com/

[3] Toulas, B. "ShinyHunters claims Instructure Canvas breach affecting 275 million students." BleepingComputer, 3 May 2026. https://www.bleepingcomputer.com/

[4] Inside Higher Ed. "Canvas dominates higher education LMS market." Industry analysis, 2025-2026 sector reporting. https://www.insidehighered.com/

[5] OECD AI Incidents Monitor. "NHS England SDLC-8: source code repository privatisation citing Mythos." Incident 2026-05-01-5196, 1 May 2026. https://oecd.ai/en/incidents

[6] Theori. "CopyFail (CVE-2026-31431): nine-year-old Linux kernel logic bug discovered by Xint Code AI." Theori Research Blog, 29 April 2026. https://theori.io/research

[7] CISA, NSA, ASD's Australian Cyber Security Centre, Canadian Centre for Cyber Security, NCSC New Zealand, NCSC United Kingdom. "Careful Adoption of Agentic AI Services." Joint Guidance, 1 May 2026. https://www.cisa.gov/

[8] Office of the Privacy Commissioner New Zealand. Public bulletins, accessed 7 May 2026. https://www.privacy.org.nz/

[9] New Zealand Government. Privacy Act 2020. Notifiable privacy breaches: Part 6. https://www.legislation.govt.nz/

[10] Office of the Privacy Commissioner New Zealand. "Information Privacy Principle 3A: indirect collection of personal information." Commenced 1 May 2026. https://www.privacy.org.nz/

[11] Department of the Prime Minister and Cabinet. "New Zealand Cyber Security Strategy 2026-2030: critical infrastructure regulatory regime consultation." Consultation closed 19 April 2026. https://www.dpmc.govt.nz/

[12] BleepingComputer staff. "Instructure confirms Canvas LMS data breach." 3 May 2026. https://www.bleepingcomputer.com/

[13] SecurityWeek staff. "Canvas LMS breach: Instructure discloses data exposure." 1 May 2026. https://www.securityweek.com/

[14] Cybernews staff. "ShinyHunters extortion campaign: Canvas LMS breach analysis." 3 May 2026. https://cybernews.com/

Andreas H 29/05/2019 Andreas H 29/05/2019

Orbital Cybersecurity: NZ Is No Longer Just a Consumer

It All Begins Here

What NCSC-NZ's co-authorship of the five-nation LEO satcom security standard means for boards with satellite dependencies

One hour before Russian tanks crossed into Ukraine on 24 February 2022, a cyberattack struck a satellite operations network in Germany. The target was not a satellite. It was the ground segment controlling ViaSat's KA-SAT service. Within minutes, approximately 80,000 modems across Europe stopped responding. Ukrainian government communications went dark. German wind farms lost remote monitoring. French law enforcement lost connectivity.

Not a single satellite was physically touched. The attackers went for the ground.

That is the operational pattern that five allied governments documented in a joint Cybersecurity Information Sheet published on 24 March 2026. The document is titled "Securing Space: Cyber Security for Low Earth Orbit Satellite Communications." The authoring agencies are the Australian Signals Directorate's Australian Cyber Security Centre, the Australian Space Agency, the Canadian Centre for Cyber Security, the National Security Agency, and the New Zealand National Cyber Security Centre.

NCSC-NZ is not cited as a contributor, an endorser, or a distribution recipient. It is a named co-author on a primary intelligence document.

If your organisation depends on satellite connectivity, that distinction matters more than the technical content of the document itself.

What the Document Actually Says

The joint Cybersecurity Information Sheet (CSI) maps risks and countermeasures across five architectural segments of LEO satcom systems.

The space segment covers the satellites themselves. Threats include jamming, unauthorised command injection, payload hijacking, firmware tampering, signal spoofing, and malware injection. The primary mitigation is consistent encryption and authentication across the satellite's operational lifetime, plus a Software Bill of Materials (SBOM) for both satellite and ground-segment software requested from providers.

The ground segment covers control centres, ground stations, gateways, and user terminals. This is the primary soft target. SpaceX runs approximately 50,000 collision avoidance manoeuvres in the Starlink fleet every six months; the satellites are not where the vulnerability lies. The operations networks, ground stations, and user terminals are. The ViaSat 2022 attack demonstrated this with precision.

The user segment covers end-user devices and interfaces. Threats include credential compromise and man-in-the-middle interception on the user-to-satellite link.

The communication links segment addresses the radio-frequency channels susceptible to jamming, spoofing, and interception. LEO satellites move constantly across ground station coverage arcs; the handover moment between stations is a window that adversarial actors can exploit.

The supply chain segment covers the full hardware and software chain for LEO satcom systems. The CSI requests SBOM from providers and expects secure-by-design development practices throughout.

This is a technically grounded, practically applicable document. Its recommendations map directly onto procurement decisions, vendor management obligations, and board-level risk questions. But its production origin is the more significant signal.

The Co-authorship Signal

The governance argument at the centre of Space Mafia begins with an uncomfortable observation: the governance vacuum in orbital AI is the most dangerous single condition in the emerging space economy. "Build the rules before the rockets launch" is the book's closing imperative.

The CSI is evidence that at least five allied governments are acting on that imperative in real time, and that New Zealand is at the table when those rules are written.

The Space Mafia Three Clocks framework identifies three independently running timers that define the governance action window. The Orbital Clock measures debris accumulation and the approach of Kessler cascade thresholds. The Conflict Clock measures geopolitical deterioration and the acceleration of adversarial-state orbital capabilities. The Regulatory Clock measures the pace at which governance frameworks are being built.

The 24 March 2026 CSI is a Regulatory Clock event. Allied governments are building governance faster than debris accumulates and faster than the Conflict Clock advances. That is the optimistic reading of the data. It is also the correct one.

This is not the first joint intelligence product where NCSC-NZ appears as a named authoring agency. The joint product cadence, which previously focused on terrestrial enterprise IT security, has now extended to orbital infrastructure. Each product in this sequence represents the Regulatory Clock gaining on the Orbital and Conflict Clocks.

Five nations co-authoring a joint security standard for orbital infrastructure is not a routine publication event. It is a distributed, accountable, peer-based security architecture operating in real time. Episode 7 of this series introduced the concept of Collaborative Vertical Integration when examining how Rocket Lab's allied-nation model, spanning launch, spacecraft, propulsion, optical communications, and defence, provides a governance-aligned alternative to single-entity monopoly at the industrial level.

The NCSC-NZ CSI co-authorship is the security governance expression of that same structural commitment. Distributed authority. Mutual accountability. No single point of control or failure.

That structure is what the Heaven pathway looks like in practice.

Under the Skynet pathway, orbital infrastructure governance collapses into opacity, regulatory arbitrage, and capture of the commons by actors with no accountability to any national framework. The Adversarial Kardashev trajectory accelerates when governance frameworks are absent: state and non-state actors exploiting orbital infrastructure for coercive leverage rather than civilian benefit. The ViaSat attack was not an anomaly. It was a preview of what adversarial ground-segment targeting looks like at operational scale, and it preceded what the book's Adversarial Kardashev analysis identifies as the next escalation level: persistent disruption of LEO satcom infrastructure as a standard instrument of statecraft.

The CSI names this threat environment explicitly. So does the trajectory.

The Constellation Scale Problem

There is a reason this advisory appeared when it did.

The LEO satcom landscape has changed materially in the past eighteen months. Starlink now operates more than 10,300 deployed satellites, with regulatory approval for approximately 15,000 and applications filed for up to 42,000. Amazon Leo, rebranded from Project Kuiper in November 2025, has deployed 302 satellites of a planned 3,236, with consumer services targeted for mid-2026. China's Qianfan constellation has more than 100 satellites deployed of a planned 15,000. OneWeb operates approximately 650 satellites, repositioned for enterprise and government clients.

A 2025 RAND analysis projected approximately 25,000 satellites on orbit by 2031, with roughly 70 per cent operated commercially. The governance architecture for those constellations is being assembled right now. There is no existing treaty framework adequate to the scale of the task. The Five Country Council joint product line is one of the mechanisms building that architecture piece by piece.

Boards procuring LEO services today are making procurement decisions against a regulatory landscape that is still forming. The CSI represents the current thinking of five allied national security agencies about what secure procurement of those services looks like. A vendor unable to meet this standard is a vendor operating below the threshold that the allied intelligence community has publicly documented.

What This Means for NZ Organisations

New Zealand has a specific regulatory exposure that many organisations have not yet mapped.

The Outer Space and High-altitude Activities Amendment Act 2025 requires registration and compliance from any organisation that operates infrastructure supporting space objects. This includes ground stations, uplink facilities, and user terminals that form part of a LEO satcom service. The compliance deadline is 29 July 2026. Non-compliance carries a fine of NZ$250,000.

An organisation that procures Starlink connectivity for a rural operations facility, and whose terminal forms part of the service network, may qualify as a "space operator" under the Act without having sought that classification. The Hidden Space Operator risk, introduced in Episode 1 of this series, is not theoretical. It is an active compliance gap with a known deadline.

NCSC-NZ's co-authorship of the CSI, and the CSI's specific guidance on ground-segment and supply-chain security, is directly applicable to any NZ organisation assessing its obligations under the Act. The co-authorship establishes that the Act's compliance framework now has an internationally co-authored security standard sitting above it. These are not separate documents. They are the same governance architecture at different layers.

There are three questions every NZ board with LEO service dependencies should put to its providers before the 29 July 2026 deadline.

One: Where are your ground stations, and who has physical access? The ViaSat attack targeted a ground station in Germany. The critical vulnerability in a LEO satcom service is not the satellite; it is physical and cyber security of the ground infrastructure. A provider should be able to confirm the jurisdictions in which its ground stations operate, the security protocols governing physical access, and whether those ground stations are subject to the CLOUD Act or equivalent legislation that would expose NZ-origin traffic to foreign government access.

Two: Can you provide a Software Bill of Materials for ground-segment and satellite software? The CSI explicitly requests this from providers. A provider unwilling to produce an SBOM either does not know its own supply chain or has reasons to obscure it. Neither position is acceptable for an organisation with GBSI Act exposure. SBOM requests are now a standard due diligence item in allied government procurement; NZ boards should apply the same standard.

Three: What is your timeline for post-quantum cryptographic migration across the ground and link segments? Post-quantum migration is underway across allied government systems. The CSI's supply chain guidance encompasses cryptographic standard hygiene. A LEO satcom provider with no defined migration timeline is passing an accumulating cryptographic risk to its clients, and that risk compounds as the handover window problem in LEO link segments is more exposed to harvest-now-decrypt-later attacks than most terrestrial services.

What to Watch Next

The joint product cadence has extended from terrestrial IT into orbital infrastructure. That shift is not cosmetic.

Several developments are worth monitoring over the next six months.

The GBSI Act enforcement window opens on 29 July 2026. Organisations that have not assessed their space operator classification by that date face both regulatory exposure and the operational risk of unregistered infrastructure. The enforcement transition is not a formality; MBIE has signalled active compliance monitoring.

The self-healing constellation pattern is emerging as an operational architecture. Satellites capable of detecting threats autonomously and sharing intelligence with trusted neighbouring satellites in their constellation represent the next frontier of orbital cyber defence. These capabilities are being developed across defence and commercial programmes; the governance frameworks for autonomous machine-to-machine threat response in orbit do not yet exist at adequate scale.

The post-quantum migration timeline across commercial LEO providers is the near-term supply chain watch item. The Linux 7.0 kernel, released 12 April 2026, introduced ML-DSA post-quantum signatures for kernel module authentication. Allied government systems are migrating now. Commercial LEO satcom providers operating with legacy cryptographic standards in their ground and link segments carry an accumulating risk that their enterprise and government clients are inheriting by default.

The joint product line from the Five Country Council will continue. The CSI on LEO satcom security is unlikely to be the last orbital infrastructure advisory in this sequence. NZ's position as a named co-author in this product line is a structural commitment, not a single-publication event.

The Architecture of Accountability

New Zealand has been a passive beneficiary of allied intelligence sharing for most of its digital history. The NCSC-NZ co-authorship of a joint LEO satcom security advisory signals a shift in that relationship. Not because of political intent, but because NZ has developed the institutional capability and the operational depth to contribute to the architecture of the standard itself.

The governance architecture for the orbital era is being built in real time. The window to shape it is open. The Corporate Kardashev trajectory, the Vertical Integration Singularity dynamic, and the Pirate Radio Parallel all describe the same underlying pattern: the exploitation of governance vacuums by actors with the capital and operational presence to move faster than national frameworks.

The CSI is evidence that five nations are choosing not to let that pattern complete itself unchallenged.

The board that does not know this, and has not asked its LEO providers the three questions above, is the board that will be surprised when the compliance window closes on 29 July 2026.

What would change about your organisation's LEO procurement approach if your board treated the NCSC-NZ co-authorship of this advisory as a direct compliance signal rather than a background document? And have you asked your satellite connectivity provider whether it can produce an SBOM?

Andreas Hamberger is an enterprise architect, security practitioner, and technology strategist with more than 30 years of experience across New Zealand's public and private sectors. He holds TOGAF Practitioner, IAPP, and AMInstD credentials and a Master of Arts in Philosophy and Logic from Humboldt-Universität zu Berlin. He is an Associate Member of the Institute of Directors New Zealand and principal of Te Pono Limited. Space Mafia examines the sovereignty implications of orbital compute infrastructure.

[1] Australian Signals Directorate's Australian Cyber Security Centre, Australian Space Agency, Canadian Centre for Cyber Security, National Security Agency, New Zealand National Cyber Security Centre. "Securing Space: Cyber Security for Low Earth Orbit Satellite Communications." 24 March 2026. https://media.defense.gov/2026/Mar/24/2003902673

[2] National Security Agency. "NSA Joins International Partners to Release Cybersecurity Guidance for Space Systems." Press Release. 24 March 2026. https://www.nsa.gov/Press-Room/

[3] Via Satellite. "Satellite Ground Systems Remain Primary Cyber Target." April/May 2026.

[4] Intelligence Community News. "Five Nations Release LEO Satellite Cybersecurity Advisory." 25 March 2026.

[5] GlobalSecurity.org. "Securing Space: Cyber Security for Low Earth Orbit Satellite Communications." 24 March 2026. https://www.globalsecurity.org

[6] Wikipedia. "Amazon Satellite Internet." Updated 30 April 2026. https://en.wikipedia.org/wiki/AmazonSatelliteInternet

[7] RAND Corporation. Orbital Infrastructure Projections 2025. 2025.

[8] New Zealand Ministry of Business, Innovation and Employment. Outer Space and High-altitude Activities Amendment Act 2025. https://www.legislation.govt.nz/

[9] NCSC New Zealand. "Cyber Security Insights Report, Q3 2025." https://www.ncsc.govt.nz/

[10] Federal News Network / Claroty / Sovada. "US Satellite Cybersecurity Act: OT-Layer Implications." 27 February 2026.

[11] Hamberger, Andreas. Space Mafia: Who Gets to Own Orbital Compute? Te Pono Limited, 2026.