Model signing verifies that a model has not been altered since a trusted party produced it, while model scanning looks for suspicious structure, payloads, or unsafe serialization patterns. Both matter. Signing helps with provenance and integrity, but it does not replace inspection for embedded malicious logic or dangerous deserialisation behaviour.
Model signing and model scanning solve different security problems
Model signing is a provenance and integrity control: it tells you a model came from a trusted source and has not changed since it was signed. Model scanning is a content and behaviour control: it inspects the artifact for suspicious weights, payloads, unsafe serialization patterns, or embedded logic that could be dangerous even if the file is “official.”
The practical difference is that signing answers “who produced this, and was it altered?” while scanning answers “what is inside this artifact, and does it look unsafe?” That distinction matters because a signed model can still be malicious, and a clean-looking file can still be tampered with after signing if downstream handling is weak.
- Signing is strongest when you need chain-of-custody, release control, and trusted distribution.
- Scanning is strongest when you need to detect embedded risk before deployment, import, or deserialization.
- They are complementary, not interchangeable, because integrity does not prove safety.
Why both controls belong in the same release path
A secure ML release pipeline should treat signing as a trust gate and scanning as a content gate. If you only sign, you may reliably distribute the wrong model. If you only scan, you may inspect an artifact without knowing whether it is the approved release or whether it was swapped in transit.
This is where the broader supply-chain lesson matters. Artifact authenticity and artifact safety are separate checks, and both should occur before the model reaches evaluation, staging, or production use. In practice, that means validating the signer or release source, then scanning the artifact itself, then enforcing policy on where the model can be loaded and by whom.
For teams building release hygiene around machine learning artifacts, the operational risk is not abstract. NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations such as code, config files, and CI/CD tools. That same pattern of weak artifact handling is exactly why signed artifacts still need inspection and why scanning alone cannot establish trust. Ultimate Guide to NHIs
Risk and Threat Considerations
The main failure mode is false confidence. A signed model can still contain malicious deserialisation logic, embedded backdoors, or unsafe dependencies, while an unsigned but scanned artifact can still be substituted before use if provenance is not enforced. Attackers benefit from any workflow that treats one control as a substitute for the other.
Failure mechanism: The signing process proves origin and integrity for the specific artifact that was signed, but it does not inspect the runtime consequences of loading that artifact; scanning inspects the artifact’s structure and content, but it does not prove that the artifact came from the expected producer or remained untouched after inspection.
Impact: Teams can deploy a trustworthy-looking model that is still unsafe, or a safe-looking model that is not authentic, leading to model tampering, supply-chain compromise, unsafe execution paths, and poor incident attribution.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 8 — Audit Log Management | Signed and scanned model releases need auditable approval and integrity evidence. |
| CIS 3 — Data Protection | Model artifacts can embed sensitive or unsafe content that scanning should surface before use. | |
| CIS 16 — Application Software Security | Model scanning and signing are software-supply-chain controls for delivered artifacts. | |
| Recommendation — Log model approvals, signature checks, and scan results so release integrity decisions are auditable. Inspect model artifacts before deployment to reduce exposure from hidden or unsafe embedded content. Validate software artifacts with integrity checks and content review before promoting them. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Signing protects integrity, while scanning reduces the risk of unsafe model content entering use. |
| PR.PT — Protective Technology | Release pipelines need technical controls that enforce trusted model handling. | |
| GV.SC — Cyber Supply Chain Risk Management | Model signing and scanning are supply-chain controls for third-party or exported ML artifacts. | |
| Recommendation — Protect model artifacts with integrity checks and content inspection before operational use. Enforce trusted artifact handling controls that block unverified or unsafe models from deployment. Apply supply-chain controls that verify artifact provenance and inspect delivered models for risk. | ||
| NIST AI RMF | GV — Govern | Model release decisions need governance over provenance, safety review, and approval criteria. |
| MP — Measure and Manage | Teams should measure whether models are both trusted and inspected before deployment. | |
| MAP — Map | Artifact provenance and content risk are part of understanding model trust boundaries and dependencies. | |
| Recommendation — Define governance that requires both provenance assurance and artifact safety review before release. Measure signing coverage and scanning coverage across the model lifecycle to reduce release risk. Map model provenance, dependencies, and inspection points before allowing deployment. | ||
Practitioner Guidance
What to verify: Treat signing as a release-control check and scanning as a pre-execution safety check. Before trusting a model, verify both the signature chain and the scan result, and make sure the scan was run on the exact artifact that will be deployed, not on an earlier copy or a repackaged derivative.
What good looks like: The release process produces an auditable trail that ties the approved model to a signer, a build or export event, and a scan result, with blocking controls if the artifact changes after either check.
Practitioner takeaway: Use signing to answer provenance questions and scanning to answer safety questions, because either control alone leaves a different class of ML supply-chain risk unaddressed.
Related resources from NHI Mgmt Group
- What is the difference between machine identity security and model security?
- What is the difference between model security and machine identity security?
- What is the difference between data poisoning and a backdoor in a machine learning model?
- What is the difference between machine identity security and human IAM?
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
