Security & Vulnerability Disclosure

1. How to report a vulnerability

Send your report by email. Please use a clear subject line and include enough detail for us to reproduce and assess the issue.

Where you can, please include:

• the product or website affected and the exact version or URL;
• a description of the vulnerability and its security impact;
• clear, reproducible steps or a proof-of-concept;
• any logs, screenshots or request/response captures that help;
• whether you believe the issue is being actively exploited.

Reports in English or German are both fine. If you wish to encrypt your report, say so in a first plain-text email and we will arrange a secure channel; a published PGP key may be added to this page and to security.txt in future.

2. Scope

In scope — the software we build and the services we operate:

• CodeB Credential Provider V2, CodeB Web SSO, CodeB Single Sign-On, CodeB Conference (including CodeB Phone and CodeB Voice AI) and the CodeB Admin CLI;
• the CodeB Wallet application and myeudi.app;
• the websites www.codeb.io and phone.codeb.io.

Generally out of scope — please do not report these unless you can demonstrate a concrete security impact:

• findings from automated scanners without a working, demonstrated exploit;
• missing security headers, cookie flags or TLS configuration niceties with no exploitable consequence;
• volumetric denial-of-service, rate-limiting or load-testing;
• social engineering, phishing or physical attacks against staff or offices;
• reports about third-party services we merely use (raise those with the relevant vendor).

Please test only against your own installations and accounts. Do not access, modify or exfiltrate data that is not yours, and do not degrade service for others.

3. What to expect from us

• Acknowledgement — we confirm receipt within two business days.
• Triage — we assess and assign a severity, and aim to begin triage within the targets in the table below.
• Updates — we keep you informed of progress and of our assessment of severity and impact.
• Remediation — we develop a fix and ship it as a signed update during the product’s support period, at no charge, and we tell you when it is available.
• Coordination — we agree a disclosure timeline with you (see below).

These are the targets we work to in good faith, not contractual guarantees; real-world timing depends on complexity, reproducibility and whether an issue is being actively exploited.

4. Severity & response targets

We acknowledge every report within two business days regardless of severity, then aim to begin triage within:

5. Safe harbour for good-faith research

If you make a good-faith effort to comply with this policy during your research, we will regard your activity as authorised, we will not pursue or support legal action against you for it, and we will work with you to understand and resolve the issue quickly. To stay within safe harbour:

• act only against assets listed in scope, and only against your own accounts and installations;
• avoid privacy violations, data destruction, and any interruption or degradation of our services;
• do not access, store or disclose data belonging to others; stop and report once you have proof of concept;
• give us a reasonable opportunity to fix the issue before disclosing it publicly.

This safe harbour does not authorise actions against third parties, and it does not waive rights of third parties who have not adopted a comparable policy. If in doubt about whether something is in scope or allowed, ask us first.

6. Coordinated disclosure & credit

We practise coordinated disclosure. Our default is to agree a disclosure date with you once a fix is available, typically within 90 days of your report — sooner for simple issues, and we will tell you if a complex fix needs longer. With your permission we are glad to credit you by name or handle when we publish an advisory or release note. If you prefer to remain anonymous, that is fine too.

We do not currently operate a paid bug-bounty programme; reports are handled on a coordinated-disclosure basis.

7. Our regulatory reporting (EU Cyber Resilience Act, Article 14)

Separately from the inbound process above, CodeB has its own outbound reporting obligations as a manufacturer under the EU Cyber Resilience Act (Regulation (EU) 2024/2847). For actively exploited vulnerabilities and severe incidents affecting products in scope, we report to ENISA and the relevant national CSIRT within the CRA’s windows:

• Early warning — within 24 hours of becoming aware;
• Notification — within 72 hours, with available detail and any corrective or mitigating measures;
• Final report — within 14 days of a corrective update being made available.

These Article 14 duties have applied since 11 September 2026; the full set of CRA manufacturer obligations applies from 11 December 2027. We position CodeB as CRA-ready rather than “certified” while the harmonised standards are finalised. A prompt, well-documented report from you directly supports our ability to meet these windows.

8. security.txt

A machine-readable security contact is published under RFC 9116 at /.well-known/security.txt. It names this page as the canonical policy and info@codeb.io as the contact.

9. Changes to this policy

We may revise this policy as our process matures or as the law requires. The current version, with its effective date, is always available at this URL; material changes are reflected in a higher version number.

Document ID: codeb-security-policy-1.0 · Last reviewed: 12 November 2026.