We can help you with regulatory compliance

There is a lot of uncertainty around new solutions for Strong Customer Authentication and with new requirements for security and privacy.


We can help you prove that you conform to any kind of regulatory framework, including giving a formal proof that your solution is secure on a fundamental design level.


For frameworks such as the “Regulatory Technical Standards on strong customer authentication and secure communication under PSD2” we already have templates that can help you speed up the process of documenting compliance, but our process can be adapted to any kind of regulation.


We can help you with compliance and evaluation processes together with one of our partners or as a consultancy-supported project where we can help write and document your solution, together with your experts.


We normally follow an iterative process, where we go through the following steps as many times as required:

1. Scope analysis

Here we filter out the systems and protocols that are within the scope of the analysis. We identify key stakeholders, such as developers and security architects, and identify the relevant regulatory frameworks.



  • Review documentation
  • Perform interviews
  • Identify critical sections
  • Review requirements
  • Map documentation and resources to key system


  • System overview
  • Critical sections
  • Scope recommendation
  • Estimate of total work that is required


2. Description of the model

We use a tool-assisted method for generating a model of the protocols and systems that are to be analysed.


  • Detailed documentation review
  • System model created
  • Identification of fundamental patterns (e.g. SSL)

Review with key personnel:

1. Model updates
2. Documentation error
3. Design errors


  • A precise PROSA model providing:
  • System overview
  • Detailed system behavior
  • Complete, uniform documentation
  • Design errors are identified


3. Security requirements

Here we can generate protection graphs of the system, allowing you to view how critical assets are protected during transmission and on systems. We can identify anomalies such as the circular use of keys. At this stage, we can help identify the sensitivity, integrity, and confidentiality requirements for each asset identified.



  • Identify and validate information assets (critical information elements)
  • Model requirements


  • A model with complete requirements including:
    • Confidentiality goals
    • Integrity goals
  • Mapping of requirements to the relevant requirements


4. Threats

Here we formulate the main attacker goals and analyse how the system protects against attackers. An example here is that sensitive information should be protected at all points. The threats are mapped to the requirements so that you can show that possible threats have been examined.


  • Perform eavesdropper simulations
  • Attack landscaping
  • Impersonation patterns


  • Documentation of possible threats (potential attacks with the description of attack behavior)

5. Risk analysis

The final phase is to analyse the results of the threats and to identify any residual risks. Typically in an evaluation process, it is the residual risks that are of interest, as this shows what you can’t control for.


  • Threats overview
  • Decision making priorities


  • Risk documentation for each potential threat