CoRIM and RATS Explained: Reference Manifests, EAT Tokens, Attestation

Remote attestation is how a device proves, with signed evidence, what firmware and software it is actually running. The IETF RATS architecture (RFC 9334) names the parties: an Attester produces Evidence, a Verifier appraises it against Reference Values and Endorsements, and a Relying Party acts on the result. An Entity Attestation Token (RFC 9711) is a common container for that evidence, and a Concise Reference Integrity Manifest (CoRIM, still an IETF draft) is the signed CBOR file a manufacturer publishes so the Verifier knows what "good" looks like.

This guide goes one level deeper than our posts on TCG DICE, Caliptra, SWID and CoSWID tags and uSWID in UEFI firmware. Those posts explain how a device builds its identity and how a firmware image describes its own contents. This one explains the plumbing in between: the roles, the token formats, the manifest that carries expected measurements, and the verifier that compares them. We read RFC 9334, RFC 9711, RFC 9393, RFC 9781, RFC 9782, RFC 9783, RFC 9683, draft-ietf-rats-corim-11, the EAR, AR4SI and endorsements drafts, the Veraison documentation and source READMEs, and the TCG DICE work group material. Where a document is still a draft, we say so and give its version and date.

Key takeaways

• RFC 9334 (January 2023) defines seven roles: Attester, Verifier, Relying Party, Endorser and Reference Value Provider, plus the Verifier Owner and Relying Party Owner who write policy. It is an architecture, not a wire protocol.
• Two topologies cover most deployments. In the passport model the Attester carries its own Attestation Result to the Relying Party. In the background check model the Relying Party forwards Evidence to a Verifier and gets the result back.
• An Entity Attestation Token (RFC 9711, April 2025) is a CWT or JWT with attestation claims such as eat_nonce, ueid, dbgstat, swversion, manifests, measurements and submods. The same claims have JSON names and CBOR integer keys.
• CoRIM is the supply chain side of attestation. It is a CBOR map, usually signed with COSE_Sign1, that bundles CoMID tags (hardware and firmware reference values and endorsements), CoSWID tags (RFC 9393) and CoTL tags (which tags are active). As of 24 October 2026 the current version is draft-ietf-rats-corim-11, dated 6 July 2026, in working group last call. It is not yet an RFC.
• A CoRIM aware Verifier works in phases: validate inputs, add Evidence to an Appraisal Claims Set, corroborate it against Reference Values, add Endorsed Values when conditions match, then apply policy and issue an Attestation Result.
• DICE layering turns each boot stage's measurement into a certificate extension. A CoMID for a DICE device lists the expected digest, security version number and flags for each layer, and the Verifier matches the two.
• Veraison is an open source verifier project with Go and Rust CoRIM libraries, a cocli command line tool and reference attestation services. Its own docs mark its Docker deployment as unsuitable for production and its CoRIM libraries as alpha.
• SBOMs, CoSWID tags, CoRIMs and attestation results answer different questions. Keep them in one inventory keyed by the same component identity so you can go from "this digest failed appraisal" to "this firmware build and these components".

What is remote attestation, and what roles does RATS define?

Remote attestation is a way for one party to decide whether to trust another based on evidence about its internal state, rather than on a password or a network location. The device measures its own boot chain or runtime, signs those measurements with a key the outside world can trace to hardware, and sends them to someone who knows what the measurements should be.

RFC 9334, "Remote ATtestation procedureS (RATS) Architecture", was published as an Informational RFC in January 2023. It does not define a protocol or a message format. It defines vocabulary, roles, the messages those roles exchange, and the trust each role must place in the others. That vocabulary is now used by RFC 9711, by the CoRIM draft, by the TCG DICE documents and by most confidential computing attestation services, so it is worth learning first.

The roles

The RFC is careful to say these are roles, not boxes. One entity can play several. A cloud provider can be Endorser, Verifier and Relying Party at once. A device can be an Attester to one service and a Verifier for a peripheral attached to it.

Attesting and target environments

Section 3.1 of RFC 9334 splits an Attester into two kinds of environment. The Target Environment is the thing being measured, such as a bootloader or a kernel. The Attesting Environment is the thing doing the measuring and signing. The trick of attestation is that the Attesting Environment must be harder to subvert than the Target Environment, or the measurements mean nothing.

Layered attestation and composite devices

Section 3.2 describes layered attestation. Each boot stage measures the next before handing over control, so a ROM measures the bootloader, the bootloader measures the kernel, and so on. The RFC's own example is a device with a BIOS in read only memory, a bootloader and an operating system kernel. Claims about the bottom layer cannot be self asserted, so an Endorser vouches for it. Claims about the upper layers are collected by the layer below. This is exactly the structure TCG DICE implements in hardware, which is why DICE devices fit RATS so neatly.

Section 3.3 describes composite devices: a chassis with several line cards, a server with a CPU, a GPU and a network card, each with its own Attesting Environment. A lead Attester collects Evidence from the others and conveys it together. EAT's submods claim and the CoRIM draft's notion of a Composite Attester both exist to represent this shape.

Conceptual messages

RATS names five conceptual messages. They are "conceptual" because the RFC does not fix their encoding.

CoRIM is a format for the second and third messages. EAT is most often used for the first and fourth.

What are the passport and background check models, and when is each used?

Section 5 of RFC 9334 describes two topological patterns. Both involve the same roles; they differ in who talks to the Verifier.

In the passport model, the Attester sends Evidence to the Verifier, gets an Attestation Result back and treats it as opaque. It then presents that result to one or more Relying Parties, the way a citizen presents a passport at an immigration desk. The Relying Party only has to parse the Attestation Result, never the raw Evidence. The RFC notes a consequence: in this model standardising the Attestation Result format matters more than standardising Evidence.

In the background check model, the Attester sends Evidence to the Relying Party, which forwards it unopened to a Verifier and receives the Attestation Result directly, the way an employer checks a candidate's references. The Relying Party never needs an Evidence parser, so any Evidence format works as long as it can be wrapped in the access protocol.

Section 5.3 adds that real systems mix them. One device can use the passport model to join a network and the background check model to unlock a secret, and a Relying Party can hand the result back to the Attester for reuse elsewhere. The TEEP architecture for trusted application management, cited in the RFC, uses exactly that combination.

Freshness

Evidence that was true an hour ago may not be true now. Section 10 of RFC 9334 lists three ways to establish when Evidence or a result was produced:

1. Synchronised, trustworthy clocks and signed timestamps.
2. Nonces: the Verifier or Relying Party sends a random challenge and the Attester includes it in signed Evidence.
3. Epoch IDs: a trusted source distributes changing epoch values that the Attester includes.

The RFC is frank that a race always exists, because state can change the instant after Evidence is signed. Policy decides how old is too old. EAT's eat_nonce claim implements the second option and requires at least 64 bits of entropy.

What is an Entity Attestation Token (RFC 9711)?

RFC 9711, "The Entity Attestation Token (EAT)", was published as a Standards Track RFC in April 2025. An EAT is a signed claims set. Section 3 states that in this document an EAT is always a CBOR Web Token (CWT, RFC 8392) or a JSON Web Token (JWT, RFC 7519), and that it must have authenticity and integrity protection. In practice that means a COSE signature for CBOR or a JWS signature for JSON.

EAT is a framework. RFC 9711 defines claims and encodings, then expects a profile to say which claims a given use case requires, which encoding, which signature algorithms and how freshness works. Section 1.3 ties EAT to the RATS model directly: an EAT can carry Evidence from an Attester, and an EAT can also carry an Attestation Result from a Verifier.

The claims

Each EAT claim has a JSON name and a CBOR integer key. The keys below are from the consolidated CDDL in RFC 9711.

Standard CWT and JWT claims such as iss, iat, exp and cnf can be used alongside these. RFC 9711 also defines iat restrictions for EAT (no floating point).

Two claims matter most for supply chain readers. Section 4.2.15 says the manifests claim carries manifests created by the software manufacturer, unmodified, so the Verifier can check them. If a payload CoSWID is used it must be a payload CoSWID. Section 4.2.16 says the measurements claim carries data created on the device by processes that inventory or measure the software, and if it is a CoSWID it must be an evidence CoSWID. That split between manufacturer statements and device measurements mirrors the split between CoRIM and Evidence one level up.

CBOR and JSON encodings

RFC 9711 defines EAT-CBOR-Token and EAT-JSON-Token at the top level. The CBOR form is a CWT, tagged or untagged, signed with COSE. The JSON form is a JWT. Nested tokens can mix the two: a JSON EAT can carry a CBOR submodule token and the reverse.

Three related RFCs fill in the edges:

• RFC 9782 (May 2025) registers media types such as application/eat+cwt, application/eat+jwt, application/eat-bun+cbor, application/eat-bun+json, application/eat-ucs+cbor and application/eat-ucs+json, each of which can carry an eat_profile parameter. That lets an HTTP API negotiate exactly which profile it accepts.
• RFC 9781 (May 2025) defines a CBOR tag for Unprotected CWT Claims Sets (UCCS). A UCCS has no signature of its own and is only safe when a secure channel, such as an attested TLS session, already provides integrity and authenticity.
• Section 5 of RFC 9711 defines detached EAT bundles: an EAT that carries digests of claims sets sent alongside it, useful when a large claims set is produced by a different component from the one that signs.

What a small EAT looks like

The JSON below is illustrative, written in RFC 9711 claim names so you can see the shape. It is not taken from any product.

{
  "eat_profile": "tag:example.com,2026:widget-evidence",
  "eat_nonce": "AAECAwQFBgcICQoLDA0ODw",
  "ueid": "AZj1Ck_2waBASCJjpnpaUsg",
  "oemid": 32473,
  "hwmodel": "d2lkZ2V0LXJldjM",
  "swname": "widget-fw",
  "swversion": ["3.4.1", 16384],
  "dbgstat": 2,
  "submods": {
    "bootloader": {
      "swname": "widget-bl",
      "swversion": ["1.9.0", 16384]
    }
  }
}

A real token would be signed and the Verifier would check the signature first, then the nonce, then the claims. The numbers here follow RFC 9711 conventions: dbgstat value 2 is "disabled since boot", and the second element of swversion is a CoSWID version scheme (16384 is semantic versioning).

Profiles in the wild

RFC 9783 (June 2025) is one published EAT profile: the Platform Security Architecture (PSA) attestation token. It is an Informational RFC published as an Independent Submission, not an IETF standard, and its abstract says so. It requires claims such as a nonce, an instance ID, an implementation ID and a security lifecycle state, and it describes measured software components. The CoRIM draft's worked example uses this profile, which makes it a convenient reference when you read the two documents together.

What is CoRIM and CoMID, and how do they relate to CoSWID?

A Concise Reference Integrity Manifest is a CBOR document a supply chain actor publishes so that Verifiers know what to expect from an Attester. The draft's introduction puts the goal in one line: to describe expected Attester state to Verifiers. It carries Reference Values (expected measurements) and Endorsements (statements about the device that do not appear in Evidence, such as certification status).

Current status of the draft

The datatracker page for draft-ietf-rats-corim, fetched on 24 October 2026, shows:

So CoRIM is mature enough that implementations exist and the working group is in last call, but it is not an RFC, CBOR tag and media type assignments are still provisional, and the wire format has changed between versions. The Veraison cocli README says plainly that manifests issued by some hardware vendors use the older wire format, up to draft -06, and it publishes a separate compatibility build to read them. Plan for version skew.

The CoRIM map

A CoRIM is a CBOR map with integer keys. Section 4.1 of the draft defines it:

The unsigned form is wrapped in CBOR tag 501. The draft allows unsigned CoRIMs only when a secure channel or an enveloping signed document provides authenticity, and requires the origin to be recorded with the manifest signer role.

The signed CoRIM

Most published CoRIMs are signed. Section 4.2 wraps the CoRIM in a COSE_Sign1 structure (CBOR tag 18). The protected header must carry the algorithm and either a content type of application/rim+cbor (when the CoRIM itself is the payload) or the hash envelope parameters (when the payload is a digest of the CoRIM, useful for large files and transparency logs). It must also carry signer metadata, either as CWT Claims (iss, sub, exp, nbf, using RFC 9597 header parameter 15) or in the older corim-meta map (header parameter 8). If both are present they must agree.

The signing key is the root of the whole exercise. A CoRIM tells your Verifier which firmware digests to accept. Whoever controls the CoRIM signing key controls what your fleet will treat as genuine.

CoMID: the reference values and endorsements

CoMID, the Concise Module Identifier, is the tag that carries hardware and firmware facts. It sits inside the CoRIM as CBOR tag 506. Its top level has a language, a tag-identity (ID and version), optional entities, optional linked-tags and a required triples map.

The draft borrows the idea of a triple from RDF: a subject, an implied predicate and an object. In CoMID the subject is usually an environment, the predicate is the triple type, and the object is a set of measurements or keys.

The subject of a triple is an environment-map with up to three parts: class (shared by every unit of a model), instance (one unit, such as a UEID) and group. The class-map holds class-id, vendor, model, layer and index. Layer and index are what let a CoMID say "the second component in boot layer one".

The object is a list of measurement-map entries. Each one has an optional mkey (which measured element), a required mval, and an optional authorized-by list of keys. The mval is a measurement-values-map, and its fields are where the useful detail lives:

CoTL: which tags are live

The third tag type is the Concise Tag List (CoTL, CBOR tag 508). A CoTL lists tag identities and a validity window, and acts as a switch: when Verifier policy requires CoTLs, a tag is ignored until a CoTL activates it, and all tags in a CoTL activate together or not at all. This is how a vendor can publish next month's firmware reference values in advance and turn them on when the rollout starts, or retire a set atomically.

Profiles and extensions

CoRIM has explicit extension points (CDDL sockets) and a profile mechanism. Section 4.1.4 says a profile may constrain or extend types but must not change the base semantics, must be publicly documented, and must say at least how verification keys are represented and tied to the Attesting Environment. Any change to a profile, however small, is a new profile with a new identifier. A separate draft, Concise Trust Anchor Stores (CoTS), is being defined as a CoRIM extension for distributing trust anchors.

How CoRIM relates to CoSWID (RFC 9393)

RFC 9393, "Concise Software Identification Tags", was published in June 2023 as the CBOR form of ISO/IEC 19770-2 SWID tags. A CoSWID describes a software component: name, version, creator, files and their hashes. RFC 9393 distinguishes payload content (what the software publisher says was shipped) from evidence content (what a discovery process found on the device).

CoRIM reuses CoSWID rather than reinventing it. A CoRIM's tags array can hold CoSWID tags directly (CBOR tag 505 around the CoSWID bytes), and a CoMID can link an environment to CoSWIDs with coswid-triples. The rough division of labour is:

• CoSWID describes software: what is in this package, file by file.
• CoMID describes hardware and firmware environments: what this boot layer should measure as, which keys it uses, what it is certified for.
• CoRIM is the signed envelope that carries both, plus CoTLs, from one supply chain actor to a Verifier.

Our CoSWID post covers the tag format itself, and the uSWID post covers embedding CoSWID inside UEFI firmware images.

Related drafts you will meet

How does a Verifier use CoRIM? The appraisal phases

Section 8 of the CoRIM draft describes a reference Verifier so that implementations behave consistently. The core data structure is the Appraisal Claims Set (ACS): a working record of claims about the Attester, each tagged with the authority that asserted it.

The note under Table 1 of the draft is the important rule: if Evidence is not matched by the manufacturer's Reference Values, the manufacturer's claims do not enter the ACS. Silence is not approval.

A worked example from the draft

Section 8.2.6 walks through a device from a fictitious vendor, Acme, using the PSA profile:

1. Acme publishes a CoRIM with one CoMID containing two reference triples for the same class ID. Both describe a component named "PRoT". One expects a SHA-256 digest ending 86aa, the other a digest ending 5065. Two acceptable states, perhaps two firmware releases.
2. A certification body publishes its own CoMID with a conditional endorsement triple: if the Attester has that implementation ID and the "PRoT" digest ending 86aa, add a claim that it holds a specific security certification.
3. The device sends Evidence. Phase 2 adds its claims to the ACS. Phase 3 finds that its "PRoT" digest matches one of Acme's reference triples and adds corroborated claims under Acme's authority. Phase 4 checks the certifier's condition and, only if the device reported the 86aa digest, adds the certification claim under the certifier's authority.

A device running the other firmware release (5065) is still corroborated by Acme, but it does not inherit the certification. Two supply chain actors contributed independent statements, and the Verifier kept track of who said what. That is the problem CoRIM exists to solve.

What comes out: attestation results

The RATS architecture leaves the result format open. The EAR draft fills it with an EAT profile. An EAR names the verifier, the issue time, the policy used and, per submodule, an ear_status from four tiers (none, affirming, warning, contraindicated) plus a trustworthiness vector covering instance identity, configuration, executables, file system, hardware, runtime opaque, storage opaque and sourced data. AR4SI reserves value ranges for each tier: 2 to 31 for affirming, 32 to 95 for warning and 96 to 127 for contraindicated, with negative ranges for non standard reasons. The draft's own example shows an "executables" value of 96 (contraindicated) next to "hardware" 2 (affirming): genuine hardware running code the Verifier does not accept.

How does DICE layering produce evidence that a Verifier compares with CoRIM?

TCG DICE (Device Identifier Composition Engine) gives a device a layered identity from a small hardware block. Our DICE post covers the derivation in depth; here is the part that touches CoRIM.

1. At reset, the DICE hardware reads a Unique Device Secret (UDS) and measures the first mutable code (Layer 0).
2. It combines the UDS with that measurement to produce a Compound Device Identifier (CDI) for Layer 0, then locks the UDS away.
3. Layer 0 derives a key pair from its CDI. Its public key, certified by the manufacturer, is the DeviceID.
4. Layer 0 measures Layer 1, combines its own CDI with Layer 1's measurement to produce Layer 1's CDI, derives Layer 1's key, and issues a certificate for that key that includes Layer 1's measurement.
5. This repeats up the boot chain. Each certificate carries the measurements of the layer it certifies.

Change any byte of a lower layer and every CDI above it changes, so every key above it changes. A Verifier that trusts the DeviceID can walk the certificate chain and read off what each layer measured.

The TCG DICE Attestation Architecture defines an X.509 extension, DiceTcbInfo, to carry those measurements. The Veraison project's DICE notes reproduce its fields: vendor, model, version, svn, layer, index, fwids (a list of hash algorithm and digest pairs), flags (not configured, not secure, recovery, debug), vendorInfo and type. Several entries can sit in one certificate as a DiceTcbInfoSeq.

Line those fields up with CoMID and the fit is obvious:

The Veraison cocli repository ships a template called comid-dice-refval.json that follows this shape. It defines two reference value entries: one for class model "FMC" at layer 0, index 0, with one SHA-256 digest and an exact SVN of 10; and one for model "L1" at layer 1, index 0, with two acceptable digests and an exact SVN of 2. So a Verifier holding that CoMID would accept Layer 1 Evidence reporting either digest at SVN 2, and nothing else.

One caveat: the authoritative mapping between DICE TCB Info and CoRIM lives in the TCG "DICE Endorsement Architecture for Devices" (version 1.0, revision 0.38, November 2022, per the CoRIM draft's references) and in DICE profiles. We could not fetch that PDF directly because the TCG site rate limited our requests, so the table above reflects field names and the Veraison template rather than the TCG text.

What does an open source verifier look like? Veraison

Veraison (the name comes from "VERificAtIon of atteStatiON") is an open source project that builds attestation verification components. The CoRIM draft's implementation status section lists it as a Veraison Project under the Linux Foundation, licensed Apache 2.0. Its project overview states the focus: components flexible enough for many deployments, specialised through plugins and policy modules.

The pieces relevant to this post:

The services expose two APIs that map directly onto RATS roles. The endorsement provisioning API accepts a CoRIM by POST to a /submit endpoint; this is where Reference Value Providers and Endorsers feed the Verifier. The verification API is challenge response: a client POSTs to create a session and receives a nonce, POSTs Evidence to the session, and reads back an Attestation Result. The project overview says appraisal policy can be written in Rego, the Open Policy Agent language, and results are signed JSON. The EAR draft's own example names Veraison as the developer in ear_verifier_id, which tells you the project and the draft grew together.

The overview lists supported evidence types as EAT tokens (with PSA profiles as a test set), tokens from a confidential computing architecture, DICE layered Evidence (noting it does not follow any single DICE protocol), and TPM based tokens. Its provisioning scope covers bulk provisioning, firmware upgrade relationships, targeted revocation, multi tenancy and audit trails, though the overview is a statement of scope, not a feature list for any given release.

Read Veraison as a reference implementation and a teaching tool. It is the fastest way to see every RATS role working on one machine. For production attestation, you would either harden and operate it yourself or use a verifier your platform provider runs, and the CoRIM draft's own security considerations apply either way.

SBOM, CoSWID, CoRIM and an attestation result compared

These four artifacts are often confused because they all describe "what is in the thing". They answer different questions for different readers.

Timeline: the RATS document family

Step by step: read a sample CoRIM and map it to your firmware

This walkthrough uses Veraison's cocli and its sample data. Nothing here touches a real device, and the keys are the test keys shipped in the repository. Do not use them for anything real.

1. Install the tools

You need Go (the veraison/corim README lists Go 1.22) and git.

go version
go install github.com/veraison/cocli@latest
cocli --help

# sample templates, keys and CoRIMs live in the cocli repository
git clone https://github.com/veraison/cocli.git
cd cocli
ls data/comid/templates data/corim/templates data/keys

If you need to read manifests produced with the older wire format, the README documents a separate build:

go install github.com/veraison/cocli@v0.0.1-compat

2. Build a CoMID from the DICE template and read it back

mkdir -p /tmp/corim-lab
cat data/comid/templates/comid-dice-refval.json

cocli comid create \
  --template data/comid/templates/comid-dice-refval.json \
  --output-dir /tmp/corim-lab

cocli comid display --file /tmp/corim-lab/comid-dice-refval.cbor

The JSON template is the readable form; the .cbor file is what a Verifier would ingest. In the template, note the environment.class block (UUID class ID, model, layer, index) and the measurements block (op flags, digests, SVN). Those are the fields you will map to firmware.

3. Wrap it in a CoRIM, sign it, verify it

cat data/corim/templates/corim-full.json

cocli corim create \
  --template data/corim/templates/corim-full.json \
  --comid /tmp/corim-lab/comid-dice-refval.cbor \
  --output /tmp/corim-lab/unsigned-corim.cbor

cocli corim sign \
  --file /tmp/corim-lab/unsigned-corim.cbor \
  --key data/keys/ec-p256.jwk \
  --meta data/corim/templates/meta-full.json \
  --output /tmp/corim-lab/signed-corim.cbor

cocli corim verify \
  --file /tmp/corim-lab/signed-corim.cbor \
  --key data/keys/ec-p256.jwk

The corim-full.json template shows the top level fields from the table earlier: a CoRIM ID, a dependent RIM locator with a SHA-256 thumbprint, a profile URI, a validity window and an entity with the manifest creator role. If any file name differs in the version you cloned, list the data directories and adjust; the README is the authority on current names.

For manifests signed with an X.509 chain, the README documents verifying against explicit trust anchors and, optionally, a CRL:

cocli corim verify --file signed-x5chain.cbor \
  --trust-anchors rootCA.der --crl issuer.crl

The veraison/corim README warns that when no trust anchor paths are supplied, verification falls back to the operating system certificate store, and that production deployments should pass explicit anchors. Take that advice. A CoRIM should chain to the manufacturer's CoRIM signing root, not to any web CA your laptop happens to trust.

4. Display and extract the tags

cocli corim display --file /tmp/corim-lab/signed-corim.cbor --show-tags

mkdir -p /tmp/corim-lab/out
cocli corim extract --file /tmp/corim-lab/signed-corim.cbor \
  --output-dir /tmp/corim-lab/out
ls /tmp/corim-lab/out

display prints the signer metadata and the CoRIM; --show-tags expands each embedded CoMID, CoSWID and CoTS. extract writes each tag to its own CBOR file so you can process them separately.

If you prefer to see raw CBOR diagnostic notation, any CBOR library will do. For example, with Python in an isolated virtual environment:

python3 -m venv /tmp/corim-lab/venv
/tmp/corim-lab/venv/bin/pip install cbor2
/tmp/corim-lab/venv/bin/python -I -c "import cbor2,sys,pprint; pprint.pprint(cbor2.load(open(sys.argv[1],'rb')))" /tmp/corim-lab/out/000000-comid.cbor

You will see integer keys where the JSON had names: 1 for tag identity, 4 for triples, 0 for reference triples, and so on, matching the tables in this post.

5. Map each measurement to a firmware component

Now do the step that most teams skip. For every reference triple, write down which firmware artifact it describes and where that artifact comes from.

Two acceptable digests at layer 1 is a decision someone made. Your records should say why the older digest is still allowed and when it will be removed (with a CoTL or a new CoRIM version).

6. Decide where reference values come from in your supply chain

Reference values are only as good as their source. Ask, for each layer:

Record which source you used for each layer next to the CoRIM ID and version. When an attestation fails, that record is what tells you whether the device changed or the reference did.

7. (Optional) Run the reference services locally

The veraison/services README describes a Docker based test deployment:

git clone https://github.com/veraison/services.git
cd services
make docker-deploy
source deployments/docker/env.bash
veraison status

It also states that this deployment is for development only, is not hardened and cannot handle high traffic. Use it to watch provisioning and verification happen end to end, then submit the CoRIM you built with cocli corim submit, passing the provisioning URL and the media type with the right profile parameter, as the cocli README shows.

Why firmware manifests and attestation evidence belong in the same inventory as SBOMs

Most organisations keep three disconnected records. Security teams have SBOMs for applications. Infrastructure teams have firmware versions in a hardware asset system, if anywhere. Attestation results, when they exist, live in the logs of whatever service checked them. The RATS model shows why that split hurts.

• An attestation failure is a supply chain question. When a Verifier reports that layer 1's digest does not match any reference value, the next questions are "which build is that digest from?" and "what is in that build?". Those answers live in your build records and SBOMs. Without a shared identifier, you cannot get from one to the other quickly.
• Reference values come from builds. If you produce your own boot or OS images, your CI already knows the digest of each artifact. Emitting the CoMID entry and the SBOM from the same pipeline step, keyed by the same release identifier, means the two can never drift.
• Vulnerabilities land on components, not digests. When a CVE lands in a firmware library or a bootloader component, you need to find every device class whose accepted reference values include an affected build, and you need to plan the CoTL or new CoRIM that stops accepting it. That is a join between SBOM data and CoRIM data.
• EAT already carries both. The manifests claim can carry payload CoSWIDs from the publisher, and the measurements claim can carry evidence CoSWIDs measured on the device. The token format assumes these belong together.
• Endorsements expire. Certifications cover specific versions. A conditional endorsement in a CoRIM is only as current as the inventory that tells you which versions you are actually running.

The practical shape: one inventory where each firmware or software release has a stable identifier (a purl, a CoSWID tag ID, or a CoRIM tag identity), and where the SBOM, the CoSWID or CoMID entries, and the latest attestation results for devices running it all hang off that identifier.

Common mistakes

• Treating attestation as authentication. A valid signature on Evidence tells you a genuine part produced it. Only appraisal against reference values tells you the part is running what you expect.
• Checking the signature and skipping freshness. Without a nonce, timestamp or epoch check, replayed Evidence from last month looks perfect.
• Accepting CoRIMs from anyone. A CoRIM is a list of digests your fleet will trust. Pin the signing roots per vendor and profile, pass explicit trust anchors, and do not fall back to the operating system store.
• Ignoring the profile. The draft says a processor that does not understand a CoRIM's profile must reject the whole CoRIM. Quietly ignoring unknown profiles turns a hard failure into silent acceptance.
• Never retiring reference values. Old firmware digests stay acceptable forever unless someone removes them. Use validity windows and CoTLs, and track when each accepted digest should go.
• Capturing "golden" values from a production unit. If that unit was already compromised, every comparison now passes for the wrong reason.
• Mixing draft versions. A Verifier built for draft -11 may not parse a manifest from draft -06. Record the draft version each producer and consumer supports.
• Forgetting debug and lifecycle state. Matching digests on a device with debug enabled is not the same as matching digests on a locked device. Check dbgstat in EAT, flags in DICE TCB Info and the corresponding CoMID flags.
• Treating the Verifier as a side service. The CoRIM draft's security considerations say the Verifier's code and configuration are part of the trusted computing base of every Attester and Relying Party it serves, and recommend memory safe languages, least privilege, secure defaults and audited changes.
• Keeping attestation results only in logs. Results that cannot be joined to firmware releases and SBOMs cannot drive patching.

FAQ

What is the difference between RATS and EAT?

RATS (RFC 9334) is an architecture: it names the roles, messages and trust relationships in remote attestation. EAT (RFC 9711) is a token format: a CWT or JWT with defined attestation claims. EAT is one way to encode the Evidence and Attestation Results that RATS describes.

Is CoRIM an RFC yet?

No. As of 24 October 2026 the latest version is draft-ietf-rats-corim-11, dated 6 July 2026, and the working group state is "In WG Last Call" with an intended status of Proposed Standard. Code points and media types are still provisional until the RFC is published.

What is the difference between CoRIM and CoMID?

CoRIM is the envelope: a signed CBOR map with an ID, a profile, a validity period and a list of tags. CoMID is one kind of tag inside it, carrying reference values and endorsements for hardware and firmware environments. A CoRIM can also carry CoSWID and CoTL tags.

How is CoRIM different from an SBOM?

An SBOM lists the components that went into a build so you can manage vulnerabilities and licences. A CoRIM lists the measurements a genuine device should report so a Verifier can decide whether to trust it at runtime. They describe the same products from different angles and work best when they share identifiers.

What is the difference between the passport model and the background check model?

In the passport model the Attester obtains an Attestation Result from the Verifier and shows it to Relying Parties. In the background check model the Relying Party forwards the Attester's Evidence to the Verifier and receives the result itself. RFC 9334 notes both can be used by the same device for different purposes.

Can an EAT be JSON instead of CBOR?

Yes. RFC 9711 defines both. A CBOR EAT is a CWT signed with COSE, and a JSON EAT is a JWT. Each claim has a JSON name and a CBOR integer key, for example eat_nonce and 10, or ueid and 256. Nested tokens can mix encodings.

What is Veraison?

Veraison is an open source project, listed in the CoRIM draft as a Linux Foundation project, that builds attestation verification components: Go and Rust CoRIM libraries, a CoRIM processor, the cocli tool and reference provisioning and verification services. Its Docker deployment is documented as not suitable for production.

Does DICE require CoRIM?

No. DICE defines how a device derives layered identities and encodes measurements in certificates. A Verifier needs reference values from somewhere, and CoRIM is the standard format the TCG endorsement work and the IETF draft align on, but a Verifier could be provisioned another way.

What is an attestation result, and is there a standard format?

It is the Verifier's signed verdict about an Attester. RFC 9334 does not fix a format. The EAR draft (draft-ietf-rats-ear-04) defines one as an EAT profile with an overall ear_status, per component trustworthiness vectors and the verifier's identity. It is still a draft.

Where do reference values come from?

Usually from the manufacturer or firmware publisher, as a signed CoRIM. For images you build yourself, your build pipeline is the better source, ideally from reproducible builds. Capturing values from a "known good" device is a last resort for labs.

Where Safeguard fits

Safeguard does not act as an attestation Verifier, does not parse CoRIM, EAT or DICE certificates, does not analyse firmware images or silicon, and does not check whether a device's measurements match a reference value. That is a Verifier's job, and the steps above use open source tools for it. Safeguard does not generate HBOMs or scan firmware.

The fit is with the software around attestation. The CoRIM draft says the Verifier's code and configuration are primary security assets that sit inside the trusted computing base of every device and service that relies on it. The verifiers, provisioning services, CoRIM libraries and build pipelines that produce reference values are ordinary repositories: veraison/corim and cocli are Go modules, corim-rs and cover are Rust crates, and most in house attestation services pull in COSE, CBOR, X.509 and HTTP libraries from public registries. Safeguard's dependency scanning covers Go and Cargo alongside npm, PyPI and Maven, so those repositories and their container images can be inventoried, matched against vulnerability data, prioritised with reachability analysis and held to policy gates like any other code you ship. If your build pipeline emits both firmware images and SBOMs, Safeguard can hold the SBOM side of the inventory described above; joining it to CoRIM identifiers is still work your team does.

A Verifier that runs a vulnerable CBOR parser or an outdated COSE library undermines every attestation decision it makes, and the boot and OS images your pipeline measures are themselves assembled from open source components. The fit here is indirect, and the steps below apply only to the software you build and run around attestation, not to the silicon, ROM or vendor firmware a manufacturer signs.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The demos below show the software side only. They do not parse CoRIMs, inspect attestation evidence or check firmware.

The first demo is a real Safeguard CLI session. You ask it to fix a lodash CVE; it reads the finding and the advisory, asks before each command, edits package.json, runs npm install and npm test with your approval, and pushes nothing. The same flow applies to a Go verifier service or a Rust CoRIM processor, where the dependencies are Go modules and Cargo crates instead of npm packages.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code and scans from the terminal. That suits attestation code that should not leave a controlled build host, such as the pipeline that produces your reference values.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. A team that keeps its verifier and provisioning services in several repositories can then ask, in one conversation, which of them carry a vulnerable CBOR or COSE library version.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard or read the CLI documentation.

Quick check

Sources

• RFC 9334, Remote ATtestation procedureS (RATS) Architecture
• RFC 9711, The Entity Attestation Token (EAT)
• RFC 9393, Concise Software Identification Tags
• RFC 9782, Entity Attestation Token (EAT) Media Types
• RFC 9781, A CBOR Tag for Unprotected CBOR Web Token Claims Sets (UCCS)
• RFC 9783, Arm's Platform Security Architecture (PSA) Attestation Token
• RFC 9683, Remote Integrity Verification of Network Devices Containing TPMs
• RFC 8392, CBOR Web Token (CWT)
• IETF datatracker: draft-ietf-rats-corim
• draft-ietf-rats-corim-11, Concise Reference Integrity Manifest
• IETF datatracker: draft-ietf-rats-ear (EAT Attestation Results)
• draft-ietf-rats-ear-04
• IETF datatracker: draft-ietf-rats-ar4si (Attestation Results for Secure Interactions)
• IETF datatracker: draft-ietf-rats-endorsements
• IETF datatracker: draft-ietf-rats-reference-interaction-models
• IETF RATS working group documents
• Trusted Computing Group, DICE Architectures work group (archived copy)
• Veraison documentation index
• Veraison project overview
• Veraison DICE notes
• Veraison challenge response verification API
• Veraison endorsement provisioning API
• veraison/corim (Go CoRIM and CoMID library)
• veraison/cocli README
• cocli DICE reference value CoMID template
• cocli full CoRIM template
• veraison/services README

Last reviewed: 24 October 2026. CoRIM, EAR and AR4SI are still Internet-Drafts and their code points may change; check the datatracker for the current version before you build against them.