BSI certification under PP-0115: how the procedure works

For indigo, BSI requires a certified MDM server component. The benchmark is the Protection Profiles BSI-CC-PP-0115 and BSI-CC-PP-0116, evaluated under Common Criteria at EAL4 augmented by ALC_FLR.3. EAL4 is the highest level recognised internationally without additional national arrangements. The augmentation requires a formalised procedure for handling reported security flaws.

Three parties, three roles

The sponsor is the applicant, usually the vendor. It funds the procedure, delivers all evidence and answers queries. Most of the effort sits here.

The evaluation lab, called the ITSEF in the procedure, is recognised by BSI. It performs the technical evaluation, documents every activity and writes the Evaluation Technical Report. BSI oversees as the certification body, raises its own questions and issues the certificate.

What is actually assessed

The assessment spans six areas, called assurance classes in the procedure. They explain why a certification is considerably more than a security test.

• Security target. Does the document describe the real product, and are the Protection Profile requirements correctly adopted?
• Development. Complete functional specification, design down to subsystem level, security architecture, and access to security-relevant source code.
• Guidance. Can an administrator install and operate the product securely from the documentation alone?
• Life cycle. Configuration management, delivery, development security including an on-site inspection, flaw remediation process.
• Tests. Coverage, depth, the vendor's own tests and independent lab testing against the running system.
• Vulnerability assessment. Systematic search for known patterns plus penetration testing against the running system.

The bulk of the work sits in the development documentation. It describes a product at a depth and in a form that ordinary product work never demands.

Why it takes years

Three things drive the timeline, and none of them is the assessment itself.

The documentation. It has to be created first, in a form the lab accepts. Learning the conventions by having them rejected costs months.

The remediation rounds. Every observation goes to the sponsor as formal feedback; the sponsor documents, changes code or adds tests. Several rounds are normal, and weeks to months pass between an observation and an accepted response.

Lab capacity. Few recognised labs work in this field. Queue time for a slot is a real item in the schedule and is routinely overlooked from the outside.

In total, a first evaluation for a product with no Common Criteria history runs to years rather than months. The certificate then holds for ten years; new product versions go through a maintenance procedure.

The target of evaluation drives the effort

What gets certified is not a product but a precisely bounded target of evaluation: a specific version, specific components, a specific deployment mode. Anything outside that boundary is not assessed and costs no evaluation time.

One practical consequence follows: a moving target is not evaluable. The certified state has to be a controlled, versioned build that changes only through a documented procedure. An approval statement is therefore only meaningful together with what it refers to.

What the site visit requires

A common assumption holds that the physical security requirement rules out software developed by a distributed team. The benchmark is a different one. What is required are documented and genuinely practised controls: access control where development happens, access control to repositories, build systems and signing infrastructure, protected signing keys and a remote work policy. No secured facility, no dedicated compound.

The visit itself typically takes a day. The time the procedure consumes arises at the points described above.

A national entity is not a precondition

The assumption that BSI certification requires a German subsidiary does not survive contact with the public approval list. The lab and BSI visit the development site wherever it is.

What the status can be pinned to

• Which version and which deployment mode does the statement refer to?
• Who holds the certificate, and is that the same entity as the contracting party?
• Is a lab engaged, or has the procedure merely been announced?
• Does the flaw remediation process already exist, with named ownership and response times?
• Which feature gaps against the Protection Profile are known, and when will they close?

Certification status remains a yes or no question on a given date. An ongoing procedure is not a basis for an award decision, however promising it looks. That holds all the more since the transitional route that allowed deployment during an ongoing evaluation was closed.

Which products are certified, run under a transition period or dropped out of it without a certificate is documented on the indigo page.