Attestation in Cybersecurity: Types, Uses & Best Practices

What is attestation? 

Attestation is a security process that enables one system or entity to prove its state or characteristics to another. This typically involves generating verifiable evidence about the software, hardware, or configuration of a device or environment. The primary goal is to ensure that systems are operating as expected and have not been tampered with. 

Attestation is important for building trust in distributed environments, where direct oversight and control are not always possible. The process of attestation involves multiple actors and steps, such as collecting measurements, generating cryptographic proofs, and transmitting these proofs to a party that can verify them. 

It is used in areas such as device security, cloud computing, and software supply chain risk management. By providing a way to establish and verify trust, attestation underpins secure interactions and decision-making in digital infrastructure.

Attestation in the Cyber Resilience Act (CRA)

The Cyber Resilience Act (CRA) introduces baseline security requirements for products with digital elements placed on the EU market. While the regulation does not mandate a single attestation protocol, it aligns with attestation concepts by requiring manufacturers to demonstrate the integrity, security, and update posture of their products throughout the lifecycle.

Attestation supports CRA compliance by enabling verifiable claims about device configuration, firmware integrity, and vulnerability status. For example, manufacturers can use attestation to prove that a device is running approved software versions, that secure boot is enforced, and that known vulnerabilities have been addressed. This evidence can be used during conformity assessments and ongoing compliance checks.

The CRA also emphasizes continuous risk management and incident handling. Attestation can feed these processes by providing up-to-date, machine-verifiable state information from deployed devices. This allows operators and regulators to validate security claims without relying solely on documentation or manual audits.

Attestation in software supply chain security

In software supply chains, attestation is used to prove how software was built, what it contains, and whether it meets defined security policies. Modern applications depend on many third-party components, build systems, and deployment pipelines, each introducing risk.

Common patterns for attestation include:

• Build attestation: During the build process, systems generate signed metadata that records inputs such as source code versions, dependencies, build tools, and environment details. Standards like in-toto and frameworks like SLSA define how to structure and verify this metadata. Verifiers can then confirm that artifacts were produced by trusted processes and have not been altered.
• Artifact integrity and provenance: Before deployment, systems can require proof that a container image or binary matches a known build and comes from an approved pipeline. This prevents unauthorized or tampered artifacts from entering production environments.
• Supply chain verification: At runtime, attestation can extend supply chain trust by verifying that deployed workloads still match their expected state. For example, a platform may require that only workloads with valid build and runtime attestations are allowed to run.

By making each step in the supply chain observable and verifiable, attestation reduces the risk of hidden modifications, compromised dependencies, and unauthorized changes. It enables automated policy enforcement based on cryptographic proof rather than implicit trust.

Key components of attestation

Attester

The attester is the system or component responsible for generating and providing evidence of its own state or integrity. This role typically belongs to a device, server, or software application that must prove it is operating as intended. The attester collects relevant data, such as firmware versions, software configurations, or runtime measurements, and packages this information into a report or cryptographic proof.

In practical terms, the attester is often equipped with secure hardware or software modules that prevent tampering and ensure the accuracy of the collected evidence. The integrity and trustworthiness of the attester are critical, as any compromise at this stage undermines the entire attestation process. Secure boot processes, trusted platform modules (TPMs), and isolated execution environments are commonly used to strengthen the attester’s reliability.

Verifier

The verifier is the entity responsible for validating the evidence provided by the attester. This could be a remote server, a management system, or a third-party service tasked with ensuring the attester’s claims are accurate and trustworthy. The verifier receives the attestation evidence, checks its authenticity, and compares it against known-good configurations or policies.

Effective verification involves cryptographic checks, such as signature validation and hash comparisons, to prevent forgery or manipulation. The verifier’s decision directly affects whether the attester is granted access, trusted for further operations, or flagged for remediation. The verifier acts as the gatekeeper for trust decisions.

Relying party

The relying party is the final decision-maker that acts based on the outcome of the attestation process. After the verifier assesses the evidence and renders a judgment, the relying party uses this information to determine whether to grant access, provide services, or initiate additional security checks. The relying party could be an IT administrator, a cloud service, or any system that depends on validated trust signals.

This separation of roles ensures that trust decisions are not made solely by the system under evaluation but are informed by independent verification. The relying party must have confidence in both the verifier’s integrity and the overall attestation process. Their actions, such as allowing network connections, deploying updates, or blocking compromised devices, are central to maintaining organizational security.

Evidence

Evidence is the collection of data points, such as measurements, configurations, or logs, that substantiate the claims made by the attester. This evidence is generated in a secure manner and may include cryptographic hashes of firmware, integrity measurements of software stacks, or detailed configuration states. The quality and scope of the evidence directly impact the reliability of attestation.

For evidence to be effective, it must be tamper-evident and relevant to the security properties being attested. Modern attestation systems use hardware roots of trust, secure boot logs, and runtime monitoring to generate evidence. This evidence is then transmitted to the verifier, where it serves as the basis for trust evaluation and subsequent decision-making by the relying party.

Types of attestation

Remote attestation

Remote attestation is a process by which a device or system proves its integrity to a remote verifier, often across a network. This type of attestation is widely used in distributed and cloud environments, where direct physical inspection of devices is not feasible. The attester collects measurements or status information and sends it securely to the verifier, which checks the data against trusted baselines.

Remote attestation: 

• Enables organizations to assess the trustworthiness of endpoints, virtual machines, or IoT devices before granting them access to sensitive resources.
• Supports enforcing security policies at scale, especially when managing fleets of devices that are geographically dispersed or outside direct organizational control.

Hardware-based attestation

Hardware-based attestation uses specialized security hardware, such as trusted platform modules (TPMs) or secure enclaves, to generate and protect attestation evidence. These hardware components resist tampering and provide a root of trust for the attestation process. TPMs can securely store cryptographic keys and record measurements of the boot process, while secure enclaves isolate sensitive computations from the rest of the system.

The primary advantage of hardware-based attestation is its resistance to software-based attacks: 

• By anchoring trust in dedicated hardware, organizations can be more confident that evidence reflects the true state of a device, even in the presence of malware. 
• This approach is used in enterprise endpoints, critical infrastructure, and cloud computing platforms.

Software-based attestation

Software-based attestation relies on software mechanisms to generate and validate evidence of system integrity. This approach does not require specialized hardware, making it more accessible for environments where hardware upgrades are impractical or cost-prohibitive. The attestation process typically involves executing predefined checks, collecting system measurements, and applying cryptographic techniques to protect the integrity of the results.

While software-based attestation is easier to deploy, it is generally less robust than hardware-based methods:

• Attackers with sufficient privileges may be able to bypass or manipulate the software responsible for evidence generation. 
• Software-based attestation is often used in less sensitive contexts or alongside stronger, hardware-backed mechanisms.

Hybrid models

Hybrid models combine hardware-based and software-based attestation techniques to balance security and flexibility. In a hybrid approach, hardware roots of trust may be used to secure the most critical parts of the attestation process, such as key storage and initial measurements, while software components handle additional checks or policy enforcement. 

This layered strategy:

• Enables broader coverage and adaptability to different operational environments.
• Is used in complex environments, such as multi-cloud deployments and IoT ecosystems, where devices have varying capabilities. 

By leveraging both hardware and software strengths, organizations can achieve higher assurance without sacrificing scalability or ease of deployment. 

Key attestation use cases 

1. Device integrity verification

Device integrity verification uses attestation to confirm that a device’s firmware, software, and configuration have not been altered from their trusted state. This is critical for organizations managing large fleets of endpoints, IoT devices, or remote systems. Attestation provides a scalable way to detect unauthorized changes, malware, or unauthorized software installations before they impact network security.

By regularly attesting device integrity: 

• Organizations can implement automated responses, such as quarantining compromised devices or triggering security alerts. 
• This approach reduces the risk of undetected breaches.
• It supports compliance with regulations that mandate continuous monitoring of device health and security posture.

2. Secure boot validation

Secure boot validation uses attestation to ensure that a system starts only with trusted software and firmware. During the boot process, measurements are taken of each component as it loads, and these measurements are securely recorded. Attestation evidence is then generated to demonstrate that the boot sequence has not been tampered with.

This technique is used in modern operating systems, embedded devices, and cloud infrastructure:

• It helps prevent the execution of unauthorized code at startup.

• Secure boot validation helps mitigate persistent threats, such as rootkits and bootkits, by blocking their ability to gain control before the operating system loads. 
• Attestation enables remote or automated verification of boot integrity.

3. Cloud workload trust

Cloud workload trust uses attestation to verify that virtual machines, containers, and serverless workloads run in a known and approved state. Before a workload is scheduled or allowed to access resources, the platform can require evidence about its image, configuration, and runtime environment. This includes checks on base images, applied patches, and security settings.

Cloud providers and orchestration systems integrate attestation into admission control. For example:

• A Kubernetes cluster may only admit pods with valid image provenance and signed build attestations. 
• Confidential computing environments extend this by attesting the integrity of the underlying host and enclave before releasing secrets. 
• This ensures that sensitive data is exposed only to verified workloads.

4. Identity and authentication

Identity and authentication use attestation to strengthen how entities prove who they are and whether they should be trusted. Instead of relying only on credentials like passwords or tokens, systems can require proof of device or workload integrity as part of the authentication process. This binds identity to a verified state.

A common pattern is device-based access control:

• When a user attempts to authenticate, the system also requests attestation evidence from their device. 
• Access is granted only if the device meets defined security policies, such as running approved software or having disk encryption enabled. 
• This reduces the risk of compromised endpoints being used to access sensitive systems.

Best practices for implementing attestation

Here are some important things to consider to ensure that attestation is complete and reliable.

1. Anchor attestation in supply chain risk management

Attestation should map directly to supply chain risks rather than exist as an isolated security control. Organizations should begin by identifying critical assets, trust boundaries, and high-risk stages within the software lifecycle, including source code repositories, build systems, artifact registries, and deployment environments. Attestation requirements should then be designed to address the specific risks associated with each stage:

1. Start by identifying critical assets, trust boundaries, and high-risk stages such as code ingestion, build, and deployment. 
2. Define what must be proven at each stage, such as source integrity, build isolation, or artifact origin.
3. Tie attestation policies to risk levels. For example, require stronger guarantees for production workloads than for development environments. 

This ensures that verification effort is focused where compromise would have the highest impact. It is also useful to align attestation with existing risk frameworks, such as NIST or ISO guidance. 

2. Implement evidence-based attestation

Attestation is only as useful as the evidence it provides. Security decisions should be based on concrete, verifiable measurements rather than assumptions or self-reported status. Effective evidence includes cryptographic hashes, dependency information, build parameters, runtime configurations, and other data that directly supports integrity verification:

1. Collect measurements that directly support security decisions, such as hashes of binaries, dependency lists, build parameters, and runtime configurations. 
2. Avoid vague or incomplete signals that cannot be independently verified. 
3. Ensure evidence is structured, signed, and tamper-evident. 
4. Use standardized formats where possible so different systems can interpret and validate the data consistently. Evidence should be easy to audit and replay, enabling automated checks and forensic analysis when needed. 
5. Define clear schemas and validation rules for evidence. 

This prevents inconsistencies across teams and tools. 

3. Automate attestation in the CI/CD pipeline

Manual attestation processes do not scale and often introduce gaps in coverage. Integrating attestation directly into CI/CD pipelines ensures that evidence is generated consistently and verified automatically throughout the software lifecycle. This reduces operational overhead while strengthening security controls:

1. Integrate attestation generation and verification directly into CI/CD workflows. 
2. Ensure that build systems automatically produce signed attestations as artifacts are created.
3. Set up deployment systems to enforce verification before release.

This approach enables policy enforcement without slowing down delivery. For example, a pipeline can block promotion if required attestations are missing or invalid. Automation ensures consistency across teams and environments, reducing the risk of human error. In mature setups, attestation checks are treated as first-class pipeline gates, similar to tests or security scans. 

4. Use cryptographic integrity and provenance

Strong cryptographic protections are essential for trustworthy attestation. Without cryptographic validation, evidence can be modified, forged, or replayed by attackers. Attestation data should be digitally signed and linked to trusted identities, systems, or hardware roots of trust. Provenance information should establish a verifiable chain connecting source code, build systems, artifacts, and deployed workloads. This allows organizations to confirm not only that an artifact is authentic but also how it was produced and by whom:

1. Sign all attestation data using keys protected by hardware or secure key management systems. This prevents forgery and ensures that evidence can be traced back to a trusted source. 
2. Ensure key management as part of this practice. Rotate keys regularly, protect them from unauthorized access, and establish clear trust anchors.
3. Ensure provenance clearly links artifacts to their origin, including the build system, inputs, and process used. 

This creates a verifiable chain from source code to deployed workload. Systems consuming attestations should validate signatures and check that provenance meets defined trust policies.

5. Align attestation with SBOM and vulnerability management

Attestation should work alongside software bill of materials (SBOM) and vulnerability management programs rather than operate independently. While attestation verifies integrity and provenance, SBOMs provide visibility into software components, and vulnerability management identifies known security risks. Together, these controls provide a more complete view of software trustworthiness:

1. Use SBOM data as part of attestation evidence to show what components are included in an artifact. This enables more precise risk evaluation during verification.
2. Combine attestation with vulnerability scanning results to enforce security policies. For example, block deployment if attestations show unresolved critical vulnerabilities. 
3. Keep attestation, SBOM, and vulnerability data aligned to ensure that trust decisions reflect both integrity and known risk exposure.

How to move from self-attestation to verifiable proof with Mend.io

Attestation is only as strong as the evidence behind it, and regulators are no longer accepting good intentions or signed self-attestations as proof. Mend.io continuously discovers, tests, and documents the security posture of your code and the AI inside it, turning frameworks like the EU AI Act, the Cyber Resilience Act (CRA), Executive Order 14028, NIST, OWASP, and ISO 42001 from static checklists into audit-ready evidence generated on every build. By closing the gap between code and AI, Mend.io gives security and compliance teams the structured, verifiable artifacts they need to prove conformity to their board, their auditors, and their regulators.

Key capabilities of Mend.io:

• Continuous inventory with SBOM and AI-BOM: Mend.io maintains an always-on, machine-readable software bill of materials (CycloneDX, SPDX) and AI-BOM across code, libraries, containers, dependencies, models, agents, and system prompts, so you never have to reconstruct inventory before an audit.
• Attestation outputs ready to file: The platform produces EO 14028 attestation form inputs, CRA conformity evidence, and EU AI Act technical documentation excerpts as structured, exportable artifacts, mapped to the framework that requires them.
• Reachability-based testing and prioritization: Reachability analysis surfaces exploitability-prioritized findings so you remediate what is actually exploitable, satisfying NIST SSDF and CRA vulnerability-handling expectations.
• Automated, continuous evidence generation: Reachability-based code testing and automated AI red teaming run on every build rather than on a six-month audit cadence, with each test producing evidence tied to the relevant control.
• Control mapping and audit logging: Mend.io maps findings directly to NIST SSDF, NIST AI RMF, ISO 42001, ISO 27001, CRA Annex I, and OWASP, and keeps an immutable audit log of detection, prioritization, remediation, and policy enforcement.
• Unified governance with AI-SPM: AI-SPM connects discovery, findings, compliance obligations, and remediation status in one governed workflow, giving you a single, defensible posture view across the code layer and the AI layer.

Turn your next audit into your easiest one. See how Mend.io produces verifiable, audit-ready attestation evidence on every build.