Products · qdCloud

IoT platform for operating, monitoring and remotely servicing connected products

qdCloud keeps your device fleet up to date and verifiably secure for its entire time in the field. It connects devices running embedded Linux, an RTOS or bare metal. The platform runs in Germany or in your own data centre.

Quick start by role

  • Head of development

    Updates without risk to the fleet, and a connection for Linux, RTOS and bare metal.

  • Security and product safety

    Which obligation of the Cyber Resilience Act the platform covers with which function.

  • Service

    Alarms, dashboards and remote access to the individual device.

  • Management

    Where the platform runs, who owns it and what you pay for.

If you sell connected devices, you have to be able to maintain them in the field

The reporting obligations of the Cyber Resilience Act have applied since 11 September 2026, and all other obligations apply from 11 December 2027. Manufacturers must fix vulnerabilities for the whole support period and be able to prove it.

  • Obligations under the Cyber Resilience Act

    Provide security updates, report exploited vulnerabilities on time, inform affected customers. For that, the manufacturer needs access to every device in the field.

  • The fleet grows faster than the service team

    Every device shipped adds questions: which device runs which version, which one has gone silent, who gets the next update first? Beyond a few hundred devices, a spreadsheet can no longer answer that.

  • No platform team of your own

    Building device identities, update distribution, tenants and audit evidence yourself ties up developers for years. qdCloud provides that foundation, so your developers have time for the core tasks of your product. If the device lacks the connection, the bootloader or the update chain, we build those too.

From the device into your production systems

  1. Connect the device

    The supplied device service connects embedded Linux, RTOS and bare-metal devices to the platform. You do not have to develop a protocol of your own, and the connection can be simulated without real hardware.

  2. Issue an identity

    Each device receives a certificate in production. On first connection it enrols itself in your fleet.

  3. Operate the fleet

    Publish versions, approve rollouts, handle alarms and manage configurations. Everything is available natively in the user interface and through the API.

  4. Hand over to your systems

    Every function is available through a documented, versioned API. Alarms, security events and fleet data flow into your ERP, your ticket system or your central security monitoring.

Roll out updates with peace of mind

  • Roll out in stages

    You select the devices for each stage by organisation, group, location or your own attribute, and trial an update first where a fault costs least.

  • Stops automatically

    If failures pile up in a stage or devices fall silent, the platform halts the rollout before the next stage begins.

  • The device stays operational

    A failed version or an interrupted installation does not take the device down. Devices that were temporarily unreachable catch up on their jobs.

  • Manage and block versions

    Each firmware version carries its release maturity, the versions it may be installed over and its end of support. You block a faulty version immediately, and a security patch ships as its own package.

Logo qdCloud

qdCloud and the Cyber Resilience Act

The table does not replace the conformity assessment of your product.

qdCloud and the Cyber Resilience Act specifications
What the regulation requiresWhat qdCloud does
Security updates for the support period, at least five years (Art. 13)Staged rollouts, security patch separate from the feature release, end of support per version with a reminder before it expires.
Keep a software bill of materials (SBOM)SBOM per firmware version, machine-readable.
Identify vulnerabilities and fix them without delayFind the affected devices per vulnerability, record whether and why the product is affected, prove the fix per device.
Early warning within 24 hours, notification within 72 hours, final report 14 days after a fix is available (Art. 14)Record the reportable incident, track the deadlines, generate the report document, keep tamper-proof evidence of the report.
Inform affected usersIdentify affected devices and customers from the fleet data, inform the customers, publish a security advisory for the fixed vulnerability.
Accept vulnerability reports from outsideAn intake for reports with acknowledgement of receipt and feedback on the processing status.
Distribute updates securelySigned packages, a certificate per device with renewal in the field, access revocable for one device or a whole production line.
Retain evidenceEvery change to fleet, permissions and rollouts is traceable. Evidence is protected against premature deletion.

What qdCloud looks like

  • qdCloud dashboard with pie charts for installed firmware versions and reachable devices, below them the alarms per day and the alarm list, shown in German
    The dashboard shows which firmware runs in the field, how many devices are reachable and which alarms are open.
  • qdCloud device list with columns for reachability, serial number, type, alarms, firmware and hardware revision, shown in German
    The device list states reachability, firmware version and open alarms for each device.

Three plans, from CRA-compliant to remote service

Basic covers fleet operation. You add Monitor and Remote Access when your service needs them. Prices and licence terms are on the plans page.

  • Basic

    Fleet overview, device identities, firmware management and updates, alarms on lost contact, tenants and permissions, an API for your systems and your CI/CD pipeline.

  • Monitor

    Dashboards for measured values and device states, alarms with your own thresholds, analysis of device logs and handover of the data to existing systems.

  • Remote Access

    Remote access to the individual device, configuration during operation, access to files and system. Every session is logged.

Hosting

Where the platform runs

The functional scope is the same either way.

  • Cloud-Hosted

    Who operates it
    We do, including updates and monitoring of the instance.
    Where the data is stored
    In a German data centre.
    Infrastructure costs
    Shown separately: €0.01 per gigabyte of traffic, €0.10 per gigabyte of storage.
    Suits
    Manufacturers without their own platform operations.
  • Self-Hosted

    Who operates it
    Your team, with our deployment and our operating documentation.
    Where the data is stored
    In your data centre.
    Infrastructure costs
    None. You pay for your own infrastructure.
    Suits
    Manufacturers with their own data centre or strict rules on where data may be stored.

Ownership

Use it or own it, your decision

  • Usage licence: you use it, we maintain it

    You license per active device and year and get updates, fixes and support in return. Your device data is yours: you can export your fleet data at any time, and the platform keeps working if the connection to us is lost.

  • Source code licence: you own the release

    You receive source code, deployment and documentation permanently and run qdCloud yourself. We do not limit the number of devices. No black box and no tie to our roadmap.

View the licence models and prices

What qdCloud connects and what it runs on

Devices

  • Embedded Linux
  • RTOS
  • Bare metal
  • Existing devices via adapter

Transport

  • MQTT over TLS
  • further transports via extension points

Updates

  • signed packages
  • A/B partitions with RAUC on Linux
  • Secure Boot

Platform

  • Kubernetes
  • NATS JetStream
  • versioned REST API

What manufacturers ask before the demo

Do I need hardware from querdenker engineering?

No. qdCloud connects devices running embedded Linux, an RTOS or bare metal. Our qdGate gateway and our qdSBC single-board computer run the qdCoreX Linux base system, where the connection is already in place.

Can devices that are already in the field be connected?

Yes, through an adapter for the existing data format. The master data of an existing fleet is imported, and a device remains functional even if a migration fails.

What happens to personal data?

You set the retention period per data type and mark personal data. A person's data can be deleted without losing audit evidence.

Demo or CRA consultation, your choice.

Tell us the device type and volume, and whether the platform should run on your premises. Tell us what you want to see as well, and we will set up the demo around it. In the free CRA consultation, we clarify in 30 minutes what the regulation requires of your device fleet.

Florian Seibold

Managing Director

info@querdenkerengineering.de

+49 7807 890 80 10