SESIP is an evaluation methodology for assessing the security of connected products and IoT components in a structured, reusable way. A SESIP certificate lets a developer prove that specific security functions have been implemented and independently evaluated by a licensed laboratory. For most developers, the hard part isn’t the final evaluation — it’s everything before it: defining the scope, the security objectives, the target level, and the documentation needed to engage a laboratory and certification body productively. Most start with pre-testing to surface technical or documentation gaps early, but pre-testing only pays off if the scope, target assurance level, product assumptions, and security claims are already clear. Internet of Trust structures that preparation so pre-testing is relevant, efficient, and aligned with what labs and certification bodies actually expect.
The work addressed two kinds of developer. The first already had a defined SESIP Profile or a clear compliance claim, and needed to confirm that their implementation, documentation, and security mechanisms actually matched the profile they intended to claim. The second was starting from scratch — no defined claim, no evaluation scope — and needed help deciding what to evaluate, which SESIP level fit, and how to turn their product architecture into a first draft Security Target. In both cases the goal was the same: reach pre-testing on a realistic footing — defined scope, appropriate level, identified security objectives, a draft Security Target, alignment across developer/lab/certification body, and a credible estimate of certification effort, cost, and timeline.
The central challenge was translation. Product teams describe security in engineering terms — secure boot, debug interfaces, code loading, key storage, physical resistance. Evaluation schemes require the same reality expressed as scope, security objectives, assumptions, threats, requirements, claims, and evidence. Without that translation, pre-testing misfires: the lab tests an unclear scope, the developer gets ambiguous results, and rework surfaces late. SESIP Profiles add a second trap — they provide a reusable structure, but a team can believe their product matches a profile when specific assumptions, lifecycle constraints, or implementation details don’t. The consequences are predictable and expensive: misaligned scope, missing evidence, wrong target level, late-discovered design issues, inaccurate lab quotes, extra evaluation iterations. Preparation is what removes that uncertainty before formal evaluation begins.
01
Initial scoping. Defined the evaluation perimeter: product boundaries, relevant components, operating environment, intended use cases, and the security functions to be assessed. For developers with no predefined claim, this established a first realistic scope.
02
Minimum and conditional SESIP requirements. Checked the product against applicable SESIP minimum and conditional requirements — product identification, secure code loading, secure lifecycle management, debug interface management, physical resistance where relevant, asset protection, environmental assumptions — separating what applied from what needed clarification or further implementation work.
03
Security objectives and target level. Identified the product’s core security objectives and selected the SESIP level that was ambitious enough to support its market positioning but realistic against its actual maturity — avoiding needless cost and complexity.
04
Profile-based compliance review. For developers already claiming a SESIP Profile, checked the claim against the real implementation and, where gaps appeared, found practical fixes: refining scope, adjusting the claim, clarifying assumptions, preparing evidence, or flagging product changes needed before pre-testing.
05
Training and alignment. Ran training and structured sessions to make SESIP concepts concrete for engineering, product, and security teams — aligning terminology and cutting misunderstandings between developers, evaluators, and certification stakeholders.
06
Draft Security Target. Produced the draft Security Target as the reference document for lab and certification-body discussions: scope, intended claims, selected level, assumptions, and expected evidence. Bringing it early meant labs could quote more accurately and the certification application could be structured from a shared basis.
Successful SESIP certification is rarely decided by the final lab test — it’s decided by the maturity of the preparation before testing starts. The key move is translating product reality into an evaluation-ready structure: scope, applicable requirements, the right level, a draft Security Target, and stakeholder alignment, all settled before formal evaluation. The sharpest lesson for connected-product developers is that pre-testing must be prepared with the same rigor as certification itself. A poorly scoped pre-test creates false confidence; a well-prepared one accelerates time-to-certificate and lowers evaluation risk. Invest early in structured preparation and SESIP evaluation becomes markedly more predictable.
We’ll send you access by email.
