Code Signing in the Era of Cyber Resilience

Adapting to The Cyber Resilience Act as Best Practice Becomes A Legal Requirement
work-single-image

The software industry never stands still. While in most cases this translates to technological advance, it also brings change to safety, security and compliance. What was once considered rare practice in secure software development is rapidly becoming the new “course of doing business”. The EU’s Cyber Resilience Act, which entered force in December 2024, fundamentally transforms how we must think about software integrity. For developers who have never encountered code signing, and even for those who have, the patterns and practices of yesterday are changing.

At its core, code signing serves a simple but crucial purpose: proving that software comes from who it claims to come from and hasn’t been tampered with along the way. Think of it as a tamper-evident seal on medicine bottles, but for software. When you download an app and your operating system doesn’t warn you about “unknown developers,” that’s code signing at work.

The New Regulatory Reality

The Cyber Resilience Act doesn’t copy today’s coding signing practices; it effectively lays a complete compliance framework through requirements for software integrity verification. By December 2027, any software with digital elements sold in the EU must ensure “protection of the integrity of stored, transmitted or otherwise processed data, commands, programs and configuration.” In practical terms, this means cryptographic signatures on your software.

For many development teams, this represents a sea change. Code signing has historically been the domain of large software vendors and app store publishers. When this new regulation goes into effect, even small development shops creating industrial control software, IoT device firmware, or business applications must show compliance with a standardized set of robust signing practices.

%%{init: {'theme': 'neutral'} }%% graph TD A[Source Code] --> B[Build Process] B --> C{Signed?} C -->|No| D[CRA Non-Compliant] C -->|Yes| E[CRA Compliant] D --> F[Cannot Sell in EU in 2028] E --> G[Market Access] style D fill:#f96 style E fill:#9f6 style F fill:#f99 style G fill:#9f9

Understanding Code Signing Fundamentals

Before diving into our designs, let’s demystify what actually happens when code is signed. The process relies on public key cryptography, the same technology that secures your online banking:

  1. Private Key: A secret mathematical key that only the developer possesses
  2. Public Key: A corresponding key that anyone can use to verify signatures
  3. Certificate: A digital document that links the public key to a verified identity
  4. Signature: A cryptographic proof created with the private key

When you sign code, you’re creating a unique mathematical fingerprint of your software using your private key. Anyone can verify this fingerprint using your public key, proving both identity and integrity.

%%{init: {'theme': 'neutral'} }%% graph TD A[Your Code] --> B[Hash Function] B --> C[Unique Fingerprint] C --> D[Sign with Private Key] D --> E[Digital Signature] F[Certificate Authority] --> G[Your Certificate] G --> H[Public Key] E --> I[Signed Software] H --> I style A fill:#f9f style I fill:#9f9

The Challenge of Traditional Signing

Traditional code signing workflows often feel bolted onto the development process. Developers must:

  • Obtain certificates from Certificate Authorities (often expensive and bureaucratic)
  • Protect private keys (new requirements mandate hardware security modules)
  • Configure build systems with signing tools
  • Manage certificate renewals before expiration
  • Handle different signing requirements for different platforms

This complexity leads to workarounds: shared certificates passed around teams, private keys stored insecurely, or signing steps skipped during development. The CRA makes such practices not just risky, but illegal.

Enter the Firefly Compilation Pipeline

This is where Firefly’s architecture comes into its own. Unlike traditional compilers that produce a binary in one opaque step, Firefly’s pipeline will have the option to generate a series of signed, verifiable artifacts. But here’s the key insight: signing doesn’t have to slow down your development workflow. The system will adapt to your needs, providing rapid iteration during development while ensuring compliance when it matters.

The Observatory Development Environment

The Fidelity “Observatory” (an enhanced VSCode extension) will make signing seamless when you need it, and invisible when you don’t. The magic will happen through integration with QuantumCredential hardware, but the system respects that development has different phases with different needs.

Morning Routine: A Developer’s Perspective

Sarah arrives at her desk and plugs in her QuantumCredential device, a USB key no larger than a typical flash drive. Observatory detects it immediately:

🔐 QuantumCredential detected
✓ Code signing certificate valid
✓ Secure WireGuard connection established
🚀 Ready for secure development

She opens her F# project and begins coding. During her morning development sprint, she’s working on a new feature and needs rapid iteration. Observatory understands this:

module TemperatureControl =
    let adjustThreshold temp =
        match temp with
        | t when t > 100.0 -> CoolingMode.Maximum
        | t when t > 85.0 -> CoolingMode.Normal
        | _ -> CoolingMode.Off

She builds and tests dozens of times, each compilation completing in milliseconds. No signing overhead, no certificate checks, just pure development velocity. This is the “closed developer loop” where speed matters most.

Transitioning to Release Mode

As Sarah’s feature stabilizes and she prepares for integration testing, she switches to release mode. Now the Observatory seamlessly integrates signing into the build process:

%%{init: {'theme': 'neutral'} }%% sequenceDiagram participant Dev as Developer participant Obs as Observatory participant QC as QuantumCredential participant FC as Firefly Compiler Dev->>Obs: Build Release Obs->>FC: Compile Code FC->>FC: Generate AST FC->>QC: Request Signature QC->>QC: Sign with HSM QC->>FC: Return Signature FC->>FC: Embed & Continue FC->>Obs: Signed Binary Obs->>Dev: Build Complete ✓

The entire process adds only milliseconds to the build time. Sarah doesn’t need to think about certificates, keys, or compliance. She just builds her software, and when it matters (release builds, CI/CD pipelines, distribution), it emerges signed and CRA-compliant.

Certificate Lifecycle Management

Behind this seamless experience lies sophisticated certificate management. The QuantumCredential device maintains certificates in its secure enclave, while the Fidelity Observatory extension handles the logistics. But the system is designed around real-world workflows and commercial realities.

From the Top: KeyStation

Security in certificate management starts with the KeyStation, a completely air-gapped system that serves as your organization’s cryptographic root of trust. Understanding how certificates flow through this system is crucial:

🔒 KeyStation Setup (One-time, Administrator-led)
   1. Administrator brings DigiCert/GlobalSign root certificate on secure media
   2. Imports into KeyStation's hardware security module
   3. Generates intermediate CA certificate for organization
   4. Creates policies for developer certificate issuance
   
   [No network connection at any point]

This air-gapped design ensures that your cryptographic foundation remains secure. The KeyStation never touches the network; instead, certificates are provisioned to QuantumCredential devices through direct physical connection.

Automatic Certificate Renewal

When certificates approach expiration, Observatory proactively manages renewal:

🔔 Certificate Renewal Required
   Your code signing certificate expires in 7 days
   
   [Renew Now] [Remind Tomorrow]

Clicking “Renew Now” initiates a secure renewal process. For organizations that have embraced the full QuantumCredential infrastructure, this happens through the quantum-resistant WireGuard tunnel. For those taking a more gradual approach, manual renewal through the KeyStation or QuantumCredential ceremonies remain available.

Team Onboarding Made Simple

When a new developer joins the team, the security officer performs a one-time ceremony:

  1. Developer presents their QuantumCredential at the KeyStation
  2. Identity confirmation (badge check, biometric, etc.)
  3. KeyStation provisions a developer certificate to the device
  4. Developer returns to desk, plugs in, and starts coding

No manual certificate installation. No configuration files. No accidentally committed private keys. This process transforms what traditionally takes hours of setup into a five-minute ceremony.

Platform-Specific Signing: Android Example

The real power of this approach becomes evident when dealing with platform-specific requirements. Consider Android app signing, which has always been a pain point for developers. The Play Store requires specific signatures, keystore files must be carefully managed, and losing a signing key can lock you out of updating your own app. Observatory transforms this complexity into a streamlined workflow:

%%{init: {'theme': 'neutral'} }%% stateDiagram-v2 direction LR state "Build Phase" as s1 { [*] --> Project: F# Android Project --> MLIR: Firefly MLIR --> LLVM: Lower LLVM --> Native: ARM Libraries Native --> QC1: Sign } state "Package Phase" as s2 { [*] --> APK: Structure APK --> Android: Signing Android --> QC2: Keystore } state "Deploy Phase" as s3 { [*] --> Signed: APK Signed --> Upload: Play Store Upload --> Verify: Signatures } s1 --> s2 s2 --> s3

Observatory maintains a mapping between your Firefly signing identity and platform-specific certificates:

[signing.mappings]
firefly = "Developer: Sarah Chen (Firefly)"
android = "CN=Sarah Chen, O=Acme Corp, C=US"
ios = "iPhone Developer: Sarah Chen (TEAMID)"
windows = "Acme Corporation (Authenticode)"

When building for Android, The Fidelity Observatory extension automatically:

  1. Signs all native libraries with your Firefly certificate
  2. Generates the APK structure
  3. Requests Android-specific signature from QuantumCredential
  4. Produces a Play Store-ready APK

The same workflow applies to iOS apps, Windows executables, or any other platform requiring code signatures. What once required juggling multiple certificates, keystore passwords, and signing tools now happens automatically.

Security Without Sacrifice

Traditional high-security signing workflows often involve:

  • Dedicated signing servers with limited access
  • Complex approval workflows
  • Batch signing ceremonies
  • Long turnaround times

This security theater often pushes developers to bypass controls, ironically reducing security. Firefly’s approach provides stronger security while improving developer experience. But crucially, it does so in a way that teams can adopt gradually, gaining immediate benefits while building toward comprehensive security.

Gradual Adoption Path

Organizations don’t need to transform overnight. The journey to comprehensive code signing can happen in stages, each providing immediate value:

Stage 1: Developer Convenience Start by using QuantumCredential for mobile app signing managed by the individual developer. Your Android and iOS developers immediately benefit from simplified workflows, eliminating keystore management headaches. This alone can save hours per release cycle.

Stage 2: Release Automation Extend signing to your CI/CD pipelines. Release builds automatically get signed without manual intervention. You’re now positioned for CRA compliance without disrupting daily development.

Stage 3: Comprehensive Security As comfort grows, extend signing to more scenarios. Some teams enable it for all builds, others reserve it for customer-facing releases. The flexibility lets you find the right balance for your organization.

Commercial Advantages

Beyond compliance, this approach is designed to deliver concrete business benefits. “Security at speed” isn’t just a buzzword; it translates to competitive advantage:

  • Faster Time to Market: No more release delays due to certificate issues
  • Reduced Operational Risk: Hardware-backed keys eliminate the nightmare of leaked credentials
  • Simplified Auditing: Every signed artifact creates an immutable audit trail
  • Developer Productivity: Engineers focus on features, not fighting with signing tools

Real-World Workflow: A Day in Development

Let’s follow a complete development cycle to see how teams naturally adopt these practices:

Morning: Feature Development

Sarah implements a new feature in her industrial control system:

// FlowController.fs
module Industrial.FlowControl

let adjustValvePressure (sensor: SensorReading) =
    match sensor.Pressure with
    | p when p > 150.0 -> ValveCommand.Reduce 0.1
    | p when p < 100.0 -> ValveCommand.Increase 0.1
    | _ -> ValveCommand.Maintain

She builds and tests locally in debug mode. Fast iteration, no signing overhead. The morning flies by as she refines the algorithm. When her change is ready, she produces a pull request which turns on signing by default and produces materials for the CI/CD server to verify.

Afternoon: Code Review

During pull request review, her colleague notices the signed artifact chain:

PR #142: Add pressure regulation
✓ All commits signed by: Sarah Chen (QC: 7A9B-4E2F)
✓ Debug builds: unsigned (development mode)
✓ PR build artifacts: fully signed and verified
✓ CRA compliance: READY

The developer appreciates that debug builds stayed fast during development, while the release build is properly signed for deployment.

Evening: Deployment

The merged code triggers the CI/CD pipeline:

deploy:
  stage: production
  script:
    - firefly build --release --target industrial
    - firefly verify --cra-compliance
    - firefly package --sign-manifest
  signing:
    credential: $CI_QUANTUM_CREDENTIAL
    timestamp: true
    include-sbom: true

The build server’s dedicated QuantumCredential signs the release, timestamps it, and includes a Software Bill of Materials. The F* verification that has been running incrementally throughout development ensures that all correctness properties hold in the final build. CRA compliance is checked automatically. The signed binary deploys to production, ready for the next day’s operations.

The Path of Natural Progression

As we approach the CRA’s compliance deadline, code signing transforms from a specialized practice to everyday necessity. But this transformation doesn’t have to be disruptive. Firefly’s approach, combining the Observatory development environment with QuantumCredential hardware, makes this transition natural and beneficial.

Teams can start small, perhaps just simplifying their mobile app signing workflow. As they experience the benefits (fewer release delays, eliminated certificate management overhead, streamlined processes) they naturally expand usage. Before long, comprehensive code signing becomes as natural as version control, something that enhances rather than hinders development flow.

Developers gain:

  • Flexible workflows that adapt to development vs. release needs
  • Stronger security through hardware-backed keys
  • Future-proof signatures resistant to quantum attack
  • Complete audit trails when needed, invisibility when not

Organizations gain:

  • CRA compliance as a natural outcome, not a burden
  • Reduced risk of key compromise
  • Clear accountability and non-repudiation
  • Simplified certificate management
  • Competitive advantage through “security at speed”

The era of unsigned software is ending. With SpeakEZ’s designs for the Firefly Compiler and QuantumCredential hardware key, the transition to secure-by-default development can be gradual, beneficial, and even pleasant. In this new world, security isn’t something artificially bolted onto your development process. It’s woven naturally into your workflow, available when you need it, invisible when you don’t, always ready to demonstrate compliance and protect your professional integrity.

Author
Houston Haynes
date
June 18, 2025
category
Technology

We want to hear from you!

Contact Us