Software Makers Encouraged to Stop Using C/C++ by 2026

The federal government is encouraging software manufacturers to ditch C/C++ and take other actions that could “reduce customer risk,” according to the Product Security Best Practices report. In particular, CISA and the FBI set a deadline of Jan. 1, 2026, for compliance with memory safety guidelines.

The report covers guidelines and recommendations rather than mandatory rules, particularly for software manufacturers who work on critical infrastructure or national critical functions. The agencies specifically highlighted on-premises software, cloud services, and software-as-a-service.

While it isn’t directly stated that using ‘unsafe’ languages could disqualify manufacturers from government work, and the report is “non-binding,” the message is straightforward: Such practices are inappropriate for any work classified as relevant to national security.

“By following the recommendations in this guidance, manufacturers will signal to customers that they are taking ownership of customer security outcomes, a key Secure by Design principle,” the report states.

Memory-unsafe programming languages introduce potential flaws

The report describes memory-unsafe languages as “dangerous and significantly elevates risk to national security.” Development in memory-unsafe languages is the first practice the report mentions.

Memory safety has been a topic of discussion since at least 2019. Languages like C and C++ “provide a lot of freedom and flexibility in memory management while relying heavily on the programmer to perform the needed checks on memory references.” a 2023 NSA report on memory safety stated. However, the report continued, those languages lack inherent memory protections that would prevent memory management issues. Threat actors can exploit memory issues that might arise in those languages.

What software manufacturers should do by January 2026

By Jan. 1, 2026, manufacturers should have:

• A memory safety roadmap for existing products written in memory-unsafe languages, which “should outline the manufacturer’s prioritized approach to eliminating memory safety vulnerabilities in priority code components.”
• A demonstration of how the memory-safety roadmap will reduce memory-safety vulnerabilities.
• A demonstration of “reasonable effort” in following the roadmap.
• Alternatively, manufacturers should use a memory-safe language.

Memory-safe languages approved by the NSA include:

• Python.
• Java.
• C#.
• Go.
• Delphi/Object Pascal.
• Swift.
• Ruby.
• Rust.
• Ada.

SEE: Benefits, risks, and best practices of password managers (TechRepublic)

Other ‘bad practices’ vary from poor passwords to lack of disclosures

Other practices labeled “exceptionally risky” by CISA and the FBI include:

• Allowing user-provided input directly in the raw contents of a SQL database query string.
• Allowing user-provided input directly in the raw contents of an operating system command string.
• Using default passwords. Instead, manufacturers should ensure their product provides “random, instance-unique initial passwords,” requires the users to create new passwords at the start of the installation process, requires physical access for initial setup, and transitions existing deployments away from default passwords.
• Releasing a product containing a vulnerability from CISA’s Known Exploited Vulnerabilities (KEV) Catalog.
• Using open source software with known exploitable vulnerabilities.
• Failing to leverage multifactor authentication.
• Lacking the capability to gather evidence of intrusion if an attack does occur.
• Failing to publish timely CVEs including the Common Weakness Enumeration (CWE), which indicates the type of weakness underlying the CVE.
• Failing to publish a vulnerability disclosure policy.

The full report includes recommended next steps organizations can use to comply with the agencies’ guidelines.