Introduction
The SEC’s 2023 cybersecurity disclosure rules contain no mention of legacy systems, end-of-life software, or technical debt. That silence is not a carve-out. It is where the disclosure exposure for most public companies actually lives.
The rules establish two obligations: annual disclosure of cybersecurity risk management processes in the 10-K, and prompt disclosure of material cybersecurity incidents on Form 8-K. Both are framed around material risk and material incidents.
A company that operates production applications on unpatchable, unsupported platforms carries material cybersecurity risk that is known, permanent, and accumulating. How that risk is characterized in SEC filings is no longer a legal drafting question. It is an enforcement question.
This article addresses the disclosure dimension: what the rules require, how legacy and EOL software flows into those requirements, and what a defensible disclosure posture looks like for a company with material legacy exposure.
SEC Cyber Disclosure Rules: Item 1.05 vs. Item 106 Explained
The SEC adopted its cybersecurity disclosure rules on July 26, 2023. They became effective September 5, 2023, with annual disclosures applicable to fiscal years ending on or after December 15, 2023 [1]. Every domestic public company has now filed at least one annual report under these requirements.
When a Cybersecurity Incident Must Be Disclosed Under Item 1.05
Item 1.05 requires a company to file a Form 8-K disclosing a material cybersecurity incident within four business days of determining the incident is material [1]. The deadline is tied to the materiality determination, not to the date the incident occurred, was discovered, or was reported to law enforcement. The SEC has stated explicitly that in most cases, a company will be unable to make the materiality determination on the same day the incident is discovered [2].
The determination must be made “without unreasonable delay.” Deliberately slow-walking the process is flagged in the adopting release as an example of unreasonable delay [1].
The filing must cover the nature, scope, and timing of the incident, and the material impact or reasonably likely material impact on the company. Item 1.05 explicitly does not require disclosing technical specifics that would impede response or remediation [1]. The disclosure is an investor communication about impact and materiality, not a vulnerability briefing.
What Companies Must Disclose in Item 1C of the 10-K
Item 106 requires companies to describe, in sufficient detail for a reasonable investor to understand, their processes for assessing, identifying, and managing material risks from cybersecurity threats [1]. The disclosure lives in Item 1C of the annual Form 10-K, covering three sub-components:
- Risk management processes, including whether they integrate with overall enterprise risk management
- Management’s role in assessing and managing material cybersecurity risks
- The board’s oversight of cybersecurity risks
The rule uses the phrase “processes, if any.” A company with no formal processes must say so. A company with processes must describe them accurately. The SEC’s own first-year review found many companies providing Item 1C language that was difficult to evaluate against their actual programs [1].
One misconception worth correcting: the final rule dropped the originally proposed requirement to disclose whether board members possess cybersecurity expertise. That requirement does not appear in the rules as adopted.
Item 1.05 vs. Item 106: Key Differences
| Form 8-K Item 1.05 | 10-K Item 106 / Item 1C | |
| Trigger | A cybersecurity incident determined to be material | Annual reporting cycle |
| Timing | Within 4 business days of materiality determination | Fiscal years ending Dec 15, 2023 onward |
| What it covers | Nature, scope, timing, and material impact of the incident | Risk management processes, management role, board oversight |
| What it does not require | Technical detail that would impede response or remediation | A world-class security program; accurate description of actual processes suffices |
| The enforcement exposure | Describing a realized incident as hypothetical or minimizing known scope | Aspirational process language; failure to disclose known material risks |
Why Legacy and EOL Systems Create SEC Disclosure Risk
The rules say nothing about legacy systems. Item 106 requires describing material cybersecurity risks accurately. Those two facts produce the disclosure problem for any public company running production applications on EOL or unsupported platforms.
End-of-life software is not a risk that “could” materialize under the right conditions. It is a structural condition: the vendor has stopped issuing security patches, newly discovered vulnerabilities will remain permanently unpatched, and the attack surface grows every month as new CVEs are published with no remediation path.
Nearly half of the entries in CISA’s Known Exploited Vulnerabilities catalog are linked to end-of-service software; these are confirmed, actively weaponized vulnerabilities [6]. An organization running production systems on those platforms carries a documented, enumerable, permanent risk, not a theoretical one.
The stacks in question are not obscure. The following all carry this exposure profile:
- VB6: no vendor support since 2008; for the production risks of running VB6 on Windows 11, compatibility is not the same as security support
- .NET Framework: pre-LTS versions accumulate CVEs each quarter; see our analysis of when .NET Framework 4.x support ends and what it means for applications still on those versions
- AngularJS: EOL December 2021, multiple CVEs with no official patches since
- Apache Struts: historically significant CVE history, actively targeted versions still in enterprise production
- Java EE, EJB, Classic ASP, and Delphi: analogous exposure across each
For companies running these stacks, Item 106 requires describing how material cybersecurity risk from those systems is assessed, identified, and managed.
If the actual process is “we continue operating with compensating controls and accept the residual risk,” that is what Item 1C must describe: specifically and accurately, not through generic patch-management language that does not apply to unpatchable systems.
Know what AI-powered vulnerability tooling would find in your legacy estate before a breach forces the question?
Legacyleap’s Security Assessment maps your dependency surface, surfaces unresolvable CVEs, and separates compliance risk from security risk, entirely inside your infrastructure, in 3 to 5 days.
The Disclosure Controls Dimension
The enforcement exposure operates on two levels simultaneously. The first is the accuracy of the risk characterization in the 10-K. The second is whether the organization is structurally capable of making an accurate, timely materiality determination when a legacy system is breached.
Legacy applications without native monitoring, structured audit logging, or a defined incident escalation path create a compounding problem. When a breach occurs on a system with no telemetry, the organization may not know what was accessed, when, or at what scope. That information gap directly affects the ability to make a timely and accurate materiality determination under Item 1.05.
Unisys was charged not only with misleading disclosures but with deficient disclosure controls. Specifically, the SEC alleged a failure to establish a process requiring cybersecurity personnel to escalate material incidents to the executives responsible for disclosure [3].
For organizations running legacy systems without visibility tooling, that structural gap is not an organizational failure. It is an architectural one. The system does not produce the evidence trail that a governed escalation process requires.
The four-day window is difficult to meet when the incident involves a system that cannot tell you what happened.
A major US airline operating a VB6 application with zero documentation faced a mandatory regulatory audit with a non-negotiable remediation deadline. The security assessment mapped 2,588 COM references, 195 Win32 API calls, and four unmapped database integrations nobody on the current team could account for. Legacyleap delivered a fully modernized React and .NET Core application in eight weeks, with a four-person team, at 50% lower cost than the manual rewrite estimate.
What the October 2024 SEC Enforcement Actions Established
On October 22, 2024, the SEC announced settled enforcement actions against four public companies, all downstream victims of the 2020 SolarWinds software hack [3]:
- Unisys: $4M penalty; charged with both misleading disclosures and deficient disclosure controls
- Avaya Holdings: approximately $1M; charged with misleading disclosures
- Check Point Software Technologies: approximately $995K; charged with misleading disclosures
- Mimecast: approximately $990K; charged with misleading disclosures
The common mechanism: each company had learned that the SolarWinds intrusion had affected its environment and continued filing risk factor disclosures using language that characterized cyber risks as hypothetical possibilities. In the SEC’s assessment, that language was materially misleading because it did not reflect what the companies knew about realized exposures [3] [4].
Unisys drew the largest penalty and a second charge the others did not face. The SEC alleged that cybersecurity personnel had no defined process to escalate incident information to the executives responsible for SEC filings [3]. Two distinct findings: one about what was disclosed, and one about whether the organizational architecture could support accurate disclosure at all.
Between December 2023 and early 2025, 54 companies filed 80 Form 8-K disclosures related to cybersecurity incidents, with the SEC settling multiple enforcement actions totaling over $8M in aggregate penalties. The enforcement record carries active consequences, not theoretical ones.
What the SolarWinds Ruling Means for Cybersecurity Disclosures
The SolarWinds case is frequently cited as limiting SEC cybersecurity enforcement in ways the ruling does not support.
On July 18, 2024, U.S. District Judge Paul Engelmayer dismissed the bulk of the SEC’s claims against SolarWinds and its CISO [5]. The court rejected charges based on post-SUNBURST disclosures, finding they must be read in the context of an unfolding investigation and that the SEC’s arguments relied on hindsight [5]. The case was fully dismissed with prejudice on November 20, 2025 [5].
What the dismissal established: the SEC cannot reliably second-guess post-incident disclosures made while a company is actively investigating a novel, unfolding attack. What it did not establish: protection for disclosures that describe known, realized risks using hypothetical language while internal evidence of those risks exists.
The distinction matters directly for the legacy-systems context. SolarWinds was responding to a sophisticated, novel supply-chain attack with incomplete information. A public company that has operated VB6 or AngularJS applications in production for years, with documented CVEs, no patch channel, and a known support termination date, is not in an unfolding-investigation posture.
The condition is structural, documented, and known to the engineering and security teams. That profile sits closer to the Unisys fact pattern than to SolarWinds.
CETU and the Current Enforcement Direction
In February 2025, the SEC reorganized its cyber enforcement unit in a way that directly signals where disclosure enforcement is heading. For companies with known legacy exposure, the direction matters.
The SEC created the Cyber and Emerging Technologies Unit (CETU) in February 2025, replacing the Crypto Assets and Cyber Unit. CETU’s stated priorities include “public issuer fraudulent disclosure relating to cybersecurity,” explicitly fraud-focused enforcement rather than technical disclosure violations.
The direction favors less aggressive pursuit of good-faith disclosure errors and more aggressive prosecution of intentional misstatements and material omissions. For companies with known legacy exposure, describing a structural, known risk as hypothetical sits on the wrong side of that line.
The enforcement record makes the standard clear. The practical question for a CTO or CISO preparing Item 1C language is what accurate disclosure actually looks like when your production environment includes EOL or unsupported applications.
How to Disclose Legacy System Risk in Item 1C
Item 106 does not require a world-class cybersecurity program. It requires an accurate description of whatever program exists [7]. A company with genuine legacy exposure can describe how it manages that risk, including the limits of those controls, without disclosing a CVE inventory or system architecture map. The obligation is accuracy, not comprehensiveness.
The SEC’s own disclosure guidance instructs registrants that risk factor language must not be generic and must reflect the registrant’s specific facts and circumstances [7]. Language that could appear in any company’s 10-K regardless of actual risk profile fails that standard.
For companies with EOL software in production, generic patch-management language describing controls that do not apply to unpatchable systems is exactly what the enforcement actions are built to address.
Why CTOs Need a Formal Cyber Risk Escalation Process
Getting the disclosure language right is only half the problem. The SEC expects the organizational process behind it to hold up under scrutiny too. Cybersecurity personnel need a defined escalation path to the executives who approve the 10-K, and that path has to exist before a breach, not be assembled in response to one.
The companies charged in October 2024 were not all charged because executives deliberately misled investors. Some faced charges because the governance architecture between their security function and their disclosure function had gaps.
For CTOs preparing or reviewing Item 1C language, the governance checkpoint is direct: does the process that informs this disclosure actually reach the people with current knowledge of the company’s cybersecurity posture?
If the security team’s reporting chain does not reach the disclosure committee in a structured, timely way, that is the second Unisys charge waiting to happen.
Defensible Language vs. Unisys-Risk Language
The table below illustrates the practical difference across three common legacy scenarios. It is not legal advice; specific disclosure language requires review by securities counsel familiar with the company’s actual risk profile. It is a structural framework for the technical leaders who provide factual inputs.
| Scenario | Language with Unisys-Type Exposure | Defensible Language Framework |
| EOL application framework in production | “We may be subject to cyber risks from vulnerabilities in our software platforms.” | “We operate applications on frameworks for which vendor security support has ended. Known vulnerabilities cannot be patched through vendor-issued updates. We manage this exposure through [specific compensating controls] and are executing a modernization program to migrate these applications to supported platforms by [timeframe].” |
| Known unpatched CVEs in production systems | “Our systems may contain vulnerabilities that could be exploited.” | “Specific CVEs have been identified in components of our production environment for which patches are not available due to platform EOL status. These vulnerabilities are documented in our risk register. Mitigating controls include [specific controls]. The underlying applications are on our active modernization roadmap.” |
| No audit logging on legacy systems | “We maintain cybersecurity controls designed to detect and respond to incidents.” | “Certain legacy applications do not support the logging and monitoring capabilities of our primary incident detection infrastructure. Incidents involving these systems may have a longer detection and assessment window. We are modernizing these applications to bring them within our standard monitoring architecture.” |
The through-line across all three:
- Describe the actual condition,
- Describe the actual controls in place, including their limitations, and
- Describe the remediation program if one exists.
A credible, active modernization program as part of the disclosure narrative is both accurate and structurally strengthens the Item 1C posture, because it demonstrates the active risk management oversight the rule’s governance disclosure requires.
Accurate language is the disclosure obligation. Reducing the underlying risk is what changes the disclosure posture permanently. That requires knowing exactly what your legacy estate contains, and that is a technical problem before it is a legal one.
That requires a modernization partner with the tooling to map what the system contains before a single line of code is changed. Legacyleap is purpose-built for exactly that starting point, with 150+ production-grade assessments completed across enterprise environments.
For a technical view of why tightly coupled legacy systems are structurally difficult to monitor and patch, our analysis covers the architectural factors that create the monitoring gap.
How Modernization Reduces SEC Cybersecurity Disclosure Risk
The most defensible Item 1C describes material risks that are actively being reduced, on a timeline, through a program the company can document and verify. That requires the underlying risk to actually be getting smaller, not characterized more carefully.
Accurate Item 1C disclosure requires knowing what your legacy estate actually contains. Legacyleap is a Texas-based Gen AI-powered modernization platform that produces that evidence base as a direct output of the assessment process, mapping dependency surfaces, surfacing unresolvable CVEs, and separating compliance risk from security risk, entirely within the client’s infrastructure.
Starting With a Security Assessment of Legacy Systems
Before modernization begins, the organization needs to know what it is actually running. Legacyleap’s Security Assessment maps the legacy estate at the component level: dependency surface, unresolvable CVEs, patch gaps on out-of-support versions, and a clear split between compliance risk and security risk.
It runs entirely within the client’s infrastructure, no source code leaves their environment, and delivers findings in 3 to 5 days.
This output is the evidence base that accurate Item 1C disclosure requires: documented, specific, produced from the actual source code rather than assumptions about what the system contains.
For regulated public companies concerned that a modernization engagement itself creates disclosure or compliance exposure, the fully on-premise deployment model directly addresses that concern.
Legacyleap has completed more than 150 production-grade assessments across enterprise environments.
The Modernization Process That Reduces Disclosure Risk
The assessment establishes the baseline. The program that changes the Item 1C posture runs the full lifecycle.
The Recommendation Agent evaluates the assessment outputs and produces an ordered modernization plan: target stack selection, phased migration sequencing, and module-level effort and risk scoring.
The Modernization Agent executes governed code transformations against that plan, producing converted code as diff-based pull requests that engineering teams review and approve before any change is accepted. AI does not merge or deploy code autonomously. Every transformation is reviewable, reversible, and traceable.
Because the transformation is executed by Gen AI agents rather than manual rewriting, modernization work does not require taking production systems offline. The timeline is measured in weeks, not the 18 to 36 months a traditional replacement requires.
The QA Agent validates behavioral parity between the legacy and modernized versions through auto-generated unit, integration, regression, API, and functional test suites. The platform delivers 100% functional parity validation before deployment.
The full audit trail is logged: every agent action, every transformation, every approval. The modernized application runs on a supported platform with an active patch channel, native monitoring capability, and the logging infrastructure that a timely Item 1.05 materiality determination requires.
Legacy Technologies Supported for Modernization
Legacyleap supports the specific stacks that create disclosure exposure:
- .NET: VB6, .NET Framework (all pre-LTS versions), Classic ASP, ADO.NET, Web Forms
- Java: Struts, JSP/Servlets, EJB, Java EE
- Frontend: AngularJS
- Additional: Delphi, ColdFusion, monolith architectures
Two delivery models are available.
- Turnkey Modernization Services gives Legacyleap’s team full ownership from assessment through deployment, with managed delivery and validation checkpoints throughout.
- Platform Licensing gives enterprises or their system integrators direct access to the agents, Studio workspace, and full lifecycle tooling to run modernization internally.
Both models process all source code within the client’s environment.
For the CFO and board members evaluating the business case for modernization, our ROI framework covers the three-horizon return calculation.
What Public-Company CTOs Should Do Now
The SEC’s cybersecurity disclosure rules have been in force long enough that their operational requirements are no longer ambiguous. The October 2024 enforcement record has established what accurate disclosure requires and what creates liability.
For public companies with material legacy and EOL exposure, the filing risk is not abstract. It is the gap between the actual condition of their production systems and the language that appears in their 10-K.
Describing a known, structural cybersecurity risk as a hypothetical possibility is the specific mechanism the Unisys enforcement order identified. A company operating unpatchable, unsupported applications in production while filing Item 1C language framing those conditions as risks that “could” materialize has the same fact pattern, regardless of whether an intrusion has occurred yet.
The defensible path is a program that moves the company off the platforms creating the characterization problem, with the evidence to document both the current state and the remediation trajectory.
The first step is knowing what your legacy estate actually contains. Legacyleap’s Security Assessment maps your dependency surface, surfaces unresolvable CVEs, and separates compliance risk from security risk, entirely inside your infrastructure, no source code leaving your environment, findings delivered in 3 to 5 days.
To see how the assessment and full agent lifecycle work against a real codebase before sharing your own:
FAQs
Item 1.05 is strictly for incidents already determined to be material. If materiality has not yet been assessed, or the incident is determined immaterial, the SEC has directed companies to file voluntarily under Item 8.01 instead, filing under Item 1.05 prematurely risks investor confusion and regulatory pushback.
Individual officers can face personal civil penalties, disgorgement of compensation, and bars from serving as a public company officer or director. D&O insurance typically excludes deliberate fraud, so a CISO or CTO whose name is attached to materially misleading Item 1C language may have no policy coverage.
The SEC has used comment letters to flag missing Item 1C disclosures entirely and insufficient descriptions of management’s cybersecurity expertise. A comment letter creates a documented record of the SEC’s specific concerns and removes the good-faith defense in any subsequent enforcement action.
Yes. Item 106 explicitly requires describing how the company manages cybersecurity risks from third-party vendors and service providers. A vendor running EOL software that handles material company data sits within that scope; the obligation is to describe the oversight process, not the vendor’s specific stack.
An in-progress modernization program is disclosable as an active risk-reduction measure and strengthens the Item 1C posture. The SEC does not require milestone specificity, but the program must be real and operating. A contracted scope with documented progress is materially different from a roadmap that exists only in a slide deck.
References
[1] SEC, “Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure: Small Business Compliance Guide,” https://www.sec.gov/resources-small-businesses/small-business-compliance-guides/cybersecurity-risk-management-strategy-governance-incident-disclosure
[2] SEC, Erik Gerding, “Disclosure of Cybersecurity Incidents Determined To Be Material and Other Cybersecurity Incidents,” May 21, 2024, https://www.sec.gov/newsroom/speeches-statements/gerding-cybersecurity-incidents-05212024
[3] McGuireWoods, “SEC Settles Charges for Alleged Misleading Disclosures, Shedding Light on Materiality in Cyber Context,” October 2024, https://www.mcguirewoods.com/client-resources/alerts/2024/10/sec-settles-charges-for-alleged-misleading-cyber-disclosures/
[4] Davis Polk, “SEC Charges Public Companies with Inadequate Disclosures in Aftermath of the SolarWinds Cyberattack,” October 2024, https://www.davispolk.com/insights/client-update/sec-charges-public-companies-inadequate-disclosures-aftermath-solarwinds
[5] Perkins Coie, “SEC Dismisses Cyber Disclosure Case Against SolarWinds and CISO,” December 2025, https://perkinscoie.com/insights/update/sec-dismisses-cyber-disclosure-case-against-solarwinds-and-ciso
[6] HeroDevs, “How Outdated Systems and Legacy Software Are Fueling Modern Cyber Attacks,” https://www.herodevs.com/blog-posts/how-outdated-systems-and-legacy-software-are-fueling-modern-cyber-attacks
[7] SEC, “CF Disclosure Guidance: Topic No. 2,” https://www.sec.gov/rules-regulations/staff-guidance/disclosure-guidance/cf-disclosure-guidance-topic-no-2
