Home Methodology


Our job is to stay abreast of the latest attacks globally to help you prevent them on your devices. We focus on security of (connected or unconnected) embedded devices, which have to operate in hostile/vulnerable environments (i.e. devices where physical access is also an option). Our goal is to enable better products that not only pass the required certification, but remain secure in the field. Our strength is to efficiently find weaknesses and help our customers resolve them.

Focusing your secure development efficiently on where vulnerabilities are

By having razor-sharp focus on finding vulnerabilities associated with a broad range of attack methods, we allow you to focus your obfuscation and hardening measures exactly where you might be vulnerable, as opposed to designing or programming generic measures across the board. More often than not, this saves you development time and for sure drives more certainty if you are preparing for a level of security certification.

Moreover, even while implementing secure development best practice, industry data show that human error and oversights will still result in remaining vulnerabilities. An attacker’s view then helps differentiate between highly critical issues which would result in a significant vulnerability and low priority ones, which may still be an oversight or problem, but would unlikely result in a relevant attack.

Importance of combined hard- and software expertise

Our combined hard- and software expertise allows us to both assess exploitable problems in the software and any vulnerabilities on the hardware-side, which could have an attacker achieve white box access to your system. The latter would risk exposing your code, which fundamentally undermines security, since white box is far simpler for an attacker to exploit than black box, where the device code is unreachable. By us helping you understand the attacker side, it allows you to prevent access exactly where and how they might attack.

While nothing is ever fool-proof, we have seen time and time again that the attackers’ mindset method truly allows our customers to drive security to a level where it becomes unattractive for attackers to break a system. An important reason why we count industries like financials and payment, as well as vendors who successfully differentiate their products on security measures, amongst our loyal customers.

Seven steps of security evaluation process

Understand the Requirements

The security requirements of a product drive how resistant a product should be against attacks. Before we evaluate the security of a product, we aim to have a good understanding of its security requirements. The security requirements can be either specified by a certification body, or developed in collaboration between Riscure and the customer.

Understand the Design

In this activity, we analyse the available design documentation, manuals and the information available on the Internet on the product and its components. The more detailed the design documentation, the more effective we are in finding potential weaknesses. In a “black box” evaluation we work with very little information on the product so that we will have to use reverse engineering techniques, whereas in a “white box” evaluation, we are provided with detailed design information and source code of the product.


Implement and Execute Tests

The implementation of tests can be straightforward when we use a tool that has the tests already implemented, such as our Java Card security test tool. In other cases, it requires significant manual work, for instance when we test a proprietary application protocol. After implementation, we execute the tests and analyse the behaviour of the product. Unexpected behaviour is followed by manual testing to gain a good understanding of the issue.


Identify the Assets

What are the valuable assets for this product in relation to the security requirements? In this activity, we determine what the assets are (e.g. authentication key, PIN, transaction counter, firmware code), and where they are located in the product. Often, we define so-called primary and secondary assets. A primary asset is critical to the security, whereas a secondary asset can often be used as a stepping stone towards a primary asset.


Threat Analysis

Now that we understand the product and its security requirements, we identify the threats that are relevant to this product. Different attack paths towards the assets are analysed and rated relative to the difficulty and cost for an attacker.


Impact Analysis

This final step forms the basis of our reporting and is critical to our customers. Having identified several technical anomalies, we analyse the impact of these issues on the product. It is our experience that what may seem as a minor technical issue at first can have a large impact on a product, as well as the other way around. For each issue, we also work out a recommendation how to address the security weakness and improve the security profile of the product. We rate security of a product or a component in accordance with certification standards or our own evaluation programs. The rating may then support a decision to award a certificate.

Select Tests

Selecting the appropriate tests is critical in each security evaluation project because one can never execute all possible attack scenarios. The experience of our people ensures that the best possible selection is made based on the Threat Analysis. Further, the security requirements for the product and the available budget for the project influence the width and depth of the tests.