Writing new code in memory-safe languages delivers faster security gains because it avoids the hardest compatibility problems and immediately reduces the amount of new vulnerable code entering the environment. Rewriting legacy code first is far slower, more expensive, and often blocked by dependencies, performance constraints, and operational risk. Most organisations should treat new development as the primary conversion path.
Why new code in memory-safe languages usually pays off first
New development is the fastest place to change the security curve because it does not require preserving decades of fragile interfaces, undocumented behaviour, and performance-sensitive assumptions. You can set a safer default for all new components while the organisation keeps shipping. That makes the benefit immediate, measurable, and much less dependent on long migration programmes.
The practical difference is that new code gives teams a clean boundary for language choice, build standards, and review expectations. Legacy rewrites often turn into multi-year architecture projects because they must preserve business logic, data flows, and integration contracts at the same time. A new-code-first strategy reduces exposure faster because it prevents additional vulnerable code from accumulating while the old estate is still being studied.
That is why many programmes treat the current secrets and credentials problem as a useful analogy: you lower risk faster by changing what is newly introduced than by waiting for every historical dependency to be rebuilt. In code modernisation, the same logic applies. Move the forward-looking development path first, then attack the hardest legacy surfaces selectively.
Why rewriting legacy code first slows security improvement
Legacy-first rewrites are slower because they must reproduce old behaviour before they can improve it. That means more time spent on compatibility testing, regression handling, data migration, and operational rollback planning. In many environments, the system that most needs improvement is also the system least able to tolerate a broad rewrite without unacceptable downtime or business interruption.
The security trade-off is that a rewrite postpones gains until the replacement is complete, while the exposure in the existing code remains in production throughout the programme. In contrast, a memory-safe language for new code changes the security baseline as soon as the first new service, module, or feature lands. The result is a smaller accumulation of fresh memory-safety defects, even though the legacy estate still needs separate treatment.
For practitioner planning, the key question is not whether legacy code matters, it does. The question is whether the organisation wants early risk reduction or wants to concentrate effort in the most difficult part of the estate first. In most cases, the answer is the same as the one reflected in the broader software assurance and code-hardening literature: prioritise the path that delivers security value without forcing a wholesale dependency rewrite.
Risk and Threat Considerations
The main risk of a legacy-first strategy is delayed protection. If the organisation waits for a rewrite before adopting safer language choices, it continues to ship new vulnerable code into production and prolongs the lifespan of the hardest-to-secure components. A new-code-first strategy also reduces the chance that long-lived implementation defects remain exploitable while migration work is still underway.
Failure mechanism: Legacy code rewrites often stall on compatibility constraints, hidden dependencies, and operational tolerance for change, which leaves the highest-risk systems untouched while new vulnerable code continues to enter the environment.
Impact: Security gains arrive later, remediation cost rises, and the organisation carries both old exposure and new exposure for longer than necessary. That extends the window for exploitation, regression, and project failure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 16 — Application Software Security | Memory-safe language choice reduces software flaw introduction at build time. |
| CIS 4 — Secure Configuration of Enterprise Assets and Software | New-code-first migration changes defaults and hardens the software baseline earlier. | |
| Recommendation — Adopt secure-by-design language standards for new development to reduce memory-safety defect introduction. Set secure language and build defaults for new services before legacy replacement begins. | ||
Practitioner Guidance
What to prioritise: Convert the next generation of products and services first, especially where teams have natural redesign opportunities, because that is where memory-safe adoption is most likely to stick without destabilising production.
Decision rule: If a component can be rewritten only by recreating critical legacy dependencies one by one, treat it as a long-term modernisation candidate, not the first security win. If the team is already building something new, make memory safety the default design choice there.
What to verify: Confirm that the security benefit is real at the portfolio level, not just in a pilot. The observable signal is a declining share of newly introduced code paths that depend on memory-unsafe patterns, even while legacy remediation continues separately.
Practitioner takeaway: The strongest programme is usually the one that reduces future risk immediately, then modernises the hardest legacy systems on a separate timetable rather than making them the gate for all progress.
Related resources from NHI Mgmt Group
- What is the difference between renting legacy applications and owning security in a build-first operating model?
- What is the difference between Python-driven detection-as-code and traditional SIEM rule writing?
- What is the difference between code-first and spec-first API specification generation?
- What is the difference between code scanning and runtime identity monitoring?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
