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
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.
Issue an identity
Each device receives a certificate in production. On first connection it enrols itself in your fleet.
Operate the fleet
Publish versions, approve rollouts, handle alarms and manage configurations. Everything is available natively in the user interface and through the API.
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.
qdCloud and the Cyber Resilience Act
The table does not replace the conformity assessment of your product.
| What the regulation requires | What 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 delay | Find 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 users | Identify affected devices and customers from the fleet data, inform the customers, publish a security advisory for the fixed vulnerability. |
| Accept vulnerability reports from outside | An intake for reports with acknowledgement of receipt and feedback on the processing status. |
| Distribute updates securely | Signed packages, a certificate per device with renewal in the field, access revocable for one device or a whole production line. |
| Retain evidence | Every change to fleet, permissions and rollouts is traceable. Evidence is protected against premature deletion. |
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.
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.




