Vulnerability Disclosure Policy
1. Purpose
DeltaM2M Device Manager manages router and gateway infrastructure in the field. A vulnerability in it can reach the networks and devices it manages, so we would rather hear about one from you than from an attacker. This policy tells you how to report, what we will do, and what protection you have when you act in good faith.
2. How to report
E-mail: security@deltam2m.dk Preferred languages: Danish, English Encryption: We do not publish a PGP key. If you need to send something that must be encrypted, write first and we will agree a channel.
Include what you can: affected component and version, impact, reproduction steps or proof of concept, whether you believe the issue is being exploited, and how you wish to be credited.
Please report privately. Do not open a public issue and do not disclose publicly before the date we agree.
3. Scope
In scope
- The Device Manager server – backend API, MQTT broker, WebSocket layer
- The web frontend
- Device agents distributed with the product (Teltonika/Lua, Digi, Kerlink)
- Release, packaging and update mechanisms, and the container images we publish
Out of scope
- Our customers’ installations, networks and devices. Each installation is operated by a customer, on their infrastructure. We cannot authorise testing against them. Test against your own installation.
- Third-party components and libraries – report to their maintainers. Tell us as well if the way DDM uses them is what makes the issue exploitable.
- Router and gateway firmware from Teltonika, Digi and Kerlink – report to those vendors.
- Volumetric denial of service.
- Automated scanner output with no demonstrated impact; missing hardening headers with no exploitable consequence; weaknesses that require a compromised administrator account that already holds the privilege in question.
- Social engineering or physical attacks against DeltaM2M staff or premises.
4. Our response
Stage | Target |
|---|---|
Acknowledgement | 5 business days |
Initial assessment – reproduction and our severity view | 15 business days |
Status updates while the issue is open | at least every 30 days |
Fix, or a documented decision not to fix with the reasoning | driven by severity; communicated to you |
These are targets for a small team, not a contractual SLA. If we are going to miss one, we will tell you before we miss it rather than after.
5. Coordinated disclosure
Our default is public disclosure 90 days after acknowledgement, or when a fix is available and our customers have had a reasonable opportunity to apply it – whichever comes first.
We will agree the date with you. We will bring it forward if a vulnerability is being exploited and users need to know. We will ask you to extend it only with a concrete reason and a date, never open-endedly.
We credit reporters by name in the release notes unless you ask us not to. We do not operate a bug bounty and cannot offer payment.
DeltaM2M ApS is not a CVE Numbering Authority. Where a CVE identifier is appropriate we will request one and will not object to you requesting one yourself.
6. Safe harbour
If you make a good-faith effort to follow this policy, we will treat your research as authorised. We will not pursue or support legal action against you in relation to it, and we will say publicly that your actions were authorised if a third party raises the matter.
Good faith means you:
- access, modify or delete no more data than is strictly necessary to demonstrate the issue, and never data belonging to another party where you can avoid it;
- do not degrade or disrupt the availability of any service;
- do not exfiltrate, retain or publish data you encounter – if you come across personal data, stop immediately, do not keep it, and tell us;
- use no social engineering, phishing, or physical attack;
- test only against systems in Section 3, and give us reasonable time to respond before disclosing.
This safe harbour is ours to give for our own systems and code. It does not, and cannot, extend to a customer’s installation.
7. Regulatory reporting
DeltaM2M ApS is subject to Article 14 of Regulation (EU) 2024/2847 (Cyber Resilience Act), applicable from 11 September 2026. Where we become aware that a vulnerability in Device Manager is being actively exploited, we are required to notify our coordinating CSIRT – Center for Cybersikkerhed (Denmark) – through ENISA’s Single Reporting Platform on a 24-hour / 72-hour / 14-day schedule, and to inform affected users.
Your report may therefore start a regulatory clock. Two consequences for you:
- If you have reason to believe the issue is being exploited, say so — it changes what we must do and how quickly.
- We will not identify you in a regulatory filing without your agreement.