A product certificate is not permission to operate

A Common Criteria certificate is a statement about a product. More precisely: about a bounded target of evaluation, in a given version, with given components, assessed under given assumptions. It is not a statement about whether deployment in a given organisation, in its network architecture and with its processes is permitted.

That second question is answered separately, by a different body, in a different document. Offers and tender texts routinely present the two as one. The difference tends to surface only when the last step comes due.

Two kinds of document, two questions

The identifiers show it. Product certificates take the form BSI-DSZ-CC and answer: does this product in this version meet the security requirements that were assessed? Deployment permissions take the form BSI-VSA and answer: may classified work be done with this product, up to which classification level, and under what conditions?

The two belong together, and they do not replace one another. A deployment permission is also time limited and tied to three conditions: it holds only for the design states listed in its annex, meaning the device and software versions named there, only for products installed and operated according to the attached operating conditions, and only where the risk analysis is observed.

The conditions are written out

On the certificate side there is the security target, the document a product is assessed against. It contains a section of assumptions about the operational environment: how the product is operated, who holds administrative access, how the network is built, which protective measures outside the target of evaluation are treated as given. Those assumptions are part of the statement: the assessed assurance holds exactly under them.

On the deployment side it gets more concrete. A permission comes with operating conditions, known internationally as security operating procedures. They set out the minimum requirements for installation, integration and configuration, and for control, protection and operation, along with security management, accessories and the product documentation.

The answer to what the operational environment has to look like therefore sits here rather than in the certificate. And in a level of detail that runs from physical and personnel security through maintenance and emergency procedures to reporting duties for incidents and for delayed updates. The management plane has an annex of its own covering requirements for mobile device management, and the build-out another on system integration and configuration.

One detail shows the scope: the accompanying risk analysis is itself classified and is not attached. It has to be requested from the manufacturer. Planning an operational environment therefore requires access to a set of documents rather than to one.

Where this becomes visible in the Apple context

For classified use of iPhone and iPad, BSI requires a certified MDM server component. What is certified is the server. What is not certified, and is nevertheless a prerequisite, is everything around it: the enrollment pipeline, the identity model, the certificate infrastructure, the role and approval logic, the operational documentation.

The Protection Profile calls this area the operational environment and places it explicitly outside the target of evaluation. No certified product configures it for you. It has to be designed, implemented and described, and it is the part where projects get stuck in approval.

Notably, the operating conditions anticipate this role explicitly. They address everyone responsible for installation, control, operation and use, and alongside them independent parties responsible for planning and commissioning who hand the overall system to the operator. That role is not tolerated by the procedure, it is designed into it.

What an offer can be checked against

• Which version and which deployment mode does the quoted certificate refer to?
• Which assumptions does the security target state, which obligations do the operating conditions impose, and who meets them in the procuring organisation?
• Who is accountable for the approval of the specific deployment, and is that effort included in the offer?

The third question is the one most often left unanswered. It separates a product offer from a programme that carries through to going live.

Where the cost usually appears

The cost usually appears where the certificate is budgeted and going live is carried as automatic. The certificate is the point at which a product becomes procurable. Between there and classified operation sit the operational environment, its documentation, and the approval decision for the specific case.

That distance does not disappear by being left out of the plan. It surfaces later, at the point with the fewest remaining options.

Where the boundary between certified product and operational environment runs is set out on the indigo page. How the procedure behind a product certificate works is covered in BSI certification under PP-0115.