Skip to content

Cooperation · knowledge and development

Bring our expertise together around a concrete problem

We invite manufacturers, operators, technology companies and research organisations to work together on product security, OT environments and cryptography.

A white arch, grey plane and blue bridge forming a complementary composition.

Areas of cooperation

Workshops and knowledge exchange

Who for: manufacturers’ and operators’ teams, industry organisations and education partners.

Need: a shared language for discussing the CRA, OT security or cryptographic change among participants with different roles and knowledge levels.

Working together: the partner brings participants’ perspectives and examples of decisions; we prepare the programme, scenario and workshop facilitation.

Outcome: team materials, an agreed description of needs and a list of next actions.

Working methods and evidence

Who for: product owners, R&D, quality and security teams, and partners supporting their processes.

Need: connect scattered requirements, component information, risk findings and test results to a specific product release.

Working together: the partner shares agreed examples and the team’s working practices; together we design responsibilities, templates and a review schedule.

Outcome: a documented method, documentation templates and a chain of decisions and evidence checked against an example.

Technology partnerships

Who for: hardware and software suppliers, integrators, laboratories and teams developing security tools.

Need: establish how a technology component works in a product or plant architecture and understand its limitations.

Working together: the partner contributes technology and integration knowledge; the joint team agrees scenarios, responsibility boundaries and verification methods.

Outcome: an integration description, results of agreed tests and conditions for further use of the solution.

Pilots and R&D

Who for: manufacturers, industrial partners and research organisations working on a new feature or an unresolved technical problem.

Need: test feasibility, for example a cryptographic change in an embedded device or a new method of gathering evidence.

Working together: we agree the hypothesis, each party’s contribution, environment access, resources and criteria. The partner brings a use case, device or research expertise.

Outcome: a demonstrator or experiment report, documented limitations and a decision on the next stage. This is a proposed scope to be agreed individually.

Ways to work together

Three light planes with rectangular openings and one blue accent.

A single task or workshop

A bounded problem, defined scope and an outcome that can be reviewed: an assessment, working session, architecture review or action plan. A good starting point when a specific decision needs to be made.

Ongoing support

Reviews of subsequent releases, risk or progress at agreed intervals. We establish availability, responsibilities and the information needed for each meeting.

A joint project

Several parties working towards an agreed technical or research outcome. Before starting, we define stages, partners’ contributions, information-sharing arrangements and acceptance criteria. Pilots and R&D have individually agreed scopes.

From a need to next actions

Each stage ends with an agreement that enables the next step. We adapt this process to the scale of the initiative.

1. Need and scope

We describe the problem, users, constraints and the decision to prepare for.

2. Working arrangements

We choose a task, ongoing support or a project, and agree contributions and responsibilities.

3. Outcome

We review the agreed material, test result or demonstrator against the adopted criteria.

4. Review of next steps

We assess findings and remaining unknowns, and agree the next stage or completion of the work.

Preparing for the first conversation

  • Describe the technical problem or team need and why it matters to the product or process.
  • Indicate the partner’s potential contribution: expertise, a use case, technology or a test environment.
  • Name the expected outcome and key constraints, such as a deadline or access to devices.

A general outline is enough at this stage. We will separately agree the exchange of confidential materials, environment access and arrangements for using the results.

B4Future’s related websites

nis2cra.com

Resources, analyses, qualification tools and initiatives on NIS2, the CRA and OT cybersecurity.

nis2cra.com

cratrace.com

cratrace — a project for managing information and evidence throughout the product lifecycle in the context of CRA requirements.

cratrace.com

Let’s discuss a joint initiative

Do you have a research need, workshop topic or cooperation proposal? Tell us which problem you want to solve.