Security & Compliance

Last updated: April 25, 2026

Overview

We provide a unified Qualified Electronic Signature (QES) infrastructure layer for software companies and enterprise systems operating under the eIDAS Regulation.

We do not replace trust providers or signature devices. Instead, we design and operate the secure integration layer that connects:

  • cloud systems
  • desktop environments
  • qualified signature devices (QSCDs)
  • trust service providers

The platform is built to ensure that security guarantees required by eIDAS are preserved end-to-end, not weakened by integration complexity.

Security Architecture

QSCD-Based Signing (Device-Centric Security)

We integrate with certified Qualified Signature Creation Devices (QSCDs), including:

  • USB tokens (e.g. SafeNet eToken series)
  • Smart cards (e.g. IDPrime 940)
  • Secure hardware-backed environments

Private keys:

  • are generated and stored inside certified devices
  • never leave the QSCD
  • are used only via secure vendor libraries

This aligns with eIDAS requirements for qualified signatures and device certification.

Desktop-Cloud Separation Model

The system is intentionally split:

Desktop Client

  • Performs all cryptographic operations locally
  • Communicates directly with QSCD hardware
  • Stores sensitive data using OS-native secure storage

Cloud Signing Layer

  • Orchestrates workflows and API requests
  • Routes signing operations to the correct device
  • Never accesses private keys or signing secrets

This architecture ensures:

  • no centralized key storage risk
  • no exposure of signing credentials to APIs or backend systems

Support for HSM / Remote QES Scenarios

Where clients use HSM-backed environments:

  • we can integrate with those flows via the same unified layer
  • signing still occurs in a certified environment (QSCD / HSM)
  • the platform orchestrates and transports signed outputs securely

HSM-based qualified signatures are commonly used by trust providers for remote QES services.

Authentication & Access Control

API Security

All APIs require authenticated API keys. Keys are:

  • hashed at rest
  • scoped to allowed operations
  • rotatable and revocable

Device-Level Security

  • Each desktop client is treated as a secure execution endpoint
  • Active device sessions are tracked and validated
  • Requests are routed only to authorized, connected devices

Data Protection

No Key Exposure

  • Private keys are never exported
  • PIN and PUK values are never transmitted to backend systems
  • Sensitive operations are executed locally only

PIN Handling

PIN storage is optional and user-controlled. When enabled, PINs are stored in OS-native secure storage (Keychain, Credential Manager, etc.).

Users can:

  • disable PIN storage at any time
  • require manual PIN entry per signature

PUK codes are never stored.

Audit Logging & Traceability

We maintain audit logs for all critical operations, including:

  • API requests (e.g. signing, tunneling, diagnostics)
  • device connection and session events
  • signature requests and outcomes
  • system-level workflow events

Logs are:

  • timestamped and traceable
  • structured per tenant and device
  • designed to support compliance audits and debugging

Sensitive data (PINs, private keys, full document payloads) is never logged.

Secure Communication

  • TLS 1.3 enforced for all communication
  • Secure socket connections between desktop and cloud
  • Strict certificate validation

All data is encrypted in transit and protected against interception.

Infrastructure Security

Hosting Model

  • Default deployments are hosted on AWS regions
  • Infrastructure is containerized and Kubernetes-ready
  • Can be deployed in alternative environments based on client requirements

Reliability

  • Stateless services for scalability
  • High-availability configuration
  • Controlled failover and recovery processes

Compliance & Standards

eIDAS Alignment

  • Fully aligned with QES requirements under eIDAS
  • Supports workflows using qualified certificates and QSCD devices
  • Designed for cross-border recognition across EU/EEA

Standards Alignment

The architecture is compatible with:

  • ETSI EN 319 401 (Trust service security)
  • ETSI EN 319 411 (Certificate policies)
  • ETSI EN 419 221 (Secure signature devices)

GDPR

  • Data minimization by design
  • No unnecessary processing of personal data
  • Secure handling of logs and metadata

Certification & Audit Readiness

We are designed to be ISO-aligned (e.g. ISO 27001) at an architectural and operational level.

  • We do not currently hold a standalone certification
  • In practice, certification is typically obtained at the client / product level, where this infrastructure is part of the system

We support:

  • security audits
  • compliance reviews
  • certification processes for client environments

Security Responsibility Model

We are not a Qualified Trust Service Provider (QTSP).

Responsibility is split as follows:

  • QTSPs - issue qualified certificates
  • QSCD / HSM vendors - secure key storage and cryptography
  • our platform - secure orchestration, integration, and workflow layer

This separation ensures that each component maintains its certified security guarantees.

Vulnerability Disclosure

We take security issues seriously.

Report vulnerabilities to: security@qes.dev

Please include:

  • description of the issue
  • reproduction steps
  • potential impact

We will investigate and respond promptly.

Final Note

We build for environments where signatures are legally binding actions, not UI interactions.

Security is enforced across:

  • device-level cryptography
  • desktop execution
  • transport and orchestration
  • auditability and compliance

Designing a secure QES workflow?

We help teams implement production-grade signing systems that meet eIDAS requirements without introducing security risk.

Book a call