Run an end-to-end Attestation Flow with Arm CCA
Introduction
Overview of the Software Architecture
Run an end-to-end Attestation with Arm CCA
Next Steps

  Log an issue

  Fork and edit

  Discuss on Discord

About this Learning Path

Skill level:  Advanced
Reading time:  2 hrs
Last updated:  03 Jul 2026
Skill level:
  Advanced
Reading time:
  2 hrs
Last updated:
  03 Jul 2026
Authors:Arnaud de Grandmaison, Arm
Paul Howard
Pareena Verma, Arm
Arm IP:Neoverse
Tags: Performance and Architecture Linux GCC FVP RME CCA Docker Veraison Runbook
Authors:
  • Arnaud de Grandmaison, Arm
  • Paul Howard
  • Pareena Verma, Arm
Arm IP:
Neoverse
Tags:
Performance and Architecture Linux GCC FVP RME CCA Docker Veraison Runbook

Who is this for?

This is an advanced topic for software developers who want to learn how to run an end-to-end attestation flow with Arm's Confidential Computing Architecture (CCA).

What will you learn?

Upon completion of this Learning Path, you will be able to:

  • Describe how you can use attestation with Arm's Confidential Computing Architecture (CCA).
  • Deploy a simple workload in a CCA realm on an Armv9-A AEM Base Fixed Virtual Platform (FVP) that has support for RME extensions.
  • Connect the workload with additional software services to create an end-to-end example that uses attestation to unlock the confidential processing of data.

Prerequisites

Before starting, you will need the following:

Summary

AI-assisted

This summary was drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
You’ll deploy a sample workload in a Linux realm on an Armv9-A AEM Base Fixed Virtual Platform (FVP) with Realm Management Extension (RME) support and connect it to attestation services to control access to secrets. First, you’ll start a minimal Key Broker Server (KBS) from the Veraison project in a container, then integrate it with the realm so that confidential data is released only after successful attestation. You’ll focus on the flow of evidence, verification, and key release to recognize a complete end-to-end run when service logs report a successful attestation result and the workload in the realm receives its key.

Frequently asked questions

AI-assisted

These FAQs were drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
Which components need to be running to exercise the end-to-end flow?
You need the RME-enabled Armv9-A AEM Base FVP hosting a Linux realm, the attestation services, and the Veraison Key Broker Server (KBS) container. Run these in the order described so that attestation can evaluate the realm before secrets are requested.
How do I know the Key Broker Server is ready?
After starting the provided container image, confirm the container is running and check its logs for a startup or listening message. Proceed only when the KBS indicates it is ready to handle requests.
What result should I expect when attestation succeeds?
The attestation services accept the realm’s evidence, and the KBS authorizes release of a key or secret. You should see logs showing a positive attestation outcome and the workload receiving the expected data.
When should the confidential data be released to the realm?
Only after the attestation step verifies that the Linux realm provides the required level of confidential isolation. The example gates key release on that successful verification.
What should I check if attestation fails or no key is returned?
Verify the Linux realm is running on the RME-enabled FVP and that the attestation services and KBS are up and reachable. Inspect their logs for configuration or connectivity errors, then restart the flow after addressing the issue.
Next