# Cyber Resilience Act

This page traces **Regulation (EU) 2024/2847** of the European Parliament and of the Council of October 23, 2024 on horizontal cybersecurity requirements for products with digital elements (the *Cyber Resilience Act*, hereinafter "the Regulation") against Flopsar's documentation, processes, and contractual commitments.&#x20;

For each applicable clause of the Regulation, the text below states in a sentence or two how the requirement is satisfied for **Flopsar 7.x**, and points to the location where the supporting evidence can be inspected. Evidence published on this documentation site is linked directly. Evidence retained internally as part of the technical documentation prescribed by Annex VII of the Regulation is identified as such and is made available to market surveillance authorities upon a reasoned request, in accordance with Article 32 and the trade-secret protections of Article 53.&#x20;

This page is a **map**, not the primary source. The authoritative content for each item lives at the linked page; this page only consolidates the references.

## Product classification and conformity assessment

Flopsar is a **product with digital elements** within the meaning of Article 3(1) of the Regulation. It is **commercial, proprietary software**; its source code is not published. It is classified as a product in the **default category** — it is not listed in Annex III ("important products with digital elements", class I or II) or Annex IV ("critical products with digital elements") of the Regulation.&#x20;

The conformity assessment procedure applied is therefore **internal production control (Module A)**, set out in Annex VIII, point 1 of the Regulation. **No notified body is involved** in the conformity assessment, as none is required for products in the default category.&#x20;

The classification is re-evaluated by Flopsar Technology Sp. z o.o. at least once every six months, and whenever the European Commission updates Annex III or Annex IV by way of a delegated act under Article 7.

## Applicability and key dates

The Regulation entered into force on **December 10, 2024**, and its provisions apply progressively.&#x20;

From **September 11, 2026**, the reporting obligations of Article 14 — for actively exploited vulnerabilities and severe incidents — apply. Flopsar Technology Sp. z o.o. operates the internal reporting process described in Section 7 of this page from that date.&#x20;

From **December 11, 2027**, the remaining obligations of the Regulation apply, including CE marking and the EU declaration of conformity. Releases placed on the market on or after that date carry the CE marking and are accompanied by the declaration linked from EU Declaration of Conformity.&#x20;

For releases placed on the market before these dates, this page documents the position adopted voluntarily by Flopsar Technology Sp. z o.o. in anticipation of full applicability.

## Essential cybersecurity requirements — Annex I, Part I

The following are the thirteen essential design and production requirements of Annex I, Part I of the Regulation. Each item states how Flopsar 7.x meets the requirement and where the supporting evidence can be found.&#x20;

**(a) Made available without known exploitable vulnerabilities.** Dependency vulnerabilities are scanned at build time (`cargo audit`, `yarn npm audit`, and Syft with Grype on the agent's bill of materials), and a release is blocked on findings of High or Critical severity that have not been remediated or formally accepted. See Security Advisories and Third-party Components & SBOM.&#x20;

**(b) Secure-by-default configuration, with the ability to reset to the original state.** A production hardening checklist is published per component, defaults are reviewed at every minor release, and a documented procedure resets a deployment to a clean state. See Hardening Checklist and Decommissioning & Secure Data Erasure.&#x20;

**(c) Vulnerabilities can be addressed through security updates.** Updates are delivered through signed Linux package repositories and the official container registry; the product checks for new releases but applies them only on the operator's confirmation, which is the appropriate behavior for a server product. See Updates & Patches.&#x20;

**(d) Protection from unauthorized access.** Local accounts use scrypt password hashing; LDAP integration and JWT-based sessions are supported; role-based access control governs authorization; the agent-to-server channel uses an authenticated session (X25519 key agreement with ChaCha20-Poly1305); and access attempts are recorded in the audit log. See Authentication, Authorization & Roles, and Cryptography & Key Management.&#x20;

**(e) Confidentiality of data, in transit and at rest.** TLS 1.3 (via rustls) protects all external interfaces; X25519 with ChaCha20-Poly1305 protects the agent-to-server channel; AES-GCM is available for data at rest when configured; and password hashes are never stored in plaintext. See Cryptography & Key Management.&#x20;

**(f) Integrity of data, commands, programs, and configuration.** Authenticated encryption protects the agent-to-server channel; Linux packages are signed with GPG and Windows binaries with Authenticode; the audit log is tamper-evident; and configuration is integrity-checked on load. See Cryptography & Key Management and Updates & Patches.&#x20;

**(g) Data minimization.** The agent records method names, timings, and stack frames by default and captures no end-user data unless the operator opts in to deeper instrumentation; data masking and filters let the operator exclude sensitive paths; and a retention policy with automatic purge limits storage over time. See Privacy & Data Handling, Data Masking, and Filters & Services.&#x20;

**(h) Availability and resilience against denial of service.** Request buffers are bounded (`xstack_maxsize`, `req_timeout`, `max_ext_size`); LZ4 compression limits payload size; listening sockets are segregated by protocol; and resource limits are enforced by the systemd unit. See Network Surface & Ports and Known Risks & Limitations.&#x20;

**(i) Minimal negative impact on other devices and networks.** The agent operates as an in-process JVM library with outbound-only traffic to the configured server, opens no listening socket, and applies back-pressure on its own buffer to avoid saturating the host. See Threat Model & Trust Boundaries.&#x20;

**(j) Limited attack surface.** The server exposes four well-defined ports, each individually disablable in configuration; the agent exposes none; the workstation is served by the server's HTTPS endpoint; and the systemd unit runs the server under a dedicated unprivileged user with capability and filesystem restrictions. See Network Surface & Ports and Hardening Checklist.&#x20;

**(k) Reduced impact of an incident through exploitation-mitigation techniques.** Rust release builds are compiled with `panic = "abort"` (no stack unwinding) and link-time optimization; position-independent executables and stack protection are enabled; address space layout randomization is supported by the host; and the `systemd` unit runs with a minimal capability set. See Hardening Checklist and the internal technical documentation.&#x20;

**(l) Recording and monitoring of security-relevant activity, with an opt-out for the user.** A structured audit log is produced by `log4rs` and can be forwarded to syslog or to a security information and event management system; verbosity is configurable; and the recorded security events are documented explicitly. See Audit Logging & Security Events.&#x20;

**(m) Secure and permanent removal of data and settings.** A retention policy with automatic, time-bounded purge is provided, together with a documented decommissioning procedure that securely wipes the `master.key` file and the data volume in line with NIST SP 800-88. See Decommissioning & Secure Data Erasure.

## Vulnerability handling requirements — Annex I, Part II

The following are the eight vulnerability handling requirements of Annex I, Part II of the Regulation. They apply throughout the support period of each release line; see Support & Maintenance Lifecycle.&#x20;

**(1) Identify and document components, including an SBOM.** A CycloneDX 1.6 software bill of materials is generated per release for each of the three components — server, agent, and workstation — covering top-level and transitive dependencies. See Third-party Components & SBOM.&#x20;

**(2) Address and remediate vulnerabilities without delay, with security updates provided separately from functionality updates where feasible.** An internal product security incident response process, aligned with ISO/IEC 30111:2019, produces security updates as patch releases that are separate from feature releases, and remediates "without undue delay" as the Regulation requires. See Vulnerability Disclosure Policy and Support & Maintenance Lifecycle.&#x20;

**(3) Apply regular security testing and reviews.** Static analysis, dependency scanning, an internal review at every release, and external penetration testing per major release are performed, and the results are retained in the technical documentation prescribed by Annex VII.&#x20;

**(4) Once an update is available, publicly disclose information about fixed vulnerabilities.** Advisories are published in human-readable form and in machine-readable CSAF 2.0 and CycloneDX VEX formats, stating affected and fixed versions, impact, severity, mitigations, and the CVE identifier where available. See Security Advisories.&#x20;

**(5) Put in place and enforce a coordinated vulnerability disclosure policy.** A public policy aligned with ISO/IEC 29147:2018 sets out scope, reporting channels, the handling process, embargo arrangements, a safe harbor, and acknowledgment. See Vulnerability Disclosure Policy.&#x20;

**(6) Facilitate the sharing of information about potential vulnerabilities, including a contact address.** A single point of contact, `psirt@flopsar.com`, is published together with a PGP key, an HTTPS web form, and an RFC 9116 `security.txt` file; reports are accepted in English and Polish. See Contact and the Vulnerability Disclosure Policy.&#x20;

**(7) Provide mechanisms to securely distribute updates.** Signed APT and YUM repositories and signed container images are used, with a documented manual update procedure that includes signature verification, and each security update is accompanied by an advisory. See Updates & Patches and Security Advisories.&#x20;

**(8) Disseminate security updates without delay and, unless otherwise agreed for tailor-made products, free of charge, with advisory messages.** Security updates are distributed without undue delay and free of charge to any holder of a valid license for the affected line, and each is accompanied by an advisory. The distinction between this free manufacturer obligation and optional paid commercial support is set out in Support & Maintenance Lifecycle.

## Information and instructions to users — Annex II

Annex II lists the information that must accompany the product. The following describes where each item is published.&#x20;

**(a) Manufacturer identity and contact.** The name, postal address, email, and website of Flopsar Technology Sp. z o.o. are on the Contact page and are displayed on every release artifact.&#x20;

**(b) Single point of contact for vulnerabilities and the CVD policy.** Published at Contact, in the Vulnerability Disclosure Policy, and in the `security.txt` file.&#x20;

**(c) Identification of the product, including version.** See Versioning and the per-release manifest published with each release.&#x20;

**(d) Intended purpose, security environment, essential functionality, and security properties.** See What is Flopsar?, Security Overview, and Deployment Models.&#x20;

**(e) Known or foreseeable circumstances that may lead to significant cybersecurity risks.** See Known Risks & Limitations and Threat Model & Trust Boundaries.&#x20;

**(f) Where the EU declaration of conformity can be accessed.** See EU Declaration of Conformity.&#x20;

**(g) The type of technical security support and the end date of the support period.** See Support & Maintenance Lifecycle.&#x20;

**(h) Instructions for installing security updates.** See Updates & Patches.&#x20;

**(i) Information for integrators, where the product is intended for integration into other products.** See Developer Guide: Agent Extensions and Server API.&#x20;

**(j) How secure deletion of data can be carried out.** See Decommissioning & Secure Data Erasure and Privacy & Data Handling.

## Manufacturer obligations — Article 13

The following obligations of Article 13 have a direct correspondence in public-facing artifacts.&#x20;

**Single point of contact (13(1)).** `psirt@flopsar.com`, monitored on business days, accepting English and Polish, is published on this site, in `security.txt`, and on the EU declaration of conformity. See Contact.&#x20;

**Secure design, development, and risk assessment (13(2)–(6)).** A secure development lifecycle aligned with ISO/IEC 27034-1:2011 is operated, and a documented risk assessment is refreshed per release and per substantial modification. This evidence is retained internally as part of the Annex VII technical documentation.&#x20;

**Information to users (13(7)).** The information required by Annex II is published throughout this documentation site, as described in Section 5.&#x20;

**Support period (13(8)).** A support period of at least five years is determined, communicated, and honored per release line, with stages of Active Maintenance, Security Maintenance, and End of Life; security updates within the support period are free of charge. See Support & Maintenance Lifecycle.&#x20;

**Reporting through national CSIRTs (13(11)).** The vulnerability disclosure policy recognizes that a reporter may report to a national CSIRT or to ENISA instead of, or in addition to, contacting Flopsar Technology Sp. z o.o. directly. See Vulnerability Disclosure Policy.&#x20;

**Due diligence on third-party components (13(15)).** All third-party components are inventoried in the SBOM, their licenses recorded, and their advisories monitored; vulnerabilities in them are remediated on the same terms as code written by Flopsar Technology Sp. z o.o. See Third-party Components & SBOM.&#x20;

**Keeping technical documentation up to date (13(19)).** An internal change-management process refreshes the technical documentation at every release; substantial modifications additionally trigger a revised EU declaration of conformity. See EU Declaration of Conformity.&#x20;

**Drawing up the EU declaration of conformity (13(20)).** The declaration is drawn up per product line and republished upon substantial modification, at a stable canonical URL. See EU Declaration of Conformity.&#x20;

**Affixing the CE marking (13(21)).** The CE marking is applied to releases placed on the market on or after December 11, 2027.

## Reporting obligations — Article 14

Article 14 of the Regulation, applicable from **September 11, 2026**, requires the manufacturer to report to the appointed CSIRT and to ENISA any **actively exploited vulnerability** contained in the product, and any **severe cybersecurity incident** that has an impact on the security of the product.&#x20;

Flopsar Technology Sp. z o.o. operates an internal incident reporting process that meets the timelines set by Article 14: an **early warning** within 24 hours of becoming aware that a vulnerability is actively exploited or that a severe incident has occurred; a **notification** within 72 hours, containing the information then available, including a preliminary assessment; and a **final report** within 14 days after a corrective measure has been made available, or after the incident has otherwise been handled.&#x20;

Reports are submitted through the single reporting platform operated by ENISA, once that platform is operational, in line with Article 16 of the Regulation. Until then, reports are submitted to the national CSIRT designated as a coordinator (in Poland, CERT Polska, operated by NASK PIB) through the channels that authority publishes.&#x20;

Reports made under Article 14 are **confidential** between Flopsar Technology Sp. z o.o. and the receiving authorities. Public communication about a vulnerability or incident is carried out separately, through Security Advisories, once a security update or mitigation is available, in line with Section 4 of this page and with the Vulnerability Disclosure Policy. The detailed internal procedure that governs Article 14 reporting is retained as part of the technical documentation referenced in Section 8.

## Technical documentation — Article 31 and Annex VII

Article 31 of the Regulation requires the manufacturer to draw up the technical documentation listed in Annex VII before placing a product on the market, and to keep it at the disposal of the competent national authorities for at least **ten years** after the product has been placed on the market.&#x20;

The technical documentation for Flopsar 7.x is retained internally by Flopsar Technology Sp. z o.o. and is **not published**. It is made available to market surveillance authorities upon a reasoned request, subject to the trade-secret protections of Article 53 of the Regulation.&#x20;

The technical documentation comprises, at a minimum, the items listed in Annex VII: a general description of the product, including its intended purpose, its versions and components, and its classification under the Regulation; a description of the design, development, and production of the product and of the vulnerability handling processes, including the secure development lifecycle; the cybersecurity risk assessment; the list of standards and specifications applied, with a description of the solutions adopted to meet the essential requirements where standards were not applied; the reports of the tests carried out to verify conformity; a copy of the EU declaration of conformity; and, where applicable, the software bill of materials.

## Conformity assessment procedure — Annex VIII, point 1

Flopsar uses the **internal production control (Module A)** procedure under Annex VIII, point 1 of the Regulation. Under that procedure, the manufacturer ensures that the design, development, and production process meets the essential requirements of Annex I; draws up the technical documentation referenced in Section 8; and draws up the EU declaration of conformity and affixes the CE marking in accordance with Article 30.&#x20;

**No notified body is involved.** If Flopsar 7.x — or any successor product line — were reclassified as falling within Annex III ("important", class I or II) or Annex IV ("critical") of the Regulation, this page and the corresponding EU declaration of conformity would be updated to reflect the change of category and of the applicable conformity assessment procedure (Module B+C, Module H, or the procedure prescribed by a relevant European cybersecurity certification scheme, as applicable).

## Substantial modification handling — Article 3(38)

A *substantial modification* is defined by Article 3(38) of the Regulation as a change to the product, following its placing on the market, that affects compliance with the essential cybersecurity requirements of Annex I, Part I, or that results in a modification to the intended use for which the product has been assessed.&#x20;

In line with Recital 60 of the Regulation, **routine maintenance releases — including security updates, bug fixes, and feature additions that do not affect the cybersecurity properties for which the product has been assessed or its intended use — do not constitute a substantial modification.**&#x20;

Flopsar Technology Sp. z o.o. performs and documents an internal review at every release within a product line to confirm whether a substantial modification has occurred. The outcome is retained as part of the technical documentation referenced in Section 8. Where a substantial modification has occurred, a revised EU declaration of conformity is issued and the change is recorded in the substantial modifications register on the EU Declaration of Conformity page.

## Standards and specifications applied

At the date of issue of this page, **no harmonized standards published in the Official Journal of the European Union under Regulation (EU) 2024/2847** covered the essential requirements of Flopsar 7.x. In accordance with Article 27 of the Regulation, conformity is demonstrated by reference to the following standards and specifications, applied in full or in part:

* ISO/IEC 27034-1:2011 — Application security — Overview and concepts
* ISO/IEC 29147:2018 — Vulnerability disclosure
* ISO/IEC 30111:2019 — Vulnerability handling processes
* ISO/IEC 27001:2022 — Information security management systems — Requirements
* IETF RFC 8446 — TLS 1.3
* IETF RFC 7748 — Elliptic curves for security (Curve25519, Curve448)
* IETF RFC 8439 — ChaCha20 and Poly1305 for IETF protocols
* CycloneDX Specification, version 1.6 (OWASP Foundation)
* OASIS Common Security Advisory Framework (CSAF), version 2.0&#x20;

No **common specifications** adopted by the European Commission under Article 27(5), and no **European cybersecurity certification schemes** adopted under Regulation (EU) 2019/881, are applicable to or claimed for Flopsar 7.x at the date of issue of this page. This section will be updated as harmonized standards, common specifications, or relevant certification schemes are published.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.flopsar.com/7/regulatory-compliance/cyber-resilience-act.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.