The most expensive findings in a security audit do not originate in the code. They originate in the first weeks of a project — where scope, assumptions and protection goals are defined, usually verbally and without a result document.
Two years later, someone asks why a particular interface was treated as trusted. The answer exists, but only in the memory of three people, one of whom has left the company.
Concept phase: four results, not four slides
What is created in the concept phase later carries the entire line of argument. Four artifacts are indispensable — and each of them is a result, not a paragraph in a presentation.
Scope. What is part of the object under consideration, and what is explicitly not? The boundary runs along interfaces, not organizational units. A gateway that "doesn't really belong to the product" but sits in the same housing must be an explained decision — not an omission.
Operating environment. Under what conditions is the device operated? Is it in a locked control cabinet or on a pole? Is it behind a firewall or connected directly to the customer's network? 62443-4-2 contains requirements that may explicitly rely on compensating countermeasures in the environment — but only if the environment is described.
Assumptions and constraints. The item most frequently missing. "The operator assigns individual credentials", "the maintenance interface is physically protected", "the device will never be directly reachable from the internet" — these are assumptions on which entire chains of measures rest. Unwritten, they are not assumptions but hopes. They also belong in the security guidelines, because the operator needs to know what they are responsible for.
Protection goals and components. What exactly is to be protected — availability of the control function, integrity of the parameterization, confidentiality of measurement data? Protection goals drive prioritization. Without them, every later risk assessment is a matter of taste.
Two further results are regularly created too late in practice:
The rating scheme itself. Which scales apply to likelihood and impact, how both are combined into a risk value, and at which level action is taken — this belongs in the concept phase, not in the first assessment session. Anyone who only defines the scheme once the first threats are on the table will unconsciously calibrate it toward the desired outcome.
The rule for what happens when a risk is identified. Who decides on treatment, who owns it, and what triggers a reassessment? It should also be clarified early who is responsible for security activities across the entire lifecycle — in many organizations a named role with its own cybersecurity plan.
Design phase: from threat to requirement
In the design phase the analysis is added, and with it the connection that ultimately matters: from threat to requirement to mechanism.
- Threat model per interface. Not per product. The interface is the unit where attacks start and to which measures can be assigned.
- Derived security requirements. Every requirement points back to an identified threat and forward to a planned mechanism. A requirement without a back-reference is a checklist; a threat without a requirement is an open item.
- Architecture decisions with rationale. Why secure boot instead of signed application updates? Why TLS at the transport layer instead of payload signatures? The answer is cheap at the moment of decision and expensive a year later.
- Design review with minutes. The minutes are the evidence. From an audit perspective, a review without a record did not take place.
- Verification of the security concept. The concept is not only specified but checked against the requirements — with a result report that belongs to the released version.
The handover is the critical point
In practice, more gets lost between concept and design, and between design and implementation, than within the phases. Three rules keep the chain intact:
Every result has a version, not just a name. "ThreatAnalysis_final_v3_new" is not a version. Versioning with a date and a responsible person is the minimum.
The released version remains unchanged. Anything edited after release is a new version — not the same file with more content. Without this separation, it is impossible to show later what the release referred to.
Changes to the baseline trigger a review. If the operating environment changes or an assumption no longer holds, the analysis is affected — not at some point, but as a triggered activity. This is exactly what the TRA maturity check measures under maintenance and currency.
This explicitly does not mean the concept phase is a one-time closure. It is completed before product development, but individual steps are repeated during design, production and operation — when an interface is added, when a test disproves an assumption, when a new attack pattern becomes known. Iteration is the norm; what counts is that each round leaves its own version behind.
The litmus test
A simple test for your own early phase: take any security requirement of your current product and try to resolve it in both directions — back to the threat that justifies it, and forward to the activity that fulfills it. If this works for three randomly chosen requirements, the concept work is solid. If it works for none, the problem is not the documentation but the order in which the work was done.
Technical assessment, not legal advice and not a certification statement. Please verify citations of standards against the original documents.
Sources
- IEC 62443-4-1:2018 Ed. 1.0 — Secure product development lifecycle requirements
- IEC 62443-4-2:2019 Ed. 1.0 — Technical security requirements for IACS components
This article was originally published in German on the Alsensio Cybersecurity Hub.
