How should security teams handle legacy model formats that still execute code at load time?

Security teams should treat legacy model formats as executable content, not inert data. The safe approach is to restrict what can be loaded, verify the provenance of checkpoints, and assume old formats may bypass newer safety controls. If a framework still supports deserialisation paths that can run code, governance needs to cover model intake, dependency risk, and runtime monitoring.

Why Legacy Model Formats Need to Be Treated as Code, Not Just Artifacts

Legacy model formats that execute code at load time create a different class of risk from ordinary file handling. The issue is not simply that a checkpoint may be malformed; it is that loading can become an execution step, which means provenance, trust boundaries, and dependency hygiene all matter before a model is ever used. Teams that assume model storage is passive data often miss the fact that the loader itself can become the attack surface. The control problem is therefore about intake discipline as much as runtime defence. In practice, many security teams discover this only after a legacy format is already embedded in an older workflow and someone tries to modernise controls around it.

What Safe Handling Looks Like Across the Model Lifecycle

Security teams should approach legacy formats as untrusted executable inputs and define a narrow approval path for them. That usually starts with inventorying which formats are still permitted, which teams own them, and which loaders or libraries interpret them. The safest operating model is to separate trusted conversion workflows from ordinary inference or training paths so that a risky file is never opened in a high-trust environment by default.

At a minimum, teams need to verify where the model came from, what dependencies are required to load it, and whether the loading process can trigger code paths outside the intended model graph. That is especially important when formats rely on general-purpose serialisation mechanisms, because those mechanisms may preserve more than weights and metadata. When governance is weak, the real failure mode is not only accidental execution but also a supply-chain style trust problem: a file that looks like a model can carry behaviour that the platform did not intend to permit.

Operationally, good handling usually includes all of the following:

Restricting allowed formats to those with well-understood loading semantics.
Quarantining legacy checkpoints until they are converted or validated.
Tracking loader libraries and their transitive dependencies as part of model intake.
Running conversion and inspection in a lower-trust environment than production.
Logging load events so unexpected execution paths can be investigated.

NIST guidance on control discipline is useful here because the problem spans software integrity, access control, and monitoring rather than model risk alone. NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant when teams need to tie model intake to broader platform controls, especially around authorised software, execution restrictions, and auditability.

This guidance breaks down when organisations treat legacy format support as a convenience feature and continue loading old artifacts directly in production without a controlled conversion path.

Where Legacy Formats Commonly Break Governance Assumptions

Tighter model loading controls often increase operational overhead, requiring organisations to balance legacy compatibility against the cost of safer intake processes.

Common edge cases involve research environments, shared notebooks, and migration periods where teams still need to load older artifacts for validation or comparison. Those contexts often blur the line between analytics work and execution authority, which is where legacy formats become most dangerous. A format may be acceptable in an isolated conversion pipeline but unacceptable in a multi-tenant platform or an automated deployment workflow. That distinction should be explicit rather than implied.

There is also a practical consensus issue: some teams argue that a format is acceptable if the source repository is trusted, while others require the loader path itself to be treated as hostile until proven otherwise. NHI Management Group’s view is that provenance alone is not enough when the deserialiser can execute code. The format, the loader, and the runtime environment all need separate review.

Teams should be especially cautious when older formats are kept for interoperability. Interoperability pressure often leads to exceptions that outlive their original justification, and those exceptions can quietly become the default path for new artifacts. In that situation, the main control failure is drift: what began as a temporary compatibility decision turns into a standing execution channel.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.IP-1 — Baseline Configuration and Change Management	Legacy formats need controlled intake and approved loading paths.
	PR.DS-6 — Data Integrity	Load-time code execution turns file integrity into a security control concern.
Recommendation — Restrict permitted model formats and manage loader changes through formal approval. Validate model provenance and integrity before any deserialisation step.
CIS Controls v8	16 — Application Software Security	Model loaders behave like software components that must be secured.
	2 — Inventory and Control of Software Assets	Teams must know which formats and libraries remain authorised.
Recommendation — Harden and test loader paths that can execute code during model import. Inventory legacy formats, loader libraries, and conversion tools used in production.
MITRE ATT&CK	T1027 — Obfuscated Files or Information	Legacy artifacts can hide executable behaviour inside expected model content.
Recommendation — Inspect suspicious artifacts for hidden executable content before loading them.

Practitioner Guidance

What to prioritise: Classify every legacy format by whether loading can trigger execution, then decide which formats are allowed only in isolated conversion workflows and which are barred from normal operational paths.

What to verify: Verify that the loader, its dependencies, and the surrounding runtime are controlled separately from model provenance. A trusted source does not eliminate risk if the deserialisation path itself can execute code.

Common mistake: Treating “model approved” as equivalent to “file safe.” For legacy formats, that shortcut hides the real decision, which is whether the platform is willing to trust code execution at load time.

Practitioner takeaway: The key judgement is not whether the model is useful, but whether the organisation can safely separate model consumption from code execution; if it cannot, the format should be isolated or retired.