ETS Breach: One SFTP Login Exposed California Student Records

Between 22 May and 18 September 2026, someone used a compromised login to copy California student files from an SFTP site run by Educational Testing Service (ETS), the state's testing contractor. Current and former public school students are affected. Families should enroll in the free Experian protection; teams running file transfer should require MFA and allowlists.

The official notice is short and careful. It names the system (an SFTP site used to exchange statewide assessment information with the California Department of Education), the access window, the data fields and the response. It does not name an attacker, say how the credential was compromised or give a victim count, and this post does not fill those gaps.

What it does show is a pattern that every organisation which exchanges files with a vendor should recognise. A single valid account on a file transfer server, used quietly and intermittently, can pull very large datasets for months. This post covers what the notice says, what is still unknown, the specific steps families and schools can take, and a detailed hardening and detection guide for SFTP servers that hold regulated data.

What happened

Timeline

Some quick arithmetic from those dates. The access window runs 120 days counting both ends. Discovery came 7 days after the last recorded access and 126 days after the first. Public notice came 21 days after discovery. None of those figures says anything about how the access was found; the notice does not explain that.

What the notice says

The notice we read is the "Notice of Data Breach" that ETS filed with the California Attorney General's data breach list. Its main points:

• ETS is notifying California students and families at the direction of CDE about unauthorized access to and copying of student data from an ETS SFTP site.
• ETS is a nonprofit under contract with the State of California to provide state and federally required testing to students in California public schools, including the California Assessment of Student Performance and Progress (CAASPP) and the English Language Proficiency Assessments for California (ELPAC).
• On 25 September 2026 ETS identified unauthorized activity involving an SFTP site that ETS and CDE used to exchange statewide assessment information.
• The investigation determined that an unauthorized party used a compromised login credential at various times from 22 May to 18 September 2026 to access the site and copy files containing California student information.
• Appropriate law enforcement agencies have been notified, and their investigations have not delayed the notice.
• ETS took the SFTP site offline and built an entirely new SFTP site with enhanced security controls, and continues to evaluate additional measures.
• After working with law enforcement and cybersecurity experts, ETS says it has taken steps to reduce the potential risk of the data being made publicly accessible. Following regular web monitoring, it has not found evidence that the information has been made public.
• The California Cybersecurity Integration Center (Cal-CSIC) is assisting with digital forensics and incident response. The California Department of Technology and the Governor's Office of Emergency Services (Cal OES) are supporting the state's technical, legal and operational response.
• CDE and the State Board of Education are reviewing the incident and ETS's compliance with applicable data security and contractual requirements.

What other reporting adds

• SecurityWeek reports that ETS paused routine processing of enrollment data and suspended some testing work while it evaluated the security of its systems.
• GovTech reports that an ETS spokesperson said the organisation has added enhanced monitoring and strengthened access controls, will conduct further third-party review, and that no other ETS customers were affected.
• LAist reports that CDE is reviewing whether ETS complied with the data security requirements in its state contract, which matches the notice.
• The Spanish edition of the Malwarebytes blog summarises the notice in Spanish and repeats the advice to verify any communication through official channels.

What has not been said

As of 23 October 2026 there is no public statement on:

• who was behind the access;
• how the login credential was compromised (phishing, reuse, a stolen key, an infostealer or anything else);
• whether the account used a password, an SSH key or both, and whether multi-factor authentication was required;
• whether the account was a person's account or a service account used by an automated job;
• how many people are affected;
• whether any ransom demand was made (GovTech notes the release did not say);
• any indicators of compromise such as source IP addresses, client versions or file names.

We do not speculate on any of these. Where this post talks about how SFTP credentials get compromised in general, it is about the class of risk, not a claim about this incident.

Technical details

There is no CVE, no vulnerable software version and no published indicator of compromise in this incident. The technical facts are about the system, the access window and the data. Every value below comes from the ETS notice unless another source is named.

The system

Access window

The times of day, the number of sessions and the volume of data have not been published.

Who is in the data

The notice says information about California students was accessed and copied, and that this includes, but is not limited to, every student enrolled in the three previous school years. CDE's FAQ, as quoted by SecurityWeek and LAist, adds students who left a California school as far back as 2006 and whose transfer to another school was not confirmed with CDE.

There is no published victim count. Figures in circulation differ:

GovTech reports that the affected population exceeds the 5.7 million current students, because it reaches back to earlier enrollments and to former students. Treat any exact number as unconfirmed until ETS or CDE publishes one.

Data fields

The notice says the data varies by individual and may include:

Not included, per the notice: Social Security numbers, driver's license numbers, passport numbers, financial account information, credit or debit card information, account passwords, and parent or guardian personal information.

Some fields are sensitive well beyond identity theft: Title I Part C covers migrant education, McKinney-Vento covers students experiencing homelessness, and disability type is health adjacent. The realistic harm is targeted scams and exposure of facts families did not choose to share, more than new credit lines.

Support details from the notice

A note on the adult deadline: the notice's summary says adults can enroll on or before 19 March 2027, but one bullet in the adult attachment says "enroll by March 19, 2029." The minor section also says minors who turn 18 before 19 March 2029 can move to the adult product on their birthday. The safest reading is to enroll before 19 March 2027 and call the number above if your code is rejected. LAist also gives 19 March 2027 for both groups.

Indicators of compromise

None published. No IP addresses, user agents, SSH client strings, file names or hashes appear in the notice, the CDE materials as reported, or the press coverage we read. If you run an SFTP exchange with ETS or any testing vendor, ask the vendor directly whether it has indicators to share; do not rely on lists circulating on social media.

Why a file transfer site is such a valuable target

SFTP is old, reliable and everywhere in education, health care, payroll and finance. It is how a state agency sends an enrollment extract to a testing vendor and how the vendor sends results back. Those exchanges share some traits that make them attractive:

• Bulk by design. A file transfer drop holds whole extracts, not one record at a time. One directory listing can show years of files.
• Long lived credentials. Accounts for automated jobs often use passwords or SSH keys that never expire, because rotating them breaks a nightly job.
• Thin monitoring. Many SFTP servers log logins but not which files were read. A read of an expected file by a valid account looks normal.
• Shared ownership. The data owner (here, the state) does not run the server; the operator (the vendor) does not own the data. Each side can assume the other is watching.
• Retention drift. Files are dropped for a job and never removed, so the server becomes an archive nobody planned.

We do not know which of these, if any, applied to this incident.

Who is affected

LAist makes a point worth repeating: not receiving a letter does not mean a student's data was not involved, because addresses for former students may be out of date.

What families should do now

1. Confirm the letter is real. Check the details against the official page at cde.ca.gov/ets or call 833-931-8488. Do not use phone numbers or links in an unexpected text or email.
2. Enroll in Experian IdentityWorks before 19 March 2027. Parents enroll minors through the Minor Plus product; adults enroll themselves. No credit card is required, per the notice.
3. Consider a child credit freeze. The notice explains that freezes are free and that parents can get a free freeze for children under 16. Contact Equifax, Experian and TransUnion; numbers are in the notice.
4. Expect school themed scams. The notice warns about unexpected emails, texts and calls that reference a student's school, statewide assessments or the incident. A caller who knows the school, grade and student ID is not proof of anything.
5. Never share passwords or payment details in response to an unsolicited request.
6. Watch for fake identity protection sites. The notice asks people to double check URLs before entering information.
7. Older former students: check your own credit reports at annualcreditreport.com, which the notice also lists.

What schools and districts can do now

1. Brief front office and help desk staff that callers may use real student details to impersonate parents, staff or the state. Set a callback rule for any request to change contact details, release records or reset accounts.
2. Publish one official link (the CDE page) on your own site and in your parent communications, so families have a trusted path.
3. List every vendor file exchange. For each one, record the data elements, the direction, the frequency, the server owner and the account type.
4. Ask each vendor the questions in the vendor section below and file the answers.
5. Check your own side of the exchange. Where your district uploads files to vendors, confirm who holds the credentials, where they are stored and when they were last rotated.

Hardening an SFTP server that holds regulated data

This section is for the teams that run file transfer servers, at vendors, agencies and districts alike. It uses OpenSSH, the most common SFTP server, and quotes only behaviour documented in the OpenBSD sshd_config manual. Test every change on a non production server first; a wrong Match block can lock out every partner at once.

Step 1: Inventory accounts and how they authenticate

List every account that can reach the SFTP subsystem and how it signs in.

# Accounts in the SFTP group (adjust the group name to yours)
getent group sftpusers

# Effective server settings, as sshd will actually apply them
sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractive|pubkeyauthentication|authenticationmethods|allowusers|allowgroups|subsystem|chrootdirectory|forcecommand|loglevel'

# Settings for one specific partner account connecting from one address
sudo sshd -T -C user=partner_cde,host=partner.example,addr=198.51.100.20 | grep -Ei 'authenticationmethods|chrootdirectory|forcecommand'

# Keys authorised for each account, with fingerprints
for d in /home/*/.ssh /sftp/*/.ssh; do
  [ -f "$d/authorized_keys" ] && echo "== $d" && ssh-keygen -lf "$d/authorized_keys"
done

Record, for each account: owner, purpose, partner, whether it is a person or a job, last login, key fingerprints and key age.

Step 2: Require more than one factor

The AuthenticationMethods option, per the manual, lists the authentication methods a user must complete successfully before access is granted. Listing two methods separated by a comma requires both.

# /etc/ssh/sshd_config.d/50-sftp.conf (illustrative)
Match Group sftpusers
    AuthenticationMethods publickey,keyboard-interactive

For people, pair a key with a one time code through PAM, or use hardware backed keys (sk-ssh-ed25519@openssh.com key types tied to a security key). NIST SP 800-63B-4 describes phishing resistant authenticators and requires them at AAL3; a hardware bound key is the closest SSH equivalent. For unattended jobs, where a second interactive factor is not practical, compensate with Step 3: a dedicated key per job, restricted by source address.

Step 3: Restrict where each account can connect from

AllowUsers accepts user@host patterns, and Match Address lets you apply settings by source network. Combine them so each partner account works only from that partner's published egress addresses.

# Only these account and network pairs may log in at all
AllowUsers partner_cde@198.51.100.0/28 vendor_results@203.0.113.16/29 admin_ops@10.20.0.0/24

# Per key restriction, in the account's authorized_keys file
from="198.51.100.0/28",restrict ssh-ed25519 AAAA... partner_cde_job_2026

The restrict option in authorized_keys disables port, agent and X11 forwarding and PTY allocation for that key. Keep the address list in version control with an owner and a review date.

Step 4: Lock the account into SFTP only, inside its own directory

Subsystem sftp internal-sftp -l INFO

Match Group sftpusers
    ChrootDirectory /sftp/%u
    ForceCommand internal-sftp -l INFO
    AllowTcpForwarding no
    AllowAgentForwarding no
    X11Forwarding no
    PermitTTY no

The manual notes that ChrootDirectory requires every component of the path to be root owned and not writable by group or others, and that internal-sftp runs an in process SFTP server that needs no support files inside the chroot. It also warns that ForceCommand does not by itself limit other kinds of access such as forwarding, which is why the forwarding lines are there.

Step 5: Log file operations, not just logins

At -l INFO, the SFTP server logs file opens, closes and transfers with byte counts, so you can see which files an account read. Ship these logs off the server to storage the SFTP host cannot modify.

# Debian and Ubuntu
sudo journalctl -u ssh --since "2026-10-01" | grep -E 'Accepted|sftp-server|internal-sftp'

# RHEL, Rocky, Alma
sudo journalctl -u sshd --since "2026-10-01" | grep -E 'Accepted|open|close'

# Hosts still writing to files
sudo grep -hE 'Accepted (publickey|password|keyboard-interactive)' /var/log/auth.log* /var/log/secure* 2>/dev/null

Step 6: Slow down guessing

Recent OpenSSH releases include PerSourcePenalties, which the manual says refuses connections from a source address (and its network block) for a period after conditions that may represent attacks. Check that your version supports it with ssh -V before you configure it. It does nothing against a valid stolen credential, which is why Steps 2 and 3 matter more.

Step 7: Keep less on the server

• Delete files once the receiving job confirms it has processed them.
• Set a maximum age for anything left behind and enforce it with a scheduled job.
• Where the receiver supports it, encrypt files to the receiver's public key before upload, so the file transfer server only ever holds ciphertext.

# Report (do not delete) files older than 14 days
sudo find /sftp -type f -mtime +14 -printf '%TY-%Tm-%Td %u %s %p\n' | sort

# Encrypt an extract to the recipient's key before upload
gpg --encrypt --recipient results-intake@vendor.example --output extract.csv.gpg extract.csv

Step 8: Rotate and expire

• Give every key a name and a creation date in its comment field.
• Rotate job keys on a schedule (for example every 90 days) and at every staff change on either side.
• Disable accounts that have not logged in for a set period; partner accounts for a seasonal exchange should be off outside the season.

Detecting quiet, intermittent access

Access at various times over four months is the hardest pattern to see, because each session on its own looks fine. Detection has to compare against what is normal for that account.

Build a baseline per account

For every account, record the usual source addresses, days of week, hours, client version string, files touched and bytes moved. A nightly job account has a very narrow baseline; that is good, because anything outside it stands out.

# Logins per account and source address over the last 30 days (OpenSSH text logs)
sudo grep -hE 'Accepted' /var/log/auth.log* 2>/dev/null \
  | awk '{for(i=1;i<=NF;i++){if($i=="for")u=$(i+1); if($i=="from")a=$(i+1)}; print u, a}' \
  | sort | uniq -c | sort -rn | head -50

# Client version strings seen (useful when a job always uses one client)
sudo grep -h 'Remote protocol version' /var/log/auth.log* 2>/dev/null | awk '{print $NF}' | sort | uniq -c

Alert on these signals

If you find a suspicious session

1. Disable the account and revoke its keys; do not just change the password if keys are also authorised.
2. Preserve logs before rotation removes them.
3. List every file the account opened during the suspicious sessions, from the internal-sftp logs.
4. Tell the data owner on the other side of the exchange, and agree who notifies whom.
5. Issue new credentials through a channel the attacker could not see.

Vendor questions after a file transfer breach

Whether you are a state agency, a district or a company sharing data with a vendor, these questions turn a news story into a checklist. Send them to every vendor that receives regulated data from you by file transfer.

Guidance worth reading

The US Department of Education's Student Privacy Policy Office (studentprivacy.ed.gov) covers FERPA, when schools may share education records with contractors, and security best practices and breach scenario trainings for education agencies. CISA's report "Protecting Our Future: Partnering to Safeguard K-12 Organizations from Cybersecurity Threats" sets out a short list of high impact measures for schools, with multi-factor authentication at the centre. The ETS notice itself sits on the California Attorney General's public data breach list.

What changed since first reports

• 19 Oct: Press coverage adds context: the enrollment figure, the superintendent letter of 2 October, ETS's pause of routine enrollment processing (SecurityWeek), an ETS spokesperson's statement that no other ETS customers were affected (GovTech), and the helpline hours (LAist).
• 21 to 23 Oct: Victim counts of 5.7 million and about 7 million appear in roundups and a public incident tracker; neither has been confirmed by ETS or CDE. A proposed class action was reported in secondary coverage around 17 October; we could not confirm a filing from a primary source, so treat it as reported only.

Open questions

• How was the credential compromised, and was it a person's account or a job account?
• Was multi-factor authentication in place on the account?
• How was the activity identified on 25 September?
• How many people are affected?
• What were the steps ETS says it took, with law enforcement, to reduce the risk of the data being made public?
• What will CDE's review of contractual compliance find, and will it be published?
• When will paused enrollment processing and testing work fully resume?

What would have helped

Nothing here claims to know what ETS or CDE had in place or what either could have done differently. These are practices that lower the odds and the impact of a credential being used against a file transfer exchange, for anyone running one.

Practices any team can use

If you run the file transfer server: the eight hardening steps and the detection signals above are the list. In short: phishing resistant MFA for people, source restrictions and one named key per job, file level logs kept off the host and compared with a per account baseline, short retention, encryption to the recipient, and quarterly account reviews with the data owner on the other side.

If you are the data owner sending files to a vendor:

• Data minimisation. Send only the fields the job needs. If a testing workflow does not need disability type or McKinney-Vento status, leave them out, or send them in a separate, more tightly controlled exchange.
• Pseudonymise where possible. If the vendor can work with a stable identifier and match back later, names and addresses do not need to travel.
• Write the controls into the contract: MFA, source restrictions, file level logging, retention limits, notice times and the right to see assessment results.
• Keep a vendor register that lists each exchange, its data elements and its last review.

For a general response template, see our compromised dependency playbook. For third-party risk in another October incident, see the IDCF Cloud ransomware post. For the month's wider picture, see October 2026 security incidents and what would have helped.

Where Safeguard fits

The boundary first. Safeguard does not run or monitor SFTP servers, watch sign ins, detect a compromised credential or analyse file transfer logs. It would not have detected or prevented this incident. The hardening and detection steps above live in your SSH configuration, your identity provider, your log pipeline and your contracts. Where Safeguard helps is the vendor risk record and the software you build and ship around a file exchange:

• Recording the vendor and the follow up. Safeguard's Compliance and GRC suite (GA) has Vendors, Questionnaires, Risks, Policies and Evidence, with connectors that collect evidence from clouds and identity providers. You can record each file transfer vendor, send the questions above as a questionnaire, log the risk and attach evidence for frameworks such as SOC 2 and ISO 27001.
• Knowing what your transfer tooling is made of. Many teams build their own extract and upload jobs, or run the SFTP server in a container. Safeguard scans repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>, with results as JSON under ./output), matches components such as the OpenSSH packages in an image against vulnerability databases, and shows which projects contain a given component and version.
• Ranking and gating. Reachability analysis puts vulnerable code paths your jobs actually call first. Policies and gates are evaluated in the platform and can block, warn, notify or require approval at a checkpoint, for example before a new transfer server image ships.
• A person on every action. The Safeguard CLI's assistant asks before it edits files or runs commands in its default modes (/permissions offers Ask, Accept edits, Plan, Auto and Strict), and the desktop and phone apps send work to a computer running the CLI, where each command is approved or denied. That matters when the change is an sshd_config edit that could lock out every partner. safeguard exec runs the same work in CI.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws 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 (gold.safeguard.sh, free, no login) offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry (registry.safeguard.sh, paid) provides hardened drop in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages; an artifact loses its badge if it regresses.

No vulnerability has been tied to this incident; the notice describes a compromised login, not a software flaw. Neither capability applies to it, and we make no claim that either relates to it. A vendor's hosted SFTP service and its account management are outside the package ecosystems Zero-Day Discovery covers. These capabilities matter for the open source components in the transfer tooling and server images you build, where the right habit is pulling patched, signed components from a curated source and rebuilding fast.

Common mistakes

• Treating "no Social Security numbers" as "low risk". Disability, housing and migrant program flags about children are sensitive in their own right and useful for targeted scams.
• Changing the password but leaving keys authorised. A compromised account may have both; revoke every key.
• Logging logins but not file reads. Without internal-sftp -l INFO or an equivalent, you cannot say what was taken.
• One shared account for many jobs or partners. It hides who did what and makes rotation painful.
• No source restriction on job accounts because "the partner's IP might change." Ask for the egress range and write it into the contract.
• Keeping files forever "in case the job reruns". Retention is the cheapest control there is.
• Assuming the other side is monitoring. In a two party exchange, agree in writing who watches the logs.
• Telling families nothing until letters arrive. One official link on the district site prevents a lot of phishing.

FAQ

What happened in the ETS breach?

An unauthorized party used a compromised login credential at various times between 22 May and 18 September 2026 to access an ETS SFTP site used to exchange California statewide assessment information with CDE, and copied files containing student information. ETS identified the activity on 25 September.

Who is affected?

Students enrolled in California public schools in the three previous school years, and some former students back to 2006 whose transfer was not confirmed with CDE. No victim count has been published.

Is it 5.7 million or 7 million students?

Neither is confirmed. More than 5.7 million is CDE's 2025 to 2026 enrollment figure, used for context. A figure of about 7 million appears in a volunteer incident tracker. GovTech reports the affected group exceeds current enrollment because it includes former students.

What data was taken?

Names, dates of birth, addresses, schools, districts, grades, statewide and local student IDs, demographics, English learner status, disability and Section 504 information, testing accommodations, program eligibility flags and test registration and results, varying by person. Social Security numbers, passwords, financial data and parent information were not included, per the notice.

How did the attacker get the login?

That has not been disclosed. The notice says only that a compromised login credential was used.

Has the data been published?

ETS says that, following regular web monitoring, it has not found evidence the information has been made public.

What should parents do?

Confirm the letter through cde.ca.gov/ets or 833-931-8488, enroll children in Experian IdentityWorks Minor Plus before 19 March 2027, consider a free credit freeze for children under 16, and treat calls or texts that mention the child's school or tests with suspicion.

Was a class action filed?

A proposed class action was reported in secondary coverage around 17 October 2026. We could not confirm the filing from a court record or a primary source.

Does SFTP itself have a vulnerability here?

No vulnerability has been reported. SFTP encrypts traffic in transit, but it cannot tell a legitimate user from someone holding that user's valid credential. That is why MFA, source restrictions and file level monitoring matter.

Fix it without waiting for upstream

This incident turned on a credential, not a software flaw, so there is no package to patch. The same discipline still applies to the transfer tooling and server images around any file exchange: know what versions you run and move to fixed ones fast.

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 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 this incident, ETS, CDE or an SFTP server. Each shows a real Safeguard flow that applies to the tooling and images around a file exchange you run.

The first demo is a real CLI session. It installs the CLI, opens the interactive terminal and asks it to fix the lodash CVE in a repository; the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. For a team that maintains its own extract and upload jobs, you would run the same /scan . against that repository and ask the assistant to move a flagged component to its fixed version, approving each step.

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

The second demo sets up the runner on your own machine, approves it with its device code, then scans from the terminal. If your SFTP server runs from a container image you build, this is how you would scan that image from a machine inside your own network, so the image and its OpenSSH packages never leave it.

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

The third demo is a real desktop app session. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit; it ends with the upgrade done and tests passing. The same approve or deny habit is what you want for changes to a file transfer server's configuration, where one wrong line can lock out every partner or open a door you meant to close.

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

To try Safeguard on your own repositories, download Safeguard and follow the CLI docs.

Quick check

Sources

• ETS: Notice of Data Breach, as filed with the California Attorney General (PDF)
• California Attorney General: Data Security Breach list
• California Department of Education: news release #26-45, 16 October 2026 (cited; the site blocks automated fetches)
• California Department of Education: ETS incident information page (cited)
• SecurityWeek: One Compromised Login Exposed Millions of California Students' Records, 19 October 2026
• GovTech: Testing Company Data Breach Affects Millions of Calif. Students
• LAist: California student data breach, what to do
• Malwarebytes (Spanish edition): Millions of California students' sensitive data stolen in breach
• VERIS Community Database: issue #24550
• Privacy Guides: Data breach roundup, 16 to 22 October 2026
• OpenBSD manual: sshd_config(5)
• NIST SP 800-63B-4: Authentication and Authenticator Management
• CISA: Protecting Our Future: Partnering to Safeguard K-12 Organizations from Cybersecurity Threats
• US Department of Education, Student Privacy Policy Office: FERPA

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