Certification support · Common Criteria / EUCC · FIPS 140-3
Prepare your product for an independent security evaluation
We help device and software manufacturers prepare their product, documentation and team for a security evaluation. We support work relating to Common Criteria and EUCC, and the preparation of cryptographic modules for FIPS 140-3 validation.
We start with the customer’s requirements and an analysis of the product. We define the preparation scope, identify gaps and help develop the materials needed to work with a laboratory.
For manufacturers and R&D teams
We support manufacturers of embedded, IoT and IIoT products, networking and security devices, encrypted storage and cryptographic modules. We work with engineers, product owners and people responsible for quality and security.
A good time to begin is when certification appears in a customer enquiry, you plan to enter a new market or you are preparing a significant hardware or firmware change. We help assess which preparations are justified and what they will require from your team.
Two support paths
Common Criteria and EUCC
The evaluation covers the security properties of a specific product or component within an agreed scope and configuration. We help translate customer requirements into preparation for the evaluation process.
- Define the Target of Evaluation (TOE), its boundaries, version and operating environment.
- Analyse Protection Profiles and security requirements.
- Develop or update the Security Target — the security specification for the TOE.
- Prepare architecture, interface, guidance, lifecycle and developer testing documentation.
We tailor the documentation scope to the product, adopted requirements and agreed evaluation path.
FIPS 140-3
Validation concerns a cryptographic module in a specific version and configuration. We help define its scope and prepare documentation and evidence for the module’s design and operation.
- Define the module boundary, components and operational environment.
- Prepare the Security Policy describing the module and its secure operation.
- Organise documentation of roles, services, keys and other sensitive security parameters.
- Prepare materials on module self-tests, integrity, entropy sources and configuration management.
We account for supplier dependencies and the required algorithm and entropy-source validations. We agree requirements and evidence collection for the specific module and target security level.
Our role in the process
B4Future provides advisory and preparation work on the manufacturer’s side. For CC/EUCC, an ITSEF laboratory performs the formal evaluation and the certification body makes the decision. For FIPS 140-3, an appropriately accredited CSTL performs testing and the CMVP programme conducts validation.
We agree the organisations involved and working arrangements for each project. Each path retains its own requirements, documents and formal outcomes.
What you receive
Readiness assessment and work plan
We review available materials, customer requirements and options for preparing the product for evaluation. You receive a list of gaps, priorities and a work plan with responsibilities and supplier dependencies.
Documentation linked to the product
We develop and review materials appropriate to the chosen path. We connect requirements with the implementation description and test results, linked to specific hardware, firmware and software versions.
Support in working with the laboratory
We help agree inputs, prepare answers to questions and maintain a record of findings. We coordinate updates to documents and evidence with the manufacturer’s team.
Preparing for subsequent changes
We help assess how a new release, component update or cryptographic change affects the evaluation scope and documentation. We prepare materials needed for the relevant certification or validation maintenance process.
Embedded systems, cryptography and the lifecycle
We account for dependencies between hardware, firmware and software: secure boot, updates, key management, configuration and interaction with supplier components. Documentation reflects the product’s actual architecture and behaviour.
The work can connect with secure development, vulnerability handling, CRA readiness and planning cryptographic changes. We assess the applicability of documents and evidence separately for each purpose.
CRA and the product lifecycle · PQC and crypto agility · OT cybersecurity
Start with one product
Tell us what you are developing, the product’s stage and the requirement raised by your customer. If you know the expected scheme, level or deadline, include it in your message.
We will use this to define the first review. We will exchange detailed technical documentation once confidentiality arrangements are agreed.