CRA class I security software: module A or notified body

Does the Cyber Resilience Act for identity, VPN and security software mean a notified body?

Identity management, privileged access management, password managers, VPN products, SIEM systems and PKI or certificate issuance software are class I important products under Annex III of the Cyber Resilience Act. A manufacturer of these products may use module A, internal control with a self-declared conformity assessment, only if it has applied in full the harmonized standards, common specifications or a European cybersecurity certification scheme at assurance level at least substantial. If it has not, module B with module C, or module H, requires a notified body to be involved. The answer depends on three things: the exact Annex III category the product falls into, how completely the relevant standards have been applied, and whether the product is free and open source. Implementing Regulation (EU) 2025/2392 sets out the technical description of each category, and it is the first document to check. Its identity management description expressly covers single sign-on, federated identity, one-time password and multi-factor authentication software, so a vendor whose core product is access control should assume the stricter route unless its standards mapping shows otherwise. Free and open-source software in Annex III categories may use module A under Article 32(5), provided the technical documentation is made public when the product is placed on the market.

Roles matter here. The manufacturer owns conformity, the technical documentation and the EU declaration of conformity, and it cannot delegate those duties. A notified body, listed in the Commission's NANDO system, issues any third-party certificate that the chosen route requires. DeployOpen prepares systems, configurations, logs and evidence for that assessment, but it does not issue certificates or declarations. Before budgeting, ask your legal or compliance team to confirm the category your product falls under, and ask any notified body you approach to state which module it would assess against and what evidence it expects for your standards position.

When module A is allowed for class I security software

Class I security products can use internal control (module A) only in narrow circumstances set by Article 32. Each card below is a decision point that determines whether a vendor self-assesses or needs a notified body, so check each one against your product before choosing a route.

Full application of harmonized standards

Module A is open to a class I manufacturer only if it has applied in full the harmonized standards that cover its product. Partial application does not count, so a vendor that meets most requirements of a relevant standard but skips some clauses cannot use self-assessment on that basis. Map each standard clause to a product feature and a test result, and record any gap. If a gap exists, plan for a notified body before the product is placed on the market.

Common specifications

If no harmonized standard exists for the category, the Commission may adopt common specifications, and applying them in full also opens the route to module A. Check whether any common specifications apply to your category and whether they have been adopted, since the route depends on the specification being in force. Document which specification you applied and how each requirement was met, so an assessor or market surveillance authority can trace the claim.

European cybersecurity certification at substantial assurance

Module A is also available where the product holds a European cybersecurity certification scheme certificate at assurance level substantial or higher. Confirm that a scheme covers your specific category and product version, because a certificate for one product line does not automatically extend to another. Keep the certificate and its scope statement in the technical documentation, and track its validity period so the declaration of conformity stays accurate.

Module B with module C or module H

Where none of the above applies in full, class I important products must go through a notified body. Module B is a type examination by the notified body, combined with module C, which covers internal production control. Module H covers full quality assurance supervised by the notified body. Ask any notified body which module it offers for your category, how long its review takes and what evidence it expects before you start preparing the technical file.

Open-source software under any Article 32(1) procedure

Article 32(5) allows free and open-source software in Annex III categories to use any Article 32(1) procedure, including module A, provided the technical documentation is made public when the product is placed on the market. This applies to open-core and community versions of security tools. Confirm which components are covered by the open-source exemption, and separate commercial add-ons that remain proprietary, since those may still need a different route.

Confirm which standards are published

Harmonized standards for class I categories are still being developed under standardization request M/606, so do not assume a standard is available for your category. Check the Commission's current list of harmonized standards and their publication status, and record the date you checked. If a standard you need is not yet published, the module A route is not open on that basis, and the notified body route becomes the planning assumption.

What the access control requirement asks of identity and privileged access products

The access control and authentication requirements in Annex I Part I are product properties. They apply to any product with digital elements, and a manufacturer applies them through its own cybersecurity risk assessment rather than a fixed checklist. For an identity, VPN or privileged access product, the practical question is what happens to access when the product ships, when it is configured by a customer and when it is attacked. Confirm the exact point numbers in the (2) sub-points against the Annex I text on EUR-Lex before you map them to your design documents, because the numbering is the reference an assessor will use. In practice, four areas need a documented decision. The first is default configuration: the product should not ship with shared administrator accounts, default passwords, open management interfaces or permissive policies that a customer must remember to tighten. The second is authentication strength, meaning which factors the product supports, whether multi-factor authentication can be enforced for administrators, and how one-time passwords, federation and single sign-on tokens are validated and expired. The third is protection of credentials and stored data: how secrets, signing keys, session tokens and recovery codes are encrypted at rest and in transit, and who can read them. The fourth is logging of access, covering authentication events, privilege changes and administrative sessions, with records that a customer can export into its own monitoring.

The stakes are higher for this group than for most products because the access control requirement sits on top of class I classification. Identity management and privileged access management software, including authentication and access control readers, are themselves important products under Annex III point 1. That means the conformity route is stricter: module A (internal control) is available only where the manufacturer has applied the relevant harmonized standards, common specifications or a European cybersecurity certification scheme in full at assurance level substantial or higher. If that is not the case, a notified body becomes involved. Before you commit to a route, document which standards you apply, which you do not, and why, and confirm the current status of the harmonized standards with your notified body or the Commission's CRA implementation page.

How the route differs for IAM, VPN, SIEM and PKI vendors

Identity management and privileged access management systems are listed in Annex III point 1 as class I important products. The technical description in Implementing Regulation (EU) 2025/2392 expressly covers single sign-on, federated identity, one-time password and multi-factor authentication software, so a vendor whose core function is controlling access starts on the stricter route. Authentication and access control readers fall under the same point. Review the Annex III list in the regulation before scoping.

Annex III point: Point 1 covers identity management and privileged access management software and hardware, including authentication and access control readers.
Functional test: Article 7(2) asks whether the function is primarily critical to the cybersecurity of other products, networks or services, or carries a significant risk of adverse effects. Central access control usually meets the first limb.
Evidence set: A threat model for authentication flows, technical documentation covering session handling and credential storage, and vulnerability handling records kept for the full support period.
Typical conformity question: Whether harmonized standards, common specifications or a certification scheme have been applied in full at the required assurance level, because that decides whether module A is open to you.
Open-source route: Under Article 32(5), open-source products in these categories may use module A if the technical documentation is made public when the product is placed on the market.

Confirm which authentication functions sit inside the category text before assuming a lighter route.

How the open-source route works for security software

Article 32(5) lets free and open-source software in Annex III categories use any Article 32(1) procedure, including module A (internal control), provided the technical documentation is made public when the product is placed on the market. For an identity provider, VPN client, password manager or SIEM that is published under an open-source licence, this can remove the notified body step that would otherwise apply to a class I important product. The exemption does not change the substance of the Annex I essential requirements or the vulnerability handling duties, so the maintainers still have to produce the risk assessment, the technical documentation and the support period evidence before the release goes out.

The exception attaches to the software placed on the market, not to the company behind it. Many security vendors run an open-core model in which a community edition is published openly while an enterprise edition adds directory connectors,高 availability clustering, hardware token support, audit reporting or paid support. Before relying on Article 32(5), the vendor should list every build, plugin and commercial add-on it distributes, then decide which ones are the open-source product and which are separate products with their own conformity route. Each build that is not covered by the exception needs its own assessment under module B with module C or module H, depending on the harmonized standards applied.

Commercial add-ons and proprietary components bundled with an open-source core are where the boundary is most often disputed, so confirm the treatment with qualified legal counsel before publication. Ask counsel to review the licence terms, the distribution channels for each edition, and whether a paid support contract changes the classification of the code it covers. Also confirm with the relevant market surveillance authority or the Commission guidance on free and open-source software how the boundary is read, since the guidance is non-binding. Document the decision, because an assessor or regulator will ask how the scope line was drawn.

How a class I conformity file is prepared, step by step

This sequence turns a set of identity, VPN or security products into a conformity file that an assessor can test, a notified body can review where required, and the manufacturer can back with an EU declaration of conformity and CE marking. Each phase closes with a named output that feeds the next.

Scope and classify each product line
The manufacturer lists every product, edition and variant that carries digital elements and checks each against the Annex III categories and the Article 7(2) test. The question is whether the product primarily performs functions critical to the cybersecurity of other products, networks or services, or carries a significant risk of adverse effects. Products such as single sign-on, password managers, VPN clients, SIEM and PKI tools commonly fall in class I, while some bundled or peripheral components may not. The output is a product register that records the category, the reasoning and the owner of each decision, reviewed by legal or compliance staff before the file is built.
Map each product to its technical description
For every class I product line, the team reads the matching category in Commission Implementing Regulation (EU) 2025/2392 and records which features the product includes. Identity categories, for example, expressly cover single sign-on, federated identity, one-time password and multi-factor authentication software, and browser categories cover browsers with AI agent integration. Products that combine several functions are mapped against each relevant description. The output is a mapping table that lists each feature, the description it falls under and any gap the team must close before the product is released.
Select harmonized standards and record full application
The team identifies the harmonized standards, common specifications or European cybersecurity certification schemes that apply to each category and decides which ones it will apply in full. Full application matters because Article 32(2) allows internal control under module A only where these instruments have been applied in full at the required assurance level. Where the team applies only part of a standard, it records that gap and plans for a notified body route. Standards are still being developed under standardization request M/606, so the team should confirm the current status with the standardization bodies and its national standards organization. The output is a standards register showing each instrument, its scope and whether it was applied in full.
Build the technical documentation and risk assessment
Engineering and security staff write the cybersecurity risk assessment that drives the Annex I Part I essential requirements, then record how each product meets them, including identity, access control, cryptographic key handling, logging and update behavior. The technical documentation pulls together the design, the risk assessment, the test results, the software bill of materials and the support period. External penetration testers or a security testing partner can supply independent evidence for these records, but the manufacturer keeps ownership of the documentation. The output is a versioned technical file per product with a named reviewer and a sign-off record for each release.
Decide between module A and a notified body route
With the standards register and technical file in hand, the team decides which conformity assessment route applies. Module A, internal control, is available for class I products only when harmonized standards, common specifications or a certification scheme at the required level have been applied in full. Otherwise module B with module C, or module H, requires a notified body. Free and open-source software in Annex III categories may use any procedure, including module A, if its technical documentation is made public when placed on the market. The output is a written route decision signed by the accountable executive, with the reasons and any notified body selection criteria, listed in the Commission's NANDO system.
Prepare the EU declaration and CE marking
Once the route is complete, the manufacturer prepares the EU declaration of conformity for each product and affixes CE marking as the regulation requires. The declaration names the product, the applicable instruments and the conformity route, and it is signed by an authorized person. The team checks that version identifiers match the technical file so that the declaration describes what customers actually receive. The output is a signed declaration and a labeling record for each released version, kept with the technical file for the period the regulation requires.
Set up vulnerability handling and Article 14 reporting
The team establishes the eight Annex I Part II vulnerability handling processes, including a coordinated disclosure policy, a way to receive vulnerability reports, security updates and a plan for the support period. It also prepares the Article 14 process to notify actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform, which has applied to manufacturers since 11 September 2026. Named contacts, escalation steps and a test of the notification path should exist before a product ships. The output is an approved vulnerability handling procedure, a reporting runbook and a dated record of the first test exercise.

What conformity for class I security software costs and who is paid

This table compares the main cost components of conformity for class I security software, showing who is paid for each, whether the cost is one-time or recurring, and what drives it up. No figures were published for these items, so use the table to frame written quotes from notified bodies and implementation partners.

Cost component	Who is paid	One-time or recurring	What drives the cost
Notified body assessment (module B with C, or module H)	Notified body, designated by a Member State and listed in NANDO	One-time per assessment, plus periodic surveillance	Product scope, number of variants, depth of technical documentation review, and whether harmonized standards are applied in full
Internal engineering and product security time	Your own staff, or contractors you engage	Largely one-time for the initial build, recurring for each release	Architecture maturity, number of access control and authentication modules, and release frequency
Implementation partner fees for evidence and hardening	Implementation partner, under a written fixed scope	One-time for the initial scope, with optional retainers afterward	Gaps in existing documentation, hardening needed for identity, PKI or VPN components, and the number of systems in scope
SBOM and vulnerability scanning tooling	Tool vendors or open-source tooling run by your team	Licences recur if commercial; open-source tooling carries staffing cost	Number of dependencies, build pipelines, and whether SBOMs are generated and kept current per release
Penetration testing and security testing	Independent testing firm or internal red team	Recurring, typically per major release or annually	Attack surface of authentication flows, admin interfaces and cryptographic handling
Legal review of declarations and conformity documents	Outside counsel or internal legal	One-time for the initial EU declaration, recurring on material change	Contract structure, number of Member States of distribution, and use of other operators
Cost of non-compliance	Not a fee, but a potential penalty	Exposure applies on breach	Article 64 sets maximum fines of EUR 15 million or 2.5% of total worldwide annual turnover for breaches of Annex I and Articles 13 and 14, whichever is higher

What makes class I conformity more expensive or slower

Class I conformity cost and timing depend on how much of the product must be independently assessed and how ready the evidence is before an assessor sees it. The cards below cover the decisions and inputs that move a project toward a faster, cheaper route or toward a longer, costlier notified body review.

Number of product lines and variants

Each product line, edition and deployment variant that carries its own technical documentation and declaration multiplies the assessment work. A single SIEM codebase sold as cloud, on-premises and appliance builds can require separate evidence for each form factor. Ask engineering to list every shipped variant and map which ones share a codebase, build pipeline and security configuration before any quote is requested.

Depth of harmonized standards application

Module A, internal control, is open to class I manufacturers only where harmonized standards, common specifications or a European cybersecurity certification scheme have been applied in full. Partial application pushes the product toward a notified body. Track each requirement of Annex I against the standard that covers it, and record any gap, since the standards are still being produced under standardization request M/606.

Whether a notified body is required

Routes B with C, or H, bring a notified body into the assessment, which adds review time and fees that the manufacturer pays directly to the body. Identity, PKI and privileged access products that do not fully apply the standards fall into this group. Ask the product lead to state, in writing, which route applies and why, before a notified body is contacted.

Evidence maturity and existing artifacts

Existing SBOMs, threat models, secure development records and vulnerability handling procedures shorten the path to a complete technical file. Products that lack these documents need them created from scratch, which is usually the largest and least predictable effort. Inventory which artifacts exist, how current they are and whether they cover the full support period.

Third-party and open-source components

Components inherited from libraries, operating systems, browsers or cloud services must be identified, assessed for vulnerabilities and documented as part of the product. Access control and VPN products often embed cryptographic and networking libraries whose maintainers publish irregular updates. Require a current component inventory with licenses, versions and a named owner for each dependency.

Notified body availability for the category

Assessment capacity depends on how many notified bodies are designated for class I categories and how much demand they face near the compliance dates. Notified bodies are notified by Member States and listed in the Commission's NANDO system, so the list of eligible bodies changes over time. Confirm in NANDO which bodies cover the relevant category, ask for their current queue and request a written scope before committing to a timetable.

Who does what: the vendor, the implementation partner and the assessor

The manufacturer is the legal person that places the identity, VPN or security product on the EU market under its own name. Under the CRA that organization owns the outcome: it performs the cybersecurity risk assessment, decides how each Annex I Part I essential requirement is met, maintains technical documentation, draws up the EU declaration of conformity, affixes the CE marking and runs vulnerability handling and reporting for the support period. No vendor or consultant can take these duties over.

Risk assessment ownership: the manufacturer documents the threat model and the reasoning behind each control choice, including the access control design for authentication and privileged access features.
Declaration and marking: the manufacturer signs the EU declaration of conformity and affixes CE marking only after the conformity route it chose is complete.
Vulnerability and reporting duties: the manufacturer runs the PSIRT process and the Article 14 reporting duty through ENISA's Single Reporting Platform.
Technical documentation: the manufacturer keeps the file that an authority or assessor may request, including evidence produced by partners.
Routing decision: the manufacturer confirms the class I route, including whether module A is available under Article 32.

Before engaging anyone, confirm internally which person holds each of these duties and who approves the declaration.

How to choose a notified body or consultant for security software

Class I security products often need a notified body rather than self-assessment, so the choice of assessor carries real weight. The cards below cover how to confirm designation, test independence, check experience, scope the work and keep the implementation partner's role separate from the assessor's.

Confirm designation for the category

A notified body only counts for a CRA assessment if a Member State has notified it for the relevant class I category. Check the body's entry in the Commission's NANDO system and confirm that the listed scope covers the specific Annex III category your product falls under, such as identity management, password managers, VPN products or SIEM systems. A general listing for software conformity is not enough. Ask the body to show the scope in writing and confirm the designation date before you commit.

Test independence from the vendor

The assessor must not design, build or operate the product it assesses. Ask whether the body or any affiliated consultant has provided development, hosting, or security tooling to your organization in the past, and whether it holds any financial interest in your company. Request a written statement of impartiality and ask who on the team would sign the conformity assessment. Independence also affects how the assessor reviews a product that uses access control as its core function.

Check experience with identity and security products

Identity management, privileged access management, PKI and SIEM products have specific failure modes, including credential handling, key lifecycle and log integrity. Ask for named assessors and their experience with comparable products, not general software audits. Ask how the body treats single sign-on, federated identity and one-time password functions, since the technical description in Implementing Regulation (EU) 2025/2392 names these expressly. Request references from comparable engagements and confirm that the people who will work on your file are the people described.

Ask these questions before signing scope

Before signing, ask which conformity module the body expects to use for your product, and whether your harmonized standard application would allow module A. Ask what evidence the body will request, how long its review queue is, what happens if a finding requires a rework, and how it handles surveillance after the initial assessment. Get the answers in writing and check that they match the fixed scope, deliverables and timeline in the contract. Ask for the fee structure, including what is charged for re-assessment.

Separate the partner's work from the assessor's

An implementation partner can prepare systems, controls, technical documentation and evidence, but only the independent assessor issues the conformity assessment outcome. Write this split into both contracts: the partner delivers the technical file and remediation work, and the assessor reviews it without shaping its conclusions. Avoid arrangements where the same party writes the evidence and also signs off on it. Keep a record of which party produced each document so the assessor can trace the chain of evidence.

Questions security software vendors ask about CRA class I

Is a password manager a class I product under the CRA?

Yes. Annex III lists password managers as a class I important product category, so the product sits outside the default route and needs the conformity assessment for important products. Whether you can use internal control (module A) depends on Article 32(2): you must have applied in full the harmonized standards, common specifications or a European cybersecurity certification scheme at assurance level at least substantial. If you have not, a notified body must be involved under module B with module C, or under module H. Classification follows core functionality, so a password manager that also ships a browser extension, sync service or emergency access feature should be checked against the technical descriptions in Implementing Regulation (EU) 2025/2392 before you settle the route. Confirm the category wording with a notified body before you commit to a route.

Does a SIEM system always need a notified body?

No, but in practice many SIEM vendors will need one. SIEM systems are a class I important product category under Annex III point 7 because they collect and correlate security data. Under Article 32(2), module A is available only when harmonized standards, common specifications or a European cybersecurity certification scheme have been applied in full. The Commission's standardization request M/606 asks for 26 product-specific standards due 30 October 2026, so a complete, published set covering your product may not exist yet. Check whether a standard for your category is published, document each clause you apply, and ask a notified body to confirm your route in writing. If you cannot show full application, plan for module B with module C or module H.

Can an open-source VPN vendor self-assess under module A?

It may be able to, if the product is free and open-source software in an Annex III category and its technical documentation is made public when it is placed on the market. Article 32(5) allows free and open-source software in these categories to use any Article 32(1) procedure, including module A. The public documentation condition is strict, so a project that keeps design or build documents internal does not meet it. Open-source licensing does not exempt a commercial vendor from the rest of the regulation. A company that sells a paid edition, support or hosted service around the code should confirm which products fall under the exception. The Annex I essential requirements and vulnerability handling duties still apply. Ask a notified body or legal adviser to confirm your release model and distribution before relying on self-assessment.

How long does CRA conformity assessment take for a class I product?

The regulation does not set a duration, and this page does not supply one, so the timeline depends on your route, the notified body's workload and how much technical documentation you already have. Timing drivers include whether you apply harmonized standards in full for module A or need a notified body under module B with module C or module H, how complete your cybersecurity risk assessment and technical file are, and how many product variants you certify. Ask each notified body for a written timeline, the documents it will review and the points where it may return findings. Also note the dates that frame planning: the Article 14 reporting obligations apply from 11 September 2026, and the regulation applies from 11 December 2027.

What does a CRA class I project need from our engineering and product staff?

It needs named owners from product security, engineering, support and legal, plus steady time from the people who know the architecture. Engineering work includes the cybersecurity risk assessment that the Annex I requirements depend on, documentation of authentication, credential storage, key management and update signing, and an SBOM that stays current. Support and vulnerability handling must run for the whole support period. Product management decides the support period and the variants in scope. Legal or compliance staff own the EU declaration and the choice of conformity route. Ask any outside partner to show which tasks it performs and which need your staff, and confirm in writing who signs each document.

Can an implementation partner handle CRA conformity for us alone?

No. The manufacturer owns conformity, and the obligations sit with it, so no partner can take that responsibility alone. A partner can prepare systems, technical documentation, evidence and the vulnerability handling process, and it can support security testing. Where a notified body is required, only that body issues the conformity assessment outcome. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, runs security testing, and prepares systems and evidence for assessments. It does not issue reports or certificates. Agree the split of responsibilities in a fixed written scope, with a named owner for each deliverable.

Why does an access control product face stricter conformity assessment?

Because Annex III point 1 lists identity management systems and privileged access management software and hardware as class I important products, including authentication and access control readers. Products whose core function is access control are therefore classed as important, and the stricter route follows from that classification. Implementing Regulation (EU) 2025/2392 expressly includes single sign-on, federated identity, one-time password and multi-factor authentication software in the identity management category, so these features fall within scope even if the product is marketed differently. Vendors should map each authentication feature to the category description and keep that mapping in the technical file. Confirm the classification and route with a notified body before you rely on module A.

What is still uncertain in the standards pipeline for security software?

The harmonized standards that would let you use module A are not all final, so the notified body route remains relevant for many class I products. Commission standardization request M/606 asks European standardization organizations for 41 harmonized standards: 15 horizontal standards grouped in three deliverables due 30 August 2026 or 30 October 2027, and 26 product-specific standards due 30 October 2026. Until a standard covering your category is published and applied in full, you cannot use it to support module A. The Commission's guidance is non-binding and does not replace the standards. Watch which standards cover identity, SIEM and PKI categories, and whether a European cybersecurity certification scheme reaches assurance level substantial. Confirm current status with the notified body before committing budget.

Which dates apply to security software vendors

Security software vendors need to plan against four dates in Regulation (EU) 2024/2847. The regulation entered into force on 10 December 2024, which is the start of the clock but not a compliance deadline for most duties. Chapter IV, which sets the rules for notifying conformity assessment bodies, applies from 11 June 2026. This matters for an identity, VPN or SIEM vendor because a class I product that cannot apply the harmonized standards in full will need a notified body, and notified bodies must be designated under those rules before they can take that work. The Article 14 duty to report actively exploited vulnerabilities and severe incidents applies from 11 September 2026. General application follows on 11 December 2027, when the Annex I essential requirements and the other manufacturer obligations start to bind the product.

The transition rule for products already on the market is easy to misread. A product placed on the market before 11 December 2027 falls under the regulation only if it is substantially modified from that date. An MFA server or password manager released in 2025 therefore does not need to be re-assessed merely because the calendar has moved, but a major rewrite of its authentication flows or a new class of functionality could bring it into scope. The Article 14 reporting duty is different. It applies to every in-scope product whenever it was placed on the market, so a vendor should confirm now which of its shipped versions could carry an actively exploited vulnerability and who in its organization would make a report within the required window.

The Commission's standardization request M/606 asks European standardization organizations for 41 harmonized standards. Fifteen are horizontal standards grouped in three deliverables, due 30 August 2026 or 30 October 2027, and 26 are product-specific standards due 30 October 2026. Those dates matter for class I vendors because the route to module A depends on applying harmonized standards in full. Before scoping a conformity assessment, ask your product team which deliverables exist when you plan the work, confirm the current status of each standard with the standards bodies, and build a schedule that allows for a notified body if a standard is not yet available or cannot be fully applied.

How DeployOpen prepares class I security products for assessment

DeployOpen works on the self-hosted open-source platforms that identity, VPN and security vendors run inside their own infrastructure. The work prepares systems, controls and technical evidence for the conformity route your product actually needs, while your organization keeps ownership of its controls and the independent assessor issues any conclusion.

How we scope

Each engagement starts with a written scope naming the class I category, the platform components and the environments in each case.
We confirm which Annex III category your product falls under and whether harmonized standards are applied in full.
Scope, deliverables and timelines are agreed in writing before any work begins, and the quote follows from that scope.
Ask us to state which assessment route the scope assumes and which parts depend on a notified body.

How we build

We deploy and harden the self-hosted platform inside your cloud accounts, data centers or air-gapped networks.
We configure access control, authentication and logging so the security properties can be tested and evidenced.
We run security testing against applications, APIs and infrastructure, and document the findings and fixes.
Where the product is open source, we help prepare the public technical documentation the route requires.

How we hand over

We produce the technical documentation and configuration records that your team and the assessor will review.
We document the vulnerability handling process and the operating procedures your staff will run after handover.
Deliverables are handed over with runbooks, backup and upgrade procedures, and a list of open items with owners.
The organization retains ownership of its controls, and assessment reports and declarations come from independent bodies.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after the initial scope closes.
Retainers can cover vulnerability monitoring, patching and re-testing when the platform or its dependencies change.
Confirm with us in writing which support period and response expectations apply before you sign the retainer.