NCUA's 2026 Cybersecurity Report: Most Credit Union Incidents Involve Vendors the Regulator Can't Examine

TL;DR

• The NCUA’s 2026 Cybersecurity and Credit Union System Resilience Report documents 588 reported cyber incidents between May 2025 and April 2026. The majority traced to third-party vendors.
• NCUA cannot directly examine those vendors. The regulator can assess the credit union’s vendor management program, but not the vendor itself.
• One fourth-party ransomware attack — targeting a vendor’s vendor — disrupted more than 60 credit unions simultaneously with no systemic event declared.
• H.R. 10230 would give NCUA direct examination authority over critical third parties. Credit union trade associations are pushing back on scope.
• The practical implication: your incident response program needs to be built for a scenario your regulator can’t see into — a vendor going dark.

NCUA releases an annual cybersecurity report to Congress every year. This one landed quietly, as these reports tend to. The numbers in it are not quiet.

The 2026 Cybersecurity and Credit Union System Resilience Report covers the period May 1, 2025 through April 30, 2026. Credit unions reported 588 cyber incidents during that window — ransomware, phishing, business email compromise, ATM jackpotting, and third-party provider failures. The majority of those incidents, consistent with every prior reporting period, traced back to a third-party service provider.

That number sits in an uncomfortable context: NCUA has no direct authority to examine those service providers. The agency can look at the credit union’s vendor management program. It cannot walk into a core processor’s operations center and assess the controls that are actually protecting 60 million credit union members.

The Structural Problem

The Federal Deposit Insurance Act gives the FDIC, the Federal Reserve, and the OCC varying degrees of authority to examine bank service providers. The Bank Service Company Act extends some federal examination authority to entities that perform services for banks. NCUA has neither equivalent. The regulator of a sector that collectively manages roughly $2 trillion in assets depends, for its visibility into vendor risk, entirely on what credit unions put in their vendor management programs and what vendors choose to disclose voluntarily.

Every year the annual cybersecurity report documents what happens when that arrangement fails. For the 2023–2024 reporting period, NCUA documented 1,072 cyber incidents, of which nearly 7 in 10 traced to a third-party vendor. The 2026 period continues the same pattern — vendor incidents account for most of what NCUA sees.

The mismatch is obvious. The incidents are mostly vendor-origin. The examination authority stops at the vendor’s door.

NCUA Chairman Kyle Hauptman has been explicit about this gap in testimony to Congress. The NCUA’s request for legislative authority to examine credit union service providers is not a new ask — but the 2026 report gives it fresh statistical backing. The existing interagency TPRM proposed guidance from September 2026 applies to banks and their regulators. For the credit union sector, the regulatory gap is more fundamental: it’s not about what the guidance says, it’s about whether the regulator can see the vendor at all.

The Fourth-Party Incident That Should Have Been a Systemic Event

The most significant data point in recent NCUA cybersecurity reporting isn’t a headline number. It’s a scenario description.

In the prior reporting cycle, NCUA documented a ransomware attack on a fourth-party vendor — an entity providing services to a core service provider — that disrupted more than 60 credit unions simultaneously. None of those credit unions had a direct contractual relationship with the attacked entity. Most of them probably didn’t know it existed. Their core processor relied on it. The processor went down. Their members couldn’t access accounts.

NCUA assessed that no systemic threat was present. Sixty-plus credit unions disrupted at once with no systemic determination. That’s worth examining.

The scenario isn’t hypothetical anymore. It’s documented. And the interagency proposed TPRM guidance from last month — which applies to banks, not credit unions under NCUA’s jurisdiction — describes exactly this problem: the institution is responsible for assessing and managing the risks of its third parties’ own dependencies, all the way down the chain.

For credit unions, the fourth-party visibility gap is both a vendor management problem and an incident response problem. If you don’t know what fourth parties your core processor depends on, you can’t scenario-plan for their failure.

The nth-party risk analysis published earlier this year laid out the conceptual framework for mapping subcontracting chains — the same logic applies here, and it’s not just a bank problem. Credit unions with one or two core processors covering most of their critical functions are concentrated in ways that regulatory examination can’t directly address.

H.R. 10230 and the Examination Authority Push

Rep. Bill Foster introduced H.R. 10230, the Strengthening Oversight for the Financial Sector Act of 2026, in the current Congress. The bill would grant NCUA direct examination authority over third-party service providers to credit unions — giving the agency tools analogous to what the OCC and FDIC have for bank service companies.

The bill is in committee. Credit union trade associations, including NAFCU, have raised concerns about the scope of examination authority and the compliance burden on service providers who serve many credit unions. The political path forward is uncertain.

But the legislative conversation is the most visible signal that the current regulatory structure is acknowledged as inadequate — not by critics, but by the regulator itself. NCUA supports the authority expansion. The question is whether Congress will act.

For compliance and risk teams at credit unions, the legislative timeline is not the relevant planning horizon. H.R. 10230 may pass this Congress. It may not. Either way, your vendors are not currently subject to NCUA examination, and the incident data says that’s where most of your incidents originate.

The gap is yours to manage. Waiting on Congress doesn’t help your incident response program.

What This Means for Your Incident Response Plan

Most credit union incident response programs are built around scenarios where the credit union controls the affected system. Ransomware hits your servers. A phishing campaign compromises your employee credentials. An insider threat exfiltrates member data from your network. You detect, contain, notify NCUA within 72 hours, and work through the response.

The vendor incident scenario is structurally different. The affected system is not yours. The detection timeline is the vendor’s. The containment decisions are the vendor’s. The information you receive is what the vendor chooses to share, on the vendor’s schedule, through whatever contractual notification mechanism you put in place — if you put one in place.

NCUA can’t go examine the vendor in real time. You need to build the response capability yourself.

Map your fourth-party dependencies for critical services. Start with your core processor. What does your core processor depend on for its own operations? Payment network connections, data hosting, authentication services, disaster recovery infrastructure? These are your fourth-party exposures. If any of them go down, your core processor goes down, and you go down. Most credit unions cannot answer this question with specificity. The 60-credit-union ransomware scenario happened because no one could.

Get vendor incident notification rights into contracts. This applies to every critical third party you contract with. Not a vague notification obligation — a specific requirement: notify us within [X] hours of any incident affecting services delivered to us, include the nature of the incident, estimated duration, and affected systems. The NCUA’s 2026 supervisory priorities make vendor contract quality a specific examination focus. Examiners will ask to see notification provisions.

Build a vendor-dark scenario into your tabletop exercises. The scenario is: your core processor is unreachable for 72 hours. You don’t know why. You get a brief notification from the vendor that they’re experiencing a “system disruption.” What happens to member access? To ACH settlement? To loan payments? To payroll origination? To your NCUA 72-hour notification obligation if you don’t yet know whether a member data breach occurred? Your tabletop should have this scenario. Most don’t.

Establish an independent vendor escalation path. When your vendor’s normal support channel is down because their system is down, who do you call? Do you have a direct line to the vendor’s incident management team — not the customer service desk? Do you have a peer network of other credit unions using the same core processor who can share real-time information about scope and impact? Build these paths before you need them. A vendor going dark is exactly when their standard communication channels fail.

Track vendor incident data as a separate KRI. Your incident response program should be tracking third-party incidents as a distinct metric — separate from direct credit union incidents. Volume of vendor-reported incidents per quarter, number of incidents that interrupted critical services, time from vendor notification to credit union remediation. These metrics tell you something about your vendor’s operational reliability that no amount of SOC 2 review captures. The third-party incident KRI framework built around this specific problem is worth connecting to your NCUA exam management process.

The Examination Gap Is Not Going Away Soon

H.R. 10230 is in committee. The interagency TPRM proposed guidance that would require banks to assess vendor operational resilience applies to OCC/FDIC/Fed-supervised institutions — not to credit unions under NCUA. CIRCIA’s final rule, which entered OMB review on October 1, 2026, will create 72-hour vendor breach reporting obligations for critical infrastructure entities, but it doesn’t give NCUA examination authority. These are parallel developments, not a solution.

NCUA has been managing this gap through examination of credit unions’ vendor management programs — looking at due diligence documentation, contract terms, and oversight evidence rather than examining the vendor directly. That’s a reasonable accommodation to a structural limitation. It also means that when you sit across from an NCUA examiner and they ask about your third-party risk management program, they’re compensating for something they can’t do themselves.

The incidents in the 2026 report aren’t surprising. They’re documenting a risk that every credit union practitioner already knows: your biggest operational vulnerabilities are controlled by organizations your regulator cannot examine.

Building an incident response program that accounts for that gap — one that doesn’t assume the vendor will communicate clearly, quickly, or completely — is the practical response to a structural problem that legislation may eventually fix, but probably not in time for your next exam cycle.

Resources used to build this post:

• NCUA 2026 Cybersecurity and Credit Union System Resilience Report
• CeFPro: NCUA Seeks Vendor Authority as Third-Party Cyber Incidents Surge
• CU Insight: NCUA Releases Annual Cybersecurity and Credit Union System Resilience Report
• NAFCU: HFSC AI Task Force Discussion — NCUA Third-Party Vendor Authority
• FortifyData: NCUA Third-Party Risk Management for Credit Unions — What Examiners Expect in 2026

Related reading on this site:

• NCUA 2026 Supervisory Priorities: What Examiners Are Looking For This Exam Cycle
• Nth-Party Risk: Managing the Subcontracting Chain Under OCC 2023-17
• What the New Interagency TPRM Proposal Requires Before November 16

If your incident response plan was built for scenarios where you control the affected system, the Incident Response & Breach Notification Kit includes vendor breach response playbook components, notification clock tracking templates, and tabletop scenarios specifically designed for third-party-origin incidents.