How to Assess a Digital Banking Vendor's Software Risk at a Credit Union

A credit union should assess a digital banking vendor's software the way NCUA's rules already describe vendor oversight: do due diligence before signing, write security duties into the contract, and monitor the vendor afterwards in proportion to the risk. For software, that means tiering the vendor by what it touches, asking for a software bill of materials (SBOM), a vulnerability handling process, patch timelines and secure development evidence, then watching the components the vendor ships for newly exploited vulnerabilities between annual reviews.

The reason the work lands on the credit union is structural. NCUA has no general authority to examine most technology vendors directly, so its examiners look at how the credit union oversees them. This post walks through the rules that create the obligation (12 CFR Part 748 and its appendices, NCUA's letters, the FFIEC handbook and the 2023 interagency guidance as a reference point), turns them into a software specific vendor review, and then shows how Safeguard supports that review today. Nothing here is legal advice; your counsel and your examiner decide what applies to your institution.

Key takeaways

• 12 CFR Part 748, Appendix A, section III.D asks each federally insured credit union to use due diligence in choosing service providers, require safeguards by contract, and, where its risk assessment indicates, monitor providers through audits, test summaries or equivalent evaluations.
• Since September 1, 2023, 12 CFR 748.1(c) requires notice to NCUA within 72 hours of a reportable cyber incident, including one caused by a third-party or supply chain compromise. The clock can start when a third party tells you.
• NCUA Letter 07-CU-13 and its enclosed Supervisory Letter 07-01 remain the core third-party guidance, and the 2026 priorities letter (26-CU-01) cites it.
• The FFIEC Cybersecurity Assessment Tool was sunset on August 31, 2025; NCUA still offers its voluntary ACET.
• Ask a digital banking vendor for an SBOM per release, a vulnerability handling process, patch timelines with a KEV target, secure development evidence and notice terms that fit your 72-hour clock.
• Safeguard supports the software part with TPRM (GA): vendor directory and tiers, single and bulk SBOM requests with status tracking and follow-ups, a 0 to 100 vendor risk score (higher is better) using EPSS and CISA KEV, and alerts on new critical vulnerabilities, KEV additions, risk changes and SBOM expiry. Portal Find & Review SBOMs (GA), the compliance and GRC suite (GA) and the MCP server (GA) help; the desktop app is generally available and fork and patch is generally available.
• Safeguard cannot make a vendor respond, does not examine the vendor's build, and its score is a prioritisation aid, not an examination finding.

Why a credit union carries the vendor load itself

Banks and credit unions buy similar software from a small number of specialist providers: core processing, online and mobile banking, digital account opening, lending and payments. The difference is who can look inside those providers.

The federal banking agencies can examine technology service providers that serve their institutions. NCUA generally cannot. GAO's July 2015 report GAO-15-509 asked Congress to consider giving NCUA authority to examine technology service providers that serve credit unions. GAO still lists that matter as open, noting two bills (S. 3554 and H.R. 7036) with no further action as of February 2026.

So the credit union is the main line of oversight. When an examiner asks whether the digital banking platform protects member information, the answer is whatever the credit union's vendor file shows. That file usually holds a contract, a SOC report, a financial review and a questionnaire. It rarely says which open source components the platform runs on, which carry known exploited vulnerabilities, or how fast the vendor patches. Those questions matter now because NCUA's own incident rule names supply chain compromise.

What 12 CFR Part 748 and its appendices require of service provider oversight

Part 748 is NCUA's security program regulation. Three parts of it shape a vendor review.

748.0 and 748.1: the program and the annual certification

Section 748.0 requires every federally insured credit union to keep a written security program that, among other things, ensures the security and confidentiality of member records and protects against anticipated threats and unauthorized access. Section 748.1(a) requires the president or managing official to certify compliance with Part 748 annually in the Credit Union Profile through NCUA's online system. So the vendor oversight described below is not optional background reading; it sits inside a program someone signs for every year.

Appendix A: the Guidelines for Safeguarding Member Information

Appendix A implements the Gramm-Leach-Bliley Act safeguards requirement for credit unions (15 U.S.C. 6801 and 6805(b)). Its section III sets out the program; most of it touches vendors.

Section III.D names its own evidence: audits, summaries of test results, or "other equivalent evaluations." An SBOM with a current vulnerability analysis is a fair example of an equivalent evaluation for software. It does not replace an audit report, but it answers what an audit report usually does not: what is inside the product, and is any of it being exploited now.

Appendix B: response programs and service providers

Appendix B is NCUA's guidance on responding to unauthorized access to member information. Two passages matter for contracts. First, it says a credit union's contract with its service provider should require the provider to take appropriate actions to address incidents of unauthorized access to member information, including notifying the credit union as soon as possible. Second, where an incident involves systems a service provider maintains, it is still the credit union's responsibility to notify members and its regulator, although the credit union may contract with the provider to send notices on its behalf.

Read together, Appendices A and B put the obligation on the credit union and the mechanism in the contract.

What NCUA's cyber incident rule means for vendor contracts

NCUA amended Part 748 in 2023 to add a cyber incident notification requirement. The NCUA Board approved the final rule on February 16, 2023, and it took effect on September 1, 2023. The text now sits at 12 CFR 748.1(c).

The 72-hour clock

A federally insured credit union must notify NCUA of a reportable cyber incident as soon as possible and no later than 72 hours after it reasonably believes it has experienced one. NCUA describes the notice as an early alert; the credit union does not have to provide a full assessment within that window. Since January 2025, Letter 25-CU-02 (an update to 23-CU-07) adds an online reporting webform alongside the phone line and secure email route.

The third-party trigger

The definition of a reportable cyber incident has three branches. The third, at 748.1(c)(1)(i)(C), covers a disruption of business operations or unauthorized access to sensitive data "facilitated through, or caused by" a compromise of a credit union service organization, cloud service provider, or other third-party data hosting provider, or by a supply chain compromise.

The rule also says that for this branch the 72 hours can run from the moment the credit union is notified by a third party, whichever is sooner. In other words, if a digital banking vendor tells you on a Friday evening that a compromised component in its platform exposed member data, your NCUA clock may already be running from that message.

What this means for the contract

The rule binds the credit union, not the vendor, so the contract has to do the work:

• Notice timing. The vendor's duty to tell you must be short enough for you to meet 72 hours. "Within five business days" leaves you exposed.
• Notice content. NCUA's reporting guide asks when the incident occurred and whether member information was compromised. The vendor must supply that quickly.
• Supply chain scope. A compromised component or subcontractor inside the vendor's product should count as an incident the vendor must report, not only a breach of its own network.
• Cooperation. Appendix B expects you to notify members when warranted; the vendor should support that with logs and affected account lists.
• Vulnerability notice. Add a separate duty to tell you when a vulnerability in CISA's Known Exploited Vulnerabilities (KEV) catalog affects your version, with a remediation date. Incident clauses do not cover this.

That last clause is where most contracts are silent, and where watching the vendor's components pays off: you may learn about an exploited vulnerability in your platform before the vendor calls.

Which NCUA letters and FFIEC booklets still apply after the CAT was retired

Here is the status of each source as we found it on the agencies' own pages in October 2026.

07-CU-13 and Supervisory Letter 07-01

The 2007 letter is still the one examiners point to. Its enclosure organises the work into risk assessment and planning, due diligence, and risk measurement, monitoring and control, scaled to the credit union's size, complexity and risk profile. It asks whether staff can monitor the relationship and whether there is a reasonable exit strategy.

Its minimum contract list still holds: responsibilities of all parties (including subcontractor oversight), ownership of and access to records, audit rights, data security and member confidentiality (including testing and audit), insurance, and default, termination and escape clauses. It also urges credit unions to negotiate rather than accept the vendor's paper.

It mentions SAS 70 reports, long since replaced by SOC reports, and says nothing about software composition. Keep its structure and fill the software gap with the evidence below.

01-CU-20

The 2001 letter was written about lending partnerships, but its sequence still describes a sound vendor review: decide whether the activity fits the credit union's strategy and risk tolerance, check references, have counsel review the contract, review the vendor's financial condition and insurance, then put monitoring and board reporting in place. It states that failing to adopt monitoring and reporting practices "constitutes an unsafe and unsound practice."

The 2026 supervisory priorities letter

Letter 26-CU-01 does not add new rules. It does tell you where examiners will look. In lending, it says that when lending, servicing or collection functions are outsourced, examiners will also assess third-party risk management practices as appropriate, and it lists 07-CU-13 as a resource. In payment systems, it says examiners will continue to assess whether credit unions have effective governance, risk assessments, vendor management and security frameworks. It also restates that NCUA will continue to enforce information security requirements.

For a credit union buying a digital banking or lending platform, that is a direct line from the priorities letter to the vendor file.

What happened to the FFIEC CAT, and what replaced it

The FFIEC sunset the Cybersecurity Assessment Tool on August 31, 2025. The OCC's Bulletin 2024-25 (August 29, 2024) explains that the FFIEC chose not to update it for NIST Cybersecurity Framework 2.0 or CISA's Cybersecurity Performance Goals and pointed institutions to those resources, and notes that NCUA would keep supporting its own CAT-derived tool.

NCUA's page now calls that tool the Automated Cybersecurity Evaluation Toolbox (ACET), says it is completely voluntary and adds no requirements, and describes a new version with updated security and NIST references. Its external dependency questions are a natural home for the software evidence below. See also what replaced the FFIEC CAT.

The FFIEC Outsourcing Technology Services booklet

The booklet is still listed in the FFIEC IT Examination Handbook InfoBase, with sections on due diligence, contract issues, ongoing monitoring, service level agreements and contract provisions, and an appendix on managed security service providers. The live handbook site blocked automated access while we were researching, so we read an archived copy captured in March 2026; check the InfoBase directly for its current issue date before you cite it in policy.

Why the interagency guidance is useful even though NCUA did not issue it

The June 2023 Interagency Guidance on Third-Party Relationships came from the Federal Reserve, the FDIC and the OCC. Its preamble records commenters asking NCUA to join; NCUA did not, so it does not bind credit unions.

It is still the most detailed public statement of what software due diligence can cover. It says assessing a third party's application security program, "including the software development life cycle and results of vulnerability and penetration tests," can inform you about system vulnerabilities, and it mentions secure source code management and the third party's technology inventories. It also addresses vendors that will not share, covered below. Our sibling post looks at the same guidance from the fintech side of a sponsor bank relationship.

What software evidence to ask a digital banking vendor for

Most vendor questionnaires ask whether the vendor has a secure development policy and whether it patches promptly. Both answers will be yes. The evidence below is harder to fake and easier to verify.

1. An SBOM for each product and release you run

An SBOM is a machine-readable list of the components in software, with versions and identifiers. Ask for one per product and per release in production, in SPDX or CycloneDX.

The current reference is CISA's 2026 Minimum Elements for a Software Bill of Materials, released July 29, 2026 by CISA, NSA, FBI and international partners. It builds on the 2021 NTIA elements, adds fields including component hash, license, SBOM tool name and SBOM generation context, and covers open source, AI and SaaS. Ask the vendor to meet it or say which fields it cannot yet provide. For a hosted platform, scope the SBOM to what runs your members' sessions: web and mobile front ends, APIs and the server components that handle member data.

2. A vulnerability handling process, in writing

Ask how the vendor learns about vulnerabilities in its own code and its components, how it decides severity, and how it tells customers. Ask whether it publishes advisories, and whether it can provide a VEX statement (a document that says whether a known vulnerability actually affects its product) when a component vulnerability does not apply.

3. Patch timelines by severity, with exploited vulnerabilities called out

Ask for target remediation times by severity, a shorter target for KEV-listed vulnerabilities, and the vendor's actual performance over the last year. For context, CISA's BOD 22-01 is revoked and superseded by BOD 26-04, Prioritizing Security Updates Based on Risk. Neither binds a credit union or its vendors; set your own expectations in the contract.

4. Secure development evidence

Ask how the vendor's development practices map to NIST SP 800-218, the Secure Software Development Framework, or an equivalent. Ask for the most recent independent penetration test summary for the product you use, and the remediation status of its findings. If the vendor has a SOC 2 report, check whether its scope covers the product and the development process, not just the data center.

5. Incident and vulnerability notice terms

As above: notice of incidents fast enough for your 72-hour clock, supply chain compromises in scope, and a separate notice duty for KEV-listed vulnerabilities in your version.

6. Refresh and access

Ask for updated SBOMs on every release in your environment, shared through a portal that keeps history rather than by email. Our posts on writing an SBOM request to a supplier and contract clauses banks expect from software vendors have wording you can adapt.

A request list you can paste into your RFP or renewal

How to tier vendors and set review frequency

Appendix A ties monitoring to your risk assessment, and 07-CU-13 scales due diligence to the criticality of the service. A defensible tiering looks at what member data the vendor touches, whether the service is critical to member operations, how many members use it, and whether its software runs inside or connects to your environment.

Document why each vendor sits where it does, and re-tier when the relationship changes: a new module, a new data feed, or a merger on the vendor's side.

How to monitor a vendor between annual reviews

Appendix A III.E asks credit unions to adjust the program for new threats, and the interagency guidance says monitoring can be periodic or continuous, with more for critical activities. For software, "continuous" is achievable because the inputs are public: new CVEs, EPSS scores and KEV listings are published every day.

What to watch

• New KEV listings matching the vendor's components. CISA lists only vulnerabilities with evidence of exploitation. A match in your version means a call that day.
• New critical CVEs with high EPSS scores. FIRST's Exploit Prediction Scoring System estimates the probability of exploitation activity; a high score deserves attention before a KEV listing.
• SBOM age. An SBOM three releases old describes software you no longer run.
• Posture drift. Rising open vulnerability counts or slipping remediation times say something about the vendor's engineering capacity.
• Evidence dates. SOC report periods, penetration test dates and renewal windows.

What to do when something matches

1. Confirm the match: is the affected component in the product and version you run?
2. Ask the vendor for its assessment and a remediation date, in writing.
3. Decide whether you need compensating controls in the meantime (for example, tighter monitoring of the affected function).
4. Check whether the situation meets the 748.1(c) reportable incident definition. A vulnerability alone usually does not; exploitation that disrupts operations or exposes sensitive data may.
5. Record the outcome in the vendor file and carry it into the annual board report under Appendix A III.F.

Our post comparing continuous vendor monitoring with annual review goes deeper on cadence.

What to do when a vendor will not share

The interagency guidance anticipates vendors that are unable or unwilling to provide information: document the limitation, understand the risk, and consider alternatives such as other information, added controls or monitoring, or a different provider. For a credit union that becomes a short path:

1. Offer a narrower ask: components and versions for member-facing services only, under NDA or through an access-controlled portal.
2. Ask for attestation of outcomes: a written statement that no KEV-listed vulnerability is present in your version, with notice within a set number of days if that changes.
3. Use the renewal. SBOM delivery is easier to win then than mid-contract.
4. Record the gap and the compensating controls in the vendor file. That record is what the examiner will look for.
5. Tell the board when a critical vendor refuses, because the board owns the risk appetite.

How Safeguard does this job, step by step

Everything above can be run with spreadsheets and email. It just gets harder with every vendor you add. Safeguard's Third-Party Risk Manager (TPRM, GA) is built for the software part of this work: request, validate and monitor what suppliers ship you. The steps below follow Safeguard's TPRM and Portal documentation. Where the docs do not show a screen, we describe the outcome rather than invent one.

1. Build the vendor directory

In TPRM, open Vendors, click Add Vendor, enter the company name, primary contact, contact email, website, products used and risk tier, then Save. The docs also describe a bulk import from a template CSV. Each record tracks contract status, risk tier, SBOM status (received, requested, none) and last assessment, and can record related parties such as resellers and implementation partners, which is where you note that a platform reaches you through a reseller or a separate host.

2. Tier the vendor and document the reason

TPRM can suggest a risk tier based on data access level, system criticality, user count and compliance requirements. You can override it: select the vendor, click Edit Risk Tier, choose the tier, and document the justification. That justification field is the record an examiner will want to see.

Safeguard's docs describe a default SBOM expectation per tier: required with quarterly updates for Critical vendors (core business operations), required with annual updates for High (significant data access), recommended for Medium and optional for Low. These are defaults, not rules; set your own to match your policy.

3. Link contracts and SLA terms

TPRM's contract management links contract documents, start and end dates, SLA terms, security requirements and SBOM obligations to the vendor. Put the notice clauses and remediation targets from your contract here, so monitoring alerts can be read against what the vendor promised.

4. Request SBOMs, one vendor or many

For a single vendor, go to the vendor, click Request SBOM, select the products, choose a request template, optionally customise the message, set a deadline and click Send. For several, go to Vendors, select them, click Bulk Request, configure the settings, then review and send.

The standard template asks for SPDX or CycloneDX, lists required fields, and includes submission instructions and the deadline. You can build your own under Settings › Request Templates with Create Template, which is where to add your credit union's specifics, such as scope (member-facing services) and refresh expectations.

5. Track responses and let follow-ups run

Each request moves through statuses: Sent, Viewed, In Progress, Submitted, then Validated or Rejected. The docs describe automated reminders seven days before the deadline, at the deadline, and an escalation seven days after. Vendors can submit by email attachment or through a secure upload portal, and can also use TPRM's self-service vendor portal to update their information, submit SBOMs, respond to questionnaires and view their risk status.

6. Validate what arrives

When an SBOM arrives, Safeguard checks that it is valid SPDX or CycloneDX, checks completeness against required fields, checks it against the EO 14028 field expectations in the template, runs a vulnerability scan, and notifies the requester. If it falls short, review the validation failures, click Request Revision, specify the corrections, and the vendor receives the request.

Be clear about what validation means. It checks the file. It does not check that the file accurately describes the software the vendor actually built and deployed.

7. Review the SBOM in Portal

Portal's Find & Review SBOMs (GA) is where you read what arrived. Go to Portal › Find SBOMs and search by product, supplier, component or version. An SBOM opens with a summary, EO 14028 and NTIA element status, and tabs for Components (versions, package URLs, supplier data), Vulnerabilities (severity, CVSS, fix availability, exploitation status), Licenses and Quality (completeness score and missing fields).

Compare Versions shows added and removed components, version changes, and new and fixed CVEs between releases: the fastest way to see what a vendor upgrade changed before you accept it. Link to TPRM attaches the SBOM to the vendor profile, and Subscribe notifies you of new versions and vulnerability updates. Portal is also the name of Safeguard's free entry tier; here we mean the SBOM review surface. That docs page says its /v1 REST endpoints are not yet available, so use the in-app flow.

8. Read the vendor risk score

Each vendor gets a score from 0 to 100, where higher is better: 0 to 25 Critical, 26 to 50 High, 51 to 75 Medium, 76 to 100 Low risk. The docs list vulnerability risk (critical and high counts, EPSS, known exploited vulnerabilities), compliance risk (required fields present, SBOM age, format validity), component risk (abandoned packages, license compliance, dependency depth) and operational risk (response time, update frequency, incident history, contract compliance). Generate Report produces an executive summary, score breakdown, vulnerability details, compliance gaps and recommendations for the vendor file.

Two cautions. An incomplete SBOM can make a vendor look better than it is. And component risk scores elsewhere in Safeguard run the other way, so keep them out of the same report.

9. Record risk acceptance and remediation

When you decide to live with a finding for now, the Accept Risk flow asks for a business justification and a review date and routes it for the approvals you require. Remediation tracking records requested fixes, vendor commitments, progress updates and verification status. Together these give you a dated record of the conversation with the vendor, which is what 07-01's monitoring and control section expects.

10. Turn on monitoring alerts

Under Settings › Monitoring, configure alerts:

Alerts go to email, Slack, Microsoft Teams, PagerDuty or a webhook. Re-analysis can run daily (the docs suggest this for critical vendors), weekly, monthly or quarterly, and re-assessment can trigger on new disclosures, major version updates, contract renewals and security incidents.

11. Report to management and the board

Scheduled reports include a weekly summary, monthly vendor review, quarterly risk assessment and an annual vendor audit, exportable as PDF or Excel. The vendor dashboard shows aggregate risk, vendors needing attention, recent score changes and upcoming SBOM expirations. These feed the Appendix A III.F annual board report; they do not write it.

12. Map evidence in the compliance suite

The compliance and GRC suite (GA) has GLBA and FFIEC framework pages and a CISA KEV framework whose scan requirement is that no components match the KEV catalog. Two caveats for credit unions: the GLBA page maps to the FTC Safeguards Rule (16 CFR 314), not NCUA's Part 748 Appendix A, and the FFIEC page follows the domains of the retired CAT. Use them to organise evidence, but map your controls to Part 748 and to ACET or NIST CSF 2.0 yourself.

13. Ask questions in plain language

Safeguard's MCP server (GA) lets an assistant such as Claude query your Safeguard data, for example "which vendor SBOMs contain a KEV-listed component?" Safeguard is listed in Claude's connector directory as a community connector. A new workspace starts with a small read-only set of tools, and an administrator turns on the rest per tool, which suits a credit union that wants analysts to read findings without changing anything.

What each obligation maps to

What still sits with the credit union

• The contract: notice periods, audit and termination rights, subcontractor terms and SBOM obligations, reviewed by counsel.
• Your own controls under Appendix A III.C around the vendor's product.
• The risk appetite: whether a vendor with a slipping record is acceptable is the board's call.
• Non-software evidence: financial condition, insurance, continuity, SOC reports and staffing.
• The incident call: whether something is reportable under 748.1(c), and when the clock started.
• Your own code: member apps and integrations you build need their own inventory and scanning.

What Safeguard does not do

• It cannot make a vendor respond. TPRM sends requests, reminders and escalations. A vendor that ignores them leaves a gap only the contract, the renewal or your board can close.
• Validation checks the file, not the vendor's build. Safeguard validates format and completeness and scans the components listed. It does not confirm that the SBOM matches the binaries the vendor actually deployed for you.
• The risk score is a prioritisation aid, not an examination finding. It reflects what vendors submit and what public vulnerability data says. It is not an NCUA rating, and it should not be presented to an examiner as one.
• It does not examine the vendor's non-software controls. Physical security, staffing, financial health, business continuity and data center operations need SOC reports, audits and your own review.
• It does not interpret regulation for you. The GLBA framework page maps to the FTC Safeguards Rule rather than Part 748, and the FFIEC page follows the retired CAT. Statements about what NCUA requires must come from NCUA's text and your counsel.
• It does not report incidents to NCUA. Alerts can tell you a vendor component has a KEV-listed vulnerability. Deciding whether an incident is reportable, and reporting it, stays with you.
• It holds no banking certification. Safeguard is not certified by NCUA, the FFIEC or any banking body, and its own SOC 2 Type II audit is in progress, not complete.

Common mistakes

• Treating the SOC report as the software review. It describes controls over a period, not the components in the product or last week's vulnerability.
• Accepting a one-time SBOM. Tie refresh to releases.
• Notice clauses in business days. With a 72-hour clock that can start at the vendor's notice, the vendor must be faster than you.
• Leaving supply chain compromise out of the incident definition. NCUA's rule names it; your contract should too.
• Tiering by spend. A cheap vendor with member data access is still high risk.
• Citing the FFIEC CAT as current. It was sunset on August 31, 2025.
• Treating the interagency guidance as binding. It is a reference for credit unions; say so if you borrow from it.
• Not recording refusals. If it is not in the file, an examiner will assume it did not happen.

FAQ

Does NCUA require credit unions to get an SBOM from vendors?

No NCUA regulation names SBOMs. Part 748 Appendix A requires due diligence, contract safeguards and risk-based monitoring of service providers, including review of audits, test summaries or equivalent evaluations. An SBOM with vulnerability analysis is a practical way to meet that monitoring expectation for software, and many credit unions now ask for one in contracts.

Does the 2023 interagency third-party guidance apply to credit unions?

No. It was issued by the Federal Reserve, the FDIC and the OCC, and NCUA did not join. Credit unions follow Part 748 and NCUA letters such as 07-CU-13. The interagency guidance is still a useful reference for what software due diligence can cover.

What is NCUA's 72-hour cyber incident rule?

12 CFR 748.1(c), effective September 1, 2023, requires a federally insured credit union to notify NCUA of a reportable cyber incident within 72 hours of reasonably believing it occurred. Incidents caused by a compromise of a CUSO, cloud provider, third-party data host or the supply chain are covered, and the clock can start when a third party notifies you.

Does a vendor's breach count toward the credit union's 72 hours?

It can. The rule covers disruptions or unauthorized access facilitated through or caused by a third party's compromise, and allows the 72 hours to run from when the third party notifies the credit union, whichever is sooner. That is why vendor notice terms matter.

Is NCUA Letter 07-CU-13 still current?

NCUA's page shows it without any archived or superseded notice, and NCUA's 2026 supervisory priorities letter lists it as a resource for outsourced lending. Its enclosure, Supervisory Letter 07-01, still describes the structure examiners expect.

What replaced the FFIEC Cybersecurity Assessment Tool for credit unions?

The FFIEC sunset the CAT on August 31, 2025 and pointed institutions to NIST CSF 2.0 and CISA's Cybersecurity Performance Goals. NCUA continues to offer its voluntary Automated Cybersecurity Evaluation Toolbox (ACET).

Can NCUA examine a credit union's technology vendors directly?

Not generally. GAO recommended in 2015 that Congress give NCUA authority to examine technology service providers. GAO lists the recommendation as open, with no further action on the related bills as of February 2026. Oversight therefore runs through the credit union.

What if a digital banking vendor refuses to provide an SBOM?

Offer a narrower or NDA-protected request, ask for a written attestation that no KEV-listed vulnerabilities affect your version, push SBOM delivery into the renewal, and document the refusal and compensating controls. Escalate to the board for critical vendors.

Can Safeguard show which of our vendors are affected by a newly exploited vulnerability?

For vendors that have sent SBOMs, yes. TPRM monitoring raises an alert when a CVE in a vendor SBOM is added to CISA's KEV catalog, and Portal shows exploitation status per component. For vendors that have not sent an SBOM, Safeguard has nothing to match against.

Most of what a credit union finds in a vendor's SBOM is the vendor's to fix, and the limit at the end of the next section says so plainly. The tools in it apply to the software the credit union builds or packages itself, such as member apps and integrations, and to conversations where you can point a vendor at a known safe version.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real session in the Safeguard desktop app. The CLI session appears in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with a dependency upgrade done and tests passing. For a credit union, the same flow fits the in-house code around a vendor platform, such as integrations and member apps, with an engineer approving every change.

Click through it at your own pace, or open it full screen.

The second demo connects Claude to the Safeguard MCP server with OAuth and shows how to choose which tools Claude can use. For a vendor management team, that is how an analyst can ask plain-language questions of TPRM and SBOM data while an administrator keeps the tool set read-only.

Click through it at your own pace, or open it full screen.

To try it with your own vendors, download the app and CLI at https://safeguard.sh/download and read the setup guides at https://docs.safeguard.sh/docs .

Quick check

Sources

• eCFR: 12 CFR Part 748, Security Program, Report of Suspected Crimes, Suspicious Transactions, Catastrophic Acts, Cyber Incidents, and Bank Secrecy Act Compliance
• NCUA Board Action Bulletin: final rule on cyber incident reporting requirements (February 2023)
• NCUA: Cyber Incident Reporting
• NCUA Letter 25-CU-02: Cyber Incident Notification Requirements, Update to Letter 23-CU-07
• NCUA Letter 07-CU-13: Evaluating Third Party Relationships
• NCUA Supervisory Letter 07-01: Evaluating Third Party Relationships (enclosure, PDF)
• NCUA Letter 01-CU-20: Due Diligence Over Third Party Service Providers
• NCUA Letter 26-CU-01: NCUA's 2026 Supervisory Priorities
• NCUA Cybersecurity Resources
• NCUA: ACET and Other Assessment Tools
• OCC Bulletin 2024-25: FFIEC Cybersecurity Assessment Tool sunset
• FFIEC IT Examination Handbook: Outsourcing Technology Services (archived copy, March 2026)
• Interagency Guidance on Third-Party Relationships: Risk Management, 88 FR 37920 (GovInfo)
• GAO-15-509: Cybersecurity, Bank and Other Depository Regulators Need Better Data Analytics
• CISA Known Exploited Vulnerabilities Catalog
• CISA Cybersecurity Directives (BOD 26-04)
• FIRST: Exploit Prediction Scoring System
• NIST SP 800-218, Secure Software Development Framework
• CISA: Updated Minimum Elements for a Software Bill of Materials (announcement, 29 July 2026)
• Safeguard docs: Third Party Risk Manager
• Safeguard docs: TPRM Vendor Management
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: TPRM Risk Assessment
• Safeguard docs: TPRM Monitoring
• Safeguard docs: Portal Find & Review SBOMs
• Safeguard docs: GLBA framework
• Safeguard docs: FFIEC framework
• Safeguard docs: CISA KEV framework
• Safeguard docs: Desktop Application
• Safeguard docs: Claude MCP connector
• Safeguard Gold Open Source

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.