Version 1.0.0
Compliance posture
The security file provided in support of your accreditation, the reference texts, how obligations are split between the vendor and you, and what remains an unmade legal decision.
A software component is not accredited as such: the information system that hosts it is, by decision of your accreditation authority. Lemniscate supplies the component’s file, that is, the documents describing what it does, what it does not do, and how to check it (security white paper V3, section 10).
This page describes that file, the texts that shape the product’s design, how obligations are split between the vendor and you, and what remains an unmade legal decision. It is public and can be read without an account.
What this page is not
Section titled “What this page is not”This page is not legal advice. The compliance corpus classifies each control by
who is entitled to rule on it
(specs/2026-07-29-conformite/spec.md, §4):
| Verifiability | What the control covers | Who rules |
|---|---|---|
MACHINE | verifiable in the repository or in continuous integration, with fichier:ligne evidence | the tooling, with evidence |
JUGEMENT | a reasoned finding with no single mechanical assertion | the tooling, with a mandatory explicit reservation |
JURIDIQUE | legal determination: CRA role, GDPR role, NIS2 entity, AI Act risk class | a human, and only a human; without a human ruling, the control has no status |
The determinations listed below are recorded human rulings, copied from
specs/2026-07-29-conformite/spec.md §2. This page does not produce them.
The items in the security file
Section titled “The items in the security file”The file ships with the product and is kept up to date for each release (security white paper V3, section 10.1). Its items are designed to slot into your accreditation file without rewriting.
| Item | What it lets you do |
|---|---|
| Flow matrix | check every port and every destination with your own tools; no outbound traffic |
| Security target in CSPN format, provided on request | read the trust boundary (the gateway and the sandbox), the protected assets, the threats and the security functions |
| SBOM and VEX, generated for each release | know what is shipped, and the exploitability status of every published vulnerability |
| Escape scenario report | confirm that containment was tested on the shipped release |
| Schema of logged events | feed the logs into your SIEM |
| Installation guide and containment profiles | reproduce the reference configuration |
The flow matrix is reproduced in Architecture. The bill of materials, the VEX file and verification of the delivered artifact are described in What a buyer can verify themselves.
ANSSI recommendations
Section titled “ANSSI recommendations”Five ANSSI texts shape the design of Lemniscate (security white paper V3, section 10.2).
| Text | What the product sets against it |
|---|---|
| PA-102 guide, generative systems (2024) | partitioning in a dedicated environment, limits on automatic actions, logging of processing |
| ANSSI and BSI, coding assistants (2024) | deployment inside the perimeter, no confidential data sent to a third party, human review |
| ANSSI and BSI, zero trust and language models (2025) | minimal rights, decision traceability, human oversight of critical decisions |
| CERTFR-2026-ACT-016, agents on the workstation (2026) | explicit authorization rules, execution approvals, process isolation, sign-off by the IT department and the CISO |
| Sensitive architectures and Diffusion Restreinte | dedicated execution host, no container engine on workstations, logs to the network SIEM |
Bulletin CERTFR-2026-ACT-016 targets autonomous assistants installed on workstations that run commands with the user’s rights. The conditions it sets map to three mechanisms in the product: the authorization rules are the project policy, the execution approvals are validation by default, and the isolation is the sandbox (security white paper V3, section 5.4). These mechanisms are described in Execution safeguards.
How obligations are split
Section titled “How obligations are split”The texts split obligations between the vendor and you (security white paper V3, section 10.3).
| Who is covered | Text | What the product provides |
|---|---|---|
| Vendor | Cyber Resilience Act, Regulation (EU) 2024/2847 | 24 h notification of exploited vulnerabilities from September 2026; the full set of requirements in December 2027 |
| Customer | NIS 2 and its French transposition | logs, access control, component inventory and signed delivery chain, in support of your obligations |
| Customer | GDPR | data kept on your premises; the vendor processes no personal data on its own behalf |
| Customer | IGI 1300 and II 901 | deployment inside the accredited perimeter, no outbound traffic, documents supplied to the accreditation authority |
| Customer | ITAR and EAR | no transmission of technical data outside the perimeter; no re-export |
| Customer | DO-178C and aeronautical standards | proposed code goes through the same reviews as any contribution; the log establishes who accepted what |
NIS 2 and its French transposition apply to you when you are an essential or important entity. Defence and export control frameworks are treated as architectural constraints: no outbound traffic, no third party involved, no technical data outside the perimeter.
The vendor’s settled positions
Section titled “The vendor’s settled positions”The table below gives, regulation by regulation, the position the vendor has settled on regarding its own role.
| Regulation | Vendor’s role | Settled position | Weight | Deadlines |
|---|---|---|---|---|
| AI Act | integrator of third-party language models; does not train or fine-tune any model | not a GPAI provider, limited risk; Art. 50 transparency obligations only | light | none |
| GDPR | product installed inside your perimeter: the vendor receives no data (security white paper V3, sections 8.3 and 10.3) | the role is determined activity by activity. For the product installed on your premises, the vendor processes no personal data on your behalf: it is neither processor nor controller, and you handle data subject requests yourself. A support engagement giving the vendor regular access to your logs or your sessions would make it a processor, under an Art. 28 contract. No customer data feeds any training | moderate | none |
| NIS2 | below the thresholds (fewer than 50 employees and under €10M in revenue) | not a directly regulated entity: size decides. The regulation reaches the vendor indirectly, through its customers’ supply chain clauses (Art. 21(2)(d)) | indirect | none |
| CRA | manufacturer; Module A self-assessment likely | the structuring regulation: software bill of materials (Annex I §2.1), coordinated disclosure and point of contact (Art. 13(5)), free updates for at least 5 years, reporting at 24 h / 72 h / 14 d (Art. 14), technical documentation, CE marking | heavy | reporting Sept. 2026 · CE marking Dec. 2027 |
| DORA | third-party ICT provider only if the vendor has “financial entity” customers | conditional: triggered in that case only, through Art. 30 clauses. Treated as conditional, not as settled | conditional | none |
Two cross-cutting readings:
- The first hard deadline is the CRA reporting obligation of September 2026. It
changes the scope of two internal commitments: the software bill of materials
(
SEC-9.3-01) and artifact signing (SEC-9.4-*) become requirements with a dated deadline. - All five regulations are anchored in Union law. None of these obligations depends on United States federal policy. The OSCAL format, which comes from NIST, is used as a format and as an optional cross-reference; no control invokes it as an authority.
Evaluation
Section titled “Evaluation”The vendor gives the customer the means to check (security white paper V3, section 10.4).
- Penetration test. You can run it yourself, or hand it to your qualified provider, on the scope of the first deployment. The code and the artifacts are supplied to the auditor.
- Security target. It is written in CSPN format and provided on request. The evaluation will be started once the scope is frozen.
- The vendor’s internal security policy. It is self-assessed against ANSSI’s IT hygiene guide, and the state of the measures is shared on request.
- Access to the code for audit, under a confidentiality agreement.
SecNumCloud: what the vendor cannot claim
Section titled “SecNumCloud: what the vendor cannot claim”SecNumCloud does not qualify a software vendor whose product is installed on the
customer’s premises. The v3.2 framework qualifies operated cloud service
providers; it is written in terms of “the provider shall…”. Software that the
customer installs and runs itself is not a service operated by the vendor. The
qualification, where one exists, belongs to the hosting provider or the operator,
that is, to the customer
(specs/2026-07-29-conformite/spec.md, §2bis, checked against the official v3.2
framework).
That framework requires neither a component-by-component software bill of materials nor build provenance. The closest chapter (ch. 8.1.b) asks for an inventory of deployed software with version numbers. The expectation of a complete bill of materials comes from the CRA.
Three channels of contractual trickle-down
Section titled “Three channels of contractual trickle-down”Some requirements land on the vendor without it being the regulated entity:
- SecNumCloud ch. 15.2 and 14.5: a customer having a service that includes Lemniscate qualified must require from its third parties (“developer, integrator, subcontractor”, ch. 15.1.a) a security level that is “at least equivalent”, with audit clauses (ch. 15.2.b).
- LPM / OIV: an operator of vital importance contractually requires its suppliers to provide ongoing security maintenance: monitoring, detection and remediation of vulnerabilities.
- NIS2 Art. 21.d: customers that are essential entities assess their suppliers’ cyber maturity and insert security clauses.
Reservation recorded in the source: the SecNumCloud chapters are taken from the
official v3.2 framework, but the LPM and NIS2 article numbers come from secondary
summaries. They still have to be validated article by article by an information
systems security expert or a lawyer. This reservation appears in
specs/2026-07-29-conformite/spec.md §2bis; it has not been lifted.
What is said and what is not claimed
Section titled “What is said and what is not claimed”The table below is taken from specs/2026-07-29-conformite/spec.md §6. It amounts
to a language commitment: nothing in the right-hand column is written in any
commercial document, any questionnaire response, or any page of this site.
| Defensible wording | What is not claimed |
|---|---|
| “developed to the applicable requirements of SecNumCloud v3.2 (ch. 14, 12.11, 8.1) and deployable within an environment that is itself qualified by its operator” | any claim of a SecNumCloud certification or qualification held by the product, or of an ANSSI approval |
| “compliant with the applicable requirements of the CRA” (bill of materials, vulnerability handling, notification), in readiness | any claim of a CRA certification, or of a CE marking already obtained |
| “makes our customers’ LPM and NIS2 compliance easier: security and audit clauses accepted, ongoing security maintenance, bill of materials supplied” | any claim of NIS2 compliance in its own right: the vendor is not the regulated entity |
| “deployable offline, with no outbound traffic, deployment sovereignty” | none |
The vendor holds no certification, and the CSPN-format security target has not yet been evaluated. The presumption of conformity that the European EUCC certification will bring to the CRA is not finalized; it is not presented as settled.
How a claim is traced
Section titled “How a claim is traced”The posture above rests on a technical reference set.
specs/securite/referentiel.md breaks the architecture and security guarantees
document down into 286 stable identifiers SEC-*. Each one carries its nature
(CODE, CICD, DOC, ORGA, CONTRAT, HOTE) and its audit axis; a change
proposal references the identifiers it covers. The status of each requirement and
the evidence that establishes it live in dated records
(specs/securite/snapshots/, one file per date), not in the reference set
itself.
Two method rules go with it:
- A status is not recorded on the strength of a configuration file, but on that of an observed effect. An option written correctly but with no measured effect does not count as a control met.
- A single technical fact has a single status. A technical regulatory control is
not re-audited: it inherits the status of the corresponding
SEC-*, and the worst status wins. A requirement shared by the CRA and NIS2 therefore has one value only, whichever regulation is invoked.
Security architecture decisions are recorded in
specs/securite/arbitrages.md along with the options ruled out and the criterion
that decided, the form an auditor expects when asking why a given path was chosen.
What remains an unmade legal decision
Section titled “What remains an unmade legal decision”These points carry an empty status in the corpus. They are neither decided nor presented as such.
- Whether DORA applies. Does the vendor target “financial entity” customers? Until
the question is settled, DORA remains an inactive conditional section
(
specs/2026-07-29-conformite/spec.md, §8, open decision no. 1). Nothing is claimed about Art. 30 clauses. - Certification path. ISO 27001 first or EUCC afterwards: the order is not settled (§8, open decision no. 2). No deadline is communicated.
- Article-by-article validation of the LPM and NIS2 references in §2bis, by a human expert, before the regulatory control catalogue is frozen.
Further reading
Section titled “Further reading”- What a buyer can verify themselves: software bill of materials, VEX file, scans, verification of the delivered artifact.
- What remains to be built: the axes that are specified and not shipped, stated without a date.
- Where the data goes: where each category of data lives, and which flows exist.
- Execution safeguards: the seven guarantees of a session and the mechanisms that uphold them.