BAE Systems Incident Takes the Bankruptcy Noticing Center Offline

A security incident at BAE Systems, the contractor that runs the federal judiciary's Bankruptcy Noticing Center (BNC), has stopped bankruptcy notices from going out nationwide since about 9 October 2026. Courts still accept filings, but parties may need to serve notices themselves. Check your district's general order, verify service, and review your own single-vendor dependencies.

This post covers what the Administrative Office of the US Courts and individual bankruptcy courts have said, which systems are down, how courts are working around the gap, and what the episode teaches any organization that hands a critical function to one contractor. It sticks to official statements. Neither the judiciary nor BAE Systems has said what caused the incident or whether any data was accessed, and we do not guess.

What happened

The Bankruptcy Noticing Center is the service that turns court notices into mail and electronic messages. When a bankruptcy court dockets a notice of a new case, a meeting of creditors, a discharge or a dismissal, the BNC produces it and sends it to creditors and other parties who are not registered users of the courts' electronic filing system. According to the judiciary's own program page, entities can choose electronic or paper delivery and manage that preference on the BNC website.

On 15 October 2026 the Administrative Office of the US Courts (AO) published a notice titled "Cybersecurity Incident Disrupting Bankruptcy Court Operations." It said a cybersecurity incident had affected BAE Systems IT and the websites that support BNC operations, which BAE runs on behalf of the federal judiciary. The AO named four affected properties: bnc.uscourts.gov, bankruptcynotices.uscourts.gov, notices.uscourts.gov and the National Creditor Registration Service. It said access to those systems was unavailable and that the incident had halted the production and distribution of bankruptcy notices. It said BAE was "actively investigating this incident and working to restore operations."

Individual courts had already been posting notices for two days by then. The Southern District of California posted on Tuesday 13 October that a nationwide BNC outage had started on Friday 9 October and that paper and electronic notices had not been delivered since. Those early notices described a "service interruption" or "service outage" and did not mention a cyber incident, which CyberScoop also noted in its coverage.

BAE Systems responded to reporters on 15 and 16 October. A spokesperson told The Record that the company was aware of a security incident "isolated to the BNC system" and had taken immediate steps to address it. CyberScoop and BleepingComputer published the same statement, and CyberScoop added the line that no other systems had been affected.

As of 22 October, no court notice we read gives a restoration date. The Southern District of Indiana's FAQ, dated 16 October, says plainly that a definitive timeline is unknown. The District of Maine issued a detailed general order on Wednesday 21 October because, in its words, the duration of the interruption is unknown. When we tried to load bnc.uscourts.gov on 22 October, the hostname did not resolve from our network. That is a single point in time observation, not an official status.

Timeline

No primary source we found publishes times of day for any of these events. The table below gives dates and the source for each. Where courts disagree on when the disruption began, all versions are listed.

One reporting inconsistency is worth flagging. Security Affairs' article says notices have been down "since last Thursday," which does not match a 9 October start, because 9 October 2026 was a Friday. N.D. Florida's "on or about 8 October" is a Thursday. The courts themselves do not agree to the day, which is normal for an outage that was first noticed downstream.

What the official statements say, and what they do not

This is the part to read carefully before repeating anything about this incident.

The Record adds that CISA referred its questions to the US Courts and that the FBI did not respond. Treat every claim you see elsewhere about ransomware gangs, stolen Social Security numbers or attacker identity as unverified unless it comes from the AO, a court or BAE.

Technical details

There is no CVE, software version, file hash or indicator of compromise in any official statement about this incident. The AO and BAE have not published any. Anything presented as an IOC list for the BNC outage did not come from them. What the primary sources do give is a precise picture of which services stopped, which kept running, and how the courts' noticing pipeline is built. That is the defender-useful detail here.

Affected and unaffected services

How the noticing pipeline is described

Putting the court notices together gives a fairly clear data flow, without any guesswork about BAE's internals:

1. A court enters a notice or order in CM/ECF. It appears on the docket immediately.
2. Registered CM/ECF users get a Notice of Electronic Filing by email directly from CM/ECF. This path does not touch the BNC and is still working.
3. For everyone else, the court's notice is handed to the BNC. Security Affairs, citing E.D. Texas, reports that this court polling and certification hand-off process has been interrupted.
4. The BNC looks up each recipient's preferred address and channel, using NCRS registrations and EBN or DeBN accounts, then prints and mails or sends electronically.
5. The BNC returns a certificate of notice, which courts treat as proof of service. A 2025 notice from the W.D. Washington bankruptcy court, about an unrelated Canada Post mail disruption, shows that BNC certificates of notice also mark undeliverable addresses.

Step 4 is why NCRS being down matters beyond the BNC itself. Attorneys normally pull an accurate mailing matrix from CM/ECF that reflects NCRS preferred addresses. With NCRS offline, the list they can get from CM/ECF may not include those preferred addresses, and S.D. Georgia warns that it may not include EBN registrations either.

Rules and forms named in the court orders

Court orders issued so far

The spread of approaches is itself a finding. Within two weeks, courts ranged from no district-wide order at all to a five-page order that shifts most noticing duties onto the parties. A practitioner who files in several districts has to track each one separately.

Who is affected

Every district depends on the BNC, so the AO describes the halt as affecting noticing for bankruptcy courts nationwide. We did not find an official count of how many districts have posted notices or orders.

How it works, in plain language

Think of the BNC as the courts' outbound mail room, run by a contractor. The courts write the letters. The contractor knows everyone's preferred address, prints, mails, emails and returns a receipt. When the mail room closed, three things broke at once.

First, letters stopped going out. That is the obvious part. Bankruptcy runs on notice. A creditor who never hears about a case, a 341 meeting date or a claims deadline may later ask the court for relief, and a court cannot treat a deadline as having run against someone who was never properly served. The S.D. Indiana FAQ makes this point directly: a notice appearing on the docket does not by itself prove that service through the BNC happened.

Second, the address book closed. NCRS and EBN registrations live with the BNC. Attorneys who would normally pull a complete mailing matrix from CM/ECF now get a partial list. Courts tell them to add debtors, trustees, the US Trustee and other parties by hand, because those are not on the creditor query.

Third, the receipts stopped. Courts rely on BNC certificates of notice as proof of service. Without them, every party that steps in to serve must file its own certificate of service. Maine and Indiana both require it.

Meanwhile the parts of the system that do not depend on the contractor kept working. CM/ECF accepts filings, dockets update, and registered attorneys still get electronic notices. That split is the clearest real-world map you will see of where one vendor's boundary sits inside a public process.

What changed since first reports

The story moved in three steps, each documented by primary sources.

13 to 14 October: an outage, cause unstated. Court notices called it a nationwide service outage or interruption and gave workarounds for the creditor list. CyberScoop noted that the Southern District of Florida's notice did not mention cyber activity.

15 to 16 October: a named cybersecurity incident. The AO's notice was the first official statement to call it a cybersecurity incident and to name BAE Systems IT. BAE's statement followed, saying the incident was isolated to the BNC system. Orders from Connecticut and New York appeared, mostly opening the door to deadline relief.

21 October: planning for a long outage. Maine's order explicitly says the duration is unknown and builds temporary procedures that move service duties to debtors, trustees and movants for as long as the order is in effect. That is a shift from "ask us for relief" toward "serve it yourself," and it signals that courts are no longer assuming a quick fix.

What has not changed: there is still no statement on cause, no statement on data, and no restoration date.

What to do now

The steps split by role. If you practice bankruptcy law or collect debts, the first two lists matter most. If you run IT, security or procurement anywhere, the third list is the point of this post.

If you file or appear in bankruptcy cases

1. Read your district's order. Go to your court's website news page and its general or administrative orders page. Requirements differ widely: Maine moves service to parties, Indiana permits it, North Carolina Western handles it case by case.
2. Assume nothing was served through the BNC since about 6 to 9 October. Maine's order says parties shall not presume a document sent to the BNC was delivered. Check each case docketed since then.
3. Pull the creditor list manually from CM/ECF. The courts' published steps are: choose Query from the top menu, enter the case number, Run Query, choose Creditor, leave Creditor type blank, Run Query again. Choose Party for party addresses.
4. Add the parties the creditor query leaves out. Debtors, trustees, the US Trustee and, where required, the US Attorney are not on that list, according to E.D. Texas and Maine.
5. Account for preferred addresses you cannot see. S.D. Georgia warns the CM/ECF list may not reflect NCRS or EBN registrations. Where you know a creditor's preferred notice address from prior cases, consider serving both.
6. File a certificate of service every time. List documents, recipients, addresses or electronic destinations, date and method.
7. For 341 notices, request copies if you need them. S.D. Georgia accepts requests at copy_requests@gas.uscourts.gov, in person, or by mail with a stamped return envelope, for cases filed after 7 October.
8. Ask for relief early if you cannot serve in time. Connecticut and Maine both expect a motion that names the affected notice and the relief sought. Filing a motion does not by itself extend a deadline.

If you are a creditor or servicer that relies on BNC notices

1. Stop treating silence as "no new cases." If your intake depends on EBN files or BNC mail, you are not seeing new filings involving your accounts. Search PACER or monitor dockets for your key accounts.
2. Check when your last EBN delivery arrived. If you ingest EBN notices automatically, look at the newest file timestamp in your landing directory. A command like the one below shows the ten newest files:

# Show the 10 most recent files, newest first, in your EBN landing folder (adjust the path)
ls -lt /data/ebn/inbound | head -n 11

3. Add an alert for a stalled feed. A feed that stops is a signal. A simple check that fails when nothing has arrived in 48 hours:

#!/usr/bin/env bash
# Alert if no file has landed in the inbound folder in the last 48 hours
DIR=/data/ebn/inbound
if [ -z "$(find "$DIR" -type f -mmin -2880 -print -quit)" ]; then
  echo "ALERT: no notices received in 48h in $DIR" >&2
  exit 1
fi

4. Be careful with "service restored" messages. Nothing in official sources reports phishing tied to this outage. As a general precaution, though, outages that affect many organizations attract lookalike emails. Verify restoration on uscourts.gov or your court's own site, not from a link in an email. You can inspect a suspicious message's authentication results in its raw headers:

# Save the raw message as message.eml, then look at the authentication results
grep -iE "^(authentication-results|received-spf|dkim-signature|from):" message.eml

If you run IT, security or vendor management anywhere

This is a third-party and contractor risk story. The questions it raises apply to any organization with a service it does not run itself.

1. List services where one vendor is the only path. For each, write down what stops if the vendor goes dark for two weeks, and who finds out first.
2. Find where vendor hostnames are wired into your code and config. That gives you a factual dependency list instead of a guess:

# Find every reference to a vendor-run domain in your repositories (example domain)
grep -rhoE "[a-z0-9.-]+\.vendor-example\.com" --include="*.yaml" --include="*.yml" --include="*.json" --include="*.env" --include="*.tf" --include="*.py" --include="*.js" --include="*.ts" . | sort -u

# Same idea with ripgrep, across all text files
rg -o --no-filename "[a-z0-9.-]+\.vendor-example\.com" | sort | uniq -c | sort -rn

3. Add synthetic checks on vendor endpoints you depend on. Check DNS and HTTPS separately, since a vendor outage can show up as either:

# DNS: does the vendor hostname still resolve?
dig +short service.vendor-example.com

# HTTPS: status code and total time, with a 10 second cap
curl -s -o /dev/null -w "%{http_code} %{time_total}\n" --max-time 10 https://service.vendor-example.com/health

On Windows, the equivalents are:

Resolve-DnsName service.vendor-example.com
Invoke-WebRequest -Uri https://service.vendor-example.com/health -Method Head -TimeoutSec 10 | Select-Object StatusCode

4. Check your contract's incident notification clause. How many hours does the vendor have to tell you, and does "tell you" include what systems and what data? Compare that with how long it took you to learn about the last vendor outage.
5. Write the manual fallback down before you need it. The courts' CM/ECF creditor query is a fallback that already existed. Know what yours is, who runs it, and how long it can last.
6. Plan the restoration, not just the outage. Indiana and Maine both plan to reconcile the backlog when the BNC returns so nobody gets duplicate or stale notices. Your playbook should cover replay, deduplication and stale data.

Third-party and contractor risk: the lessons

None of these lessons assumes anything about why the incident happened. They follow from the public facts about how the service is structured and how the outage played out.

Concentration risk is real even when the vendor is large and capable. BAE Systems is described by The Record as one of the world's largest defense contractors and by BleepingComputer as a major provider of IT and cybersecurity services to government. Size and reputation do not remove single points of failure. They only make it easier to forget they exist.

The blast radius was defined by architecture, and part of it held. CM/ECF filing and electronic notices kept working. BAE says the incident is isolated to the BNC system. That separation is the reason courts can still function. If your vendor's system shares identity, network or data paths with your core platform, a vendor incident becomes your incident.

Downstream users noticed before the public statement. Courts posted outage notices on 13 October. The AO's cyber statement came on 15 October. For a multi-tenant service, the people affected first are often the ones furthest from the vendor. Make sure your own monitoring would catch a vendor outage before your customers report it.

Fallbacks need to be complete, not just available. The manual CM/ECF query works, but it leaves out NCRS and EBN preferred addresses. A fallback that silently drops data creates legal and operational risk of its own. Test your fallback for completeness, not only for whether it runs.

Governance has to scale across many dependents. The nine courts we checked issued different guidance in the first two weeks. If one of your vendors serves many of your business units, decide in advance who issues the single instruction to all of them.

Restoration is a project. When noticing returns, courts must decide what to replay, what to suppress and what to correct. Data that sat in a queue for weeks may carry dates and deadlines that have passed.

For a related pattern in a different sector, see our post on IDCF Cloud ransomware and third-party risk, and our roundup of October 2026 security incidents and what would have helped.

Open questions

These are unanswered in every primary source we read as of 22 October:

1. What caused the incident? No cause has been published by the AO or BAE.
2. Was any data accessed? BNC notices can include names, addresses and partial taxpayer IDs, and NCRS holds creditor address preferences. Neither the AO nor BAE has said whether any data was accessed. Do not assume either way.
3. When exactly did it start? Courts cite 6, 8 and 9 October.
4. When will service return? No date has been given.
5. How will the backlog be handled? Courts say they will coordinate, but no national procedure has been published.
6. Will the AO publish a post-incident report? Nothing has been announced.

What would have helped

We cannot say what would have prevented this incident, because no one has said what it was. What we can describe is what reduces the impact of any contractor outage on the organizations that depend on it.

Practices any team can use

• Tier vendors by operational criticality, not only by data sensitivity. A vendor that holds little sensitive data but sits on a path every customer depends on is a tier one vendor.
• Map sole-source dependencies. For each critical function, record whether a second provider or an in-house path exists. The BNC case shows what "no second path" looks like.
• Contract for notification and transparency. Set an incident notification window measured in hours, with a requirement to state affected systems, whether data is involved once known, and a restoration estimate with regular updates.
• Agree a recovery time objective and test it. Ask for evidence of restoration drills, and run a tabletop where the vendor goes dark for 14 days.
• Keep a minimal copy of what you need to operate. If your process depends on a vendor's address book, keep a current export under your control so the fallback is complete.
• Monitor vendor endpoints from your side. Synthetic checks on DNS and HTTPS for each critical vendor service, with alerts routed to the business owner.
• Segment vendor-run systems from your core. The fact that CM/ECF kept working is the best argument for keeping a contractor's platform behind its own boundary.
• Pre-write the communication. Templates for "vendor outage, here is what still works, here is what to do" save days.

Where Safeguard fits

Safeguard's fit here is indirect, and we want to be plain about it. Nothing in Safeguard would have prevented an incident inside a contractor's own systems, detected it, or restored the BNC. Safeguard does not run anyone's noticing service and has no visibility into BAE's environment. What Safeguard does is help organizations manage the third-party and software supply chain risk they carry.

• Third-Party Risk Manager (GA) gives you a vendor directory with contracts, SLAs and risk tiers, so a sole-source operational vendor can be marked critical and its notification terms tracked next to it. It scores each vendor from 0 to 100, where higher is better, across vulnerability, compliance, component and operational risk, using EPSS and CISA KEV data. Continuous monitoring sends alerts for new critical vulnerabilities, KEV additions, risk changes and SBOM expiry to email, Slack, Teams, PagerDuty or a webhook.
• SBOM requests (GA) let you ask a vendor for an SBOM of the software they deliver, track the request through Sent, Viewed, In Progress, Submitted and Validated or Rejected, and follow up automatically. When a vulnerability lands in a component your vendor ships, you can see which vendors and products carry it. That would not have told anyone about the BNC incident, which has no published software cause, but it is the right habit for every vendor that delivers software to you.
• SBOM generation and dependency scanning (GA) cover the software you build yourself: repositories, container images and SBOM files, with vulnerability matching and reachability analysis. The CLI runs safeguard scan --dir ., safeguard scan --image <name> or safeguard scan --sbom <file> and writes JSON results under ./output.
• Compliance suite (GA) includes Vendors, Risks and Questionnaires tabs, so vendor assessments and the risks they create live with the rest of your compliance evidence.

Where Safeguard does not help: a contractor's internal incident, a hosted service's availability, legal service obligations, and anything that depends on what BAE and the AO have not disclosed.

Zero-Day Discovery and Gold

Two Safeguard capabilities come up in every incident post, so here is how they relate to this one. In short, they do not apply directly, because no software vulnerability has been named.

• Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists, in two modes, an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases, and it covers seven package ecosystems.
• Gold Open Source at gold.safeguard.sh is free and needs no login. It offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, a free read API, and a CI gate GitHub Action.
• Gold Registry at registry.safeguard.sh is paid. It provides hardened drop-in components and container images held to zero exploitable critical or high CVEs, with SLSA L3 or higher provenance and Sigstore signatures, and evidence pages. An artifact loses the badge if it regresses.

If a vendor later discloses that a specific component was involved, those tools become useful for checking whether you run the same component. Until then, the honest answer is that this incident is about vendor dependency, not a package you can patch.

Common mistakes

• Repeating unverified claims about data theft. No official source says data was taken. No official source says it was not. Say "not disclosed."
• Assuming the docket proves service. S.D. Indiana says the entry of a notice on the docket does not by itself establish that BNC service happened.
• Using only the CM/ECF creditor list. It leaves out debtors, trustees, the US Trustee and possibly NCRS and EBN preferred addresses.
• Assuming one district's order applies everywhere. Requirements range from no order to mandatory party service.
• Assuming deadlines are extended. Maine's order says it does not extend any deadline. Connecticut lets the court extend on request. Read the order.
• Forgetting the restoration step. When the BNC returns, queued notices may carry stale dates. Courts plan to reconcile; your office should too.
• Treating a vendor's size as a control. Large contractors have outages too. Plan for it in contracts and runbooks.
• Monitoring only your own systems. A dependency that goes quiet looks like "no news." Alert on silence.

FAQ

What is the Bankruptcy Noticing Center?

It is the service that produces and delivers court notices in bankruptcy cases to creditors and other parties who are not registered CM/ECF users. It also maintains preferred creditor addresses. BAE Systems operates it for the federal judiciary, according to the AO and several courts.

What exactly is down?

The AO names bnc.uscourts.gov, bankruptcynotices.uscourts.gov, notices.uscourts.gov and the National Creditor Registration Service. Production and distribution of notices, paper and electronic, has stopped. W.D. North Carolina adds that Debtor Electronic Bankruptcy Noticing is down.

Can I still file a bankruptcy case?

Yes. Courts say they continue to accept filings, open cases and process documents, and that CM/ECF and Notices of Electronic Filing work normally.

Was my personal data stolen?

Neither the AO nor BAE has said whether any data was accessed or taken. The Record reports that the AO did not respond to questions on that point. If that changes, it will come from the AO, a court or BAE. Be wary of any message claiming otherwise that does not link to one of them.

Was this ransomware?

No official source says so, and no ransomware group claim appears in the coverage we read. The AO calls it a cybersecurity incident; BAE calls it a security incident.

When did the outage start?

Courts give different dates: Connecticut says it may have begun as early as 6 October, N.D. Florida says on or about 8 October, and S.D. California and E.D. Texas say 9 October.

Who has to send the 341 meeting notice now?

It depends on the district. In Maine, debtors in voluntary cases filed on or after 7 October must serve it, except individual chapter 7 debtors without a lawyer, for whom the clerk serves it. In Indiana, parties may elect to serve. In other districts, the court is mailing manually or deciding case by case.

What happens to 341 meetings?

S.D. Indiana says trustees will convene meetings as scheduled, decide whether proper notice was given, and adjourn rather than conclude the meeting if it was not. Trustees may still conduct limited examinations to protect the estate.

When will the BNC come back?

No date has been published. S.D. Indiana says a definitive timeline is unknown, and Maine's 21 October order was written because the duration is unknown.

What should non-court organizations take from this?

Find your own single-vendor dependencies, measure how long you could run without each, write the fallback down, test whether it is complete, and put incident notification terms in the contract. Our post on using SBOMs to find affected products fast covers the software side of the same discipline.

Fix it without waiting for upstream

This incident has no published software flaw to patch, so the steps below are not a fix for the BNC outage. They are the remediation habits that matter when a vendor or open source incident does name a component you also run, and they are the part of supply chain risk you control directly.

In incidents like this one, 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 covers eight categories, including dependencies, licenses, security posture and findings. 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. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

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

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature 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. This fork and patch flow is in early access today, so 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 have helped

None of these demos shows the BNC incident, and Safeguard could not have restored a contractor's service. They show the everyday tooling for the part of third-party risk you do control: knowing what software and vendors you depend on, and acting quickly when one of them has a problem. You can try Safeguard from safeguard.sh/download, and the CLI is documented at docs.safeguard.sh/docs/cli.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which Safeguard tools Claude can use. For a vendor outage like this one, that is the setup you would use to ask an assistant questions about your own projects and findings during an incident, with you deciding which tools it may call.

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

This demo is a real CLI session: it installs the CLI, opens the interactive terminal, asks it to fix a lodash CVE, and approves each command as it edits package.json to lodash 4.17.21 and runs npm install and npm test, pushing nothing. If a vendor ever does disclose a vulnerable component behind an outage, this is the same flow you would use to check your own repositories for that component with /scan . and bump it with approval at each step.

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

This demo is a real desktop app session: 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, ending with the upgrade done and tests passing. During an incident, it lets a security lead hand work to an engineer's machine and keep a human decision on every change, which is the same control you would want over any automated response.

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

Quick check

Sources

• Administrative Office of the US Courts: Cybersecurity Incident Disrupting Bankruptcy Court Operations (15 Oct 2026)
• US Courts: Bankruptcy Noticing program page
• US Bankruptcy Court, S.D. Indiana: BNC Service Interruption Update and FAQs as of 16 Oct 2026
• S.D. Indiana FAQ (PDF)
• US Bankruptcy Court, D. Maine: General Order 26-01 (PDF, 21 Oct 2026)
• US Bankruptcy Court, D. Maine: General Order announcement
• US Bankruptcy Court, D. Connecticut: General Order 2026-02 (PDF, 16 Oct 2026)
• US Bankruptcy Court, S.D. Georgia: BNC nationwide service disruption
• US Bankruptcy Court, E.D. Texas: BNC Service Interruption Update
• US Bankruptcy Court, N.D. Florida: Administrative Order 26-003
• US Bankruptcy Court, S.D. California: BNC Service Outage
• US Bankruptcy Court, E.D. New York: Administrative Order 844
• US Bankruptcy Court, W.D. North Carolina
• US Bankruptcy Court, W.D. Washington: BNC delivery to Canada (2025, background on certificates of notice)
• The Record: Federal bankruptcy courts dealing with outages after contractor cyberattack
• CyberScoop: BAE Systems incident halts federal bankruptcy notices
• BleepingComputer: BAE Systems cyberattack disrupts US federal court operations
• Security Affairs: BAE Systems cyber incident takes US Bankruptcy Noticing Center offline for a week
• Infosecurity Magazine: Cyber incident at BAE Systems disrupts US federal bankruptcy noticing

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.