Software manufacturers are recommended to stop using C/C++ by 2026

According to the Product Security Best Practices report, the federal government is urging software manufacturers to move away from C/C++ and take other actions that can “reduce risk to customers.” Specifically, CISA and the FBI have set a deadline of January 1, 2026, for compliance with memory security regulations.

Report covers guidelines and recommendations rather than mandatory rules, especially for software vendors who work on critical infrastructure or national mission-critical functions. The agencies highlighted on-premise software, cloud services and software as a service.

While it doesn’t explicitly say that using “unsecure” language could disqualify manufacturers from working for the government, and the report is “non-binding,” the message is simple: the practice is inappropriate for any job classified as having a national security relevance.

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

Memory-Insecure Programming Languages ​​Contain Potential Drawbacks

The report describes memory-insecure languages ​​as “dangerous and significantly increasing the risk to national security.” Developing in languages ​​with unsafe memory is the first practice mentioned in the report.

Memory security has been a topic of discussion since at least 2019. Languages ​​such as C and C++ “provide greater freedom and flexibility in memory management while relying heavily on the programmer to perform the necessary memory reference checks.” A 2023 NSA Report on Memory Security stated. However, as the report notes, these languages ​​lack built-in memory protection that could prevent memory management problems. Threat actors may take advantage of memory problems that may occur in these languages.

What software manufacturers must do by January 2026

By January 1, 2026, manufacturers must have:

• A memory security roadmap for existing products, written in non-memory safe languages, which “should describe the vendor’s prioritized approach to addressing memory security vulnerabilities in priority code components.”
• Demonstrate how the memory security roadmap will reduce memory security vulnerabilities.
• Demonstration of “reasonable efforts” in following the roadmap.
• As an alternative, manufacturers should use a memory-safe language.

Memory-safe languages ​​approved by the NSA include:

• Python.
• Java.
• WITH#.
• Go.
• Delphi/Pascal Object.
• Fast.
• Ruby.
• Rust.
• Ada.

SEE: Benefits, risks and best practices password managers (Tech Republic)

Other “bad practices” range from bad passwords to lack of disclosure.

Other methods cited by CISA and the FBI as “exceptionally risky” include:

• Allowing user input directly into the raw content of a SQL database query string.
• Allows user input directly into the raw content of the operating system command line.
• Using default passwords. Instead, manufacturers must ensure that their product provides “random, instance-unique initial passwords,” requires users to create new passwords at the beginning of the installation process, requires physical access for initial setup, and transitions existing deployments away from default passwords.
• Release of a product containing a CISA vulnerability Known Exploitable Vulnerabilities (KEV) Directory.
• Use of open source software with known vulnerabilities.
• Failed to use multi-factor authentication.
• Inability to collect evidence of an intrusion should it occur.
• Failure to timely publish CVE reports, including the Common Weapons Equity (CWE) inventory, which identifies the type of vulnerability underlying the CVE.
• The vulnerability disclosure policy could not be published.

The full report includes recommended next steps organizations can use to comply with agency guidelines.