Security Audits | Developers

Security Audits

Estimated reading time: 3 minutes


To be listed on the Ledger Live “My Ledger“ section, Embedded Apps and Plugins must go through our integration process that includes a security audit performed by one of our trusted partners.

Provided your project fulfills the conditions, this is how an external audit unfolds:

  1. You get in touch with the auditers and sign a contract with them. Read more.
  2. The auditors review your app based on Ledger specifications. Read more.
  3. Ledger reviews the security audit report
  4. Ledger publishes your app


To go through an external security audit, ensure your project fulfills the following conditions:

  • Your Embedded App works with all our devices (Ledger Nano S, S Plus, X and Stax)
  • Your Embedded App has been functionally validated by Ledger team
  • Do not start a security audit process if your Embedded App is not ready for all Ledger devices (Ledger Nano S, S Plus, X and Stax).
  • Your Embedded App must still be functional after the security audit

Your agreement with our partners

If your embedded app is ready to go through the security audit, you can contact one of our partners:

They both follow Ledger specifications and will provide a full report with potential vulnerabilites.

Important aspects of your agreement:

  • Time: When the auditors will be able to start the review.
  • Cost: The external audit will be entirely at your expense.
  • Maintenance: You must include a clause for updates or sign a new contract for any major update. If you don’t, your app will not be updated by Ledger and will be reverted to developer mode if it is breaking.
Ledger is not a stakeholder in the contract between you and our partners.

Content of the security audit

Ledger has established and made public a detailed specification of what needs to be done to perform a security audit following Ledger’s standards.

Step Specification
Application privileges
  • Check application flags (privileges) and allowed derivation paths.
  • Check for compilation warnings, and if warnings have been silenced. If so, ask for a fix.
  • Run tests and check they succeed.
  • Check tests are sound
Static Analysis
  • Check for defects using scan-build and our scan options. Add in CI if not present.
  • CodeQL: check with the "security and quality" queries. Add in CI if not present.
Manual code review
  • List every transaction fields. Look which ones must be displayed to the user.
  • Check transaction parser, field formatters.
  • Check if sensitive data is properly erased.
  • Do not allow blind signing.
  • Implement a transaction fuzzer. Best effort to reach decent coverage.
  • Use libFuzzer if possible to integrate with ClusterFuzzLite.
  • Report and executive summary detailing findings, and tests that gave no results.
  • Security fixes: on a temporary private fork.
  • Feedback on the SDK: what could be improved for a better security.

Security Guidelines

To develop a secure embedded app, read and apply the security guidelines.

Did you find this page helpful?

How would you improve this page for developers?

Release types and requirements
App submission
Getting Started
Theme Features

Embedded Apps