Why TCSEC still comes up in procurement meetings
Most people I talk to about the Trusted Computer System Evaluation Criteria are looking at it through a compliance lens. They need to tick a box for a government contract or answer a security questionnaire from a client who copies a 1980s document into their RFP. The reality is less dramatic but messier. The criteria was produced in 1983 by the Department of Defense and became the de facto standard for evaluating how trustworthy a computer system actually is. It covered everything from security policy and access control to labeling, enforcement, and assurance. The result of an evaluation was a rating, and most buyers only know the ratings by their nickname. I spent a few years dealing with these evaluations directly, mostly for classified contracting in the late nineties and early two thousands. Here is how it works when you have to actually use it instead of just reading the summary in a textbook. Start with the rating you need. The common ones buyers reference are D, C1, C2, B1, B2, B3, and A1. D is the floor. It means the system has no evaluated security features. C1 gives you basic isolation between users. C2 adds controlled access and auditable actions. B1 introduces mandatory access control with labels. B2 raises the bar on labeling, covert channels, and rigorous design. B3 demands a security model, minimal trusted computing base, and tamper resistance. A1 is where formal verification meets real-world testing.
The first mistake people make is assuming a B1 requirement means you can install something and check the box. That is not how the process works. You need an accredited lab. In practice that means submitting your product to a facility like CACI or GTE here in the US, or the equivalent in other countries under the Mutual Recognition Arrangement. The submission package alone usually runs forty to sixty pages, covering architecture, design documentation, source code level detail, test plans, and operator guidance. Budget roughly eight to fourteen months for a B2 evaluation depending on how clean your code base is. A1 takes a year and a half to two years minimum, and it is not cheap. One practical thing that saves time is starting the threat model before you start the documentation. I learned this after my second submission got sent back because the attacker model did not match the security policy description. The evaluators flagged it immediately. Once I aligned the external interaction assumptions with the actual network interface design, the review cycle dropped from four months down to about six weeks for the remaining work. Another problem that shows up constantly is the trusted computing base assumption. You need to prove that the security-critical code is minimal and that everything outside it has a clearly bounded role. If your OS ships with a dozen background services that are not explicitly excluded from the TCSE, you will spend weeks just documenting why they are not part of the security enforcement path. My workaround was mapping every running process to a security function or a non-security function early on and writing a traceability matrix before the evaluator even arrived. It cut the TCSE analysis phase by roughly a third.
The assurance requirements are where most teams get stuck. The criteria ties each rating to a set of assurance classes: security policy, access control, labeling, integrity, auditing, reliability, and flexibility. Each class has specific requirements that escalate with the rating. The trick is understanding that these are not independent. A gap in integrity requirements at B2 will cascade into problems in the auditing section because the evaluator will ask how you detect tampering if your integrity controls are shallow. Plan the documentation in order of ascending complexity, not in the order the criterion lists them. Covert channel analysis is another area where people underestimate the effort. At B2 you need to measure and bound covert channels. At B3 you need to identify and eliminate or control them below a specific bandwidth threshold. I worked on a system where the storage controller introduced a timing channel through cache behavior. We resolved it by adding a flushing sequence and a timing barrier in the device driver, then measured the residual bandwidth at roughly 0.8 kilobits per execution, which satisfied the policy requirement for that classification level. Documenting the measurement methodology took longer than the fix itself.
Get the Full Details
What the criteria does not cover anymore
The Orange Book was replaced in 1999 by the Common Criteria, but TCSEC still appears in legacy contracts and in requirements language that has not been updated. Buyers sometimes reference it because they inherited the language from an older contract template. If you are evaluating a system today, know that TCSEC does not address software composition, open source components, supply chain risk, cloud virtualization boundaries, or modern threat models involving network-based exploitation at the application layer. It was built for monolithic systems on dedicated hardware. I have seen procurement teams reject a modern containerized workload because it could not meet TCSEC B2 requirements around physical labeling. That is not a reflection of the system's security. It is a reflection of the criteria being out of scope for the architecture in question. The correct move is to negotiate a Common Criteria equivalent or a risk-based assessment that addresses the actual deployment model. The criteria also does not evaluate performance. An A1-rated system can be painfully slow if the security enforcement overhead is high. Conversely, a D-rated commercial system might handle your workload correctly in practice while failing the evaluation because its documentation is incomplete. Do not conflate the rating with operational effectiveness. Evaluate the rating against the requirements, not against what you actually need the system to do.
If you need a current reference document, the original criteria is available as DoD 5200.28-STD from the Defense Technical Information Center. It is public domain. The full text is archived and downloadable without restriction. Most people end up using a Common Criteria reference instead because it maps to the same concepts with updated structure, but if your contract explicitly requires TCSEC compliance, you need the original. The main pitfall I see is treating the rating as a binary pass or fail. It is not. The evaluation produces a report with findings, observations, and recommendations. A system can be rated B2 with noted weaknesses that require a remediation plan before deployment. The rating is valid, but the gaps are real and need to be addressed separately. Don't ignore the observations section just because the final rating looks acceptable. Another thing people get wrong is the relationship between the rating and the environment. A B3 rating applies to a specific configuration and deployment context. Moving that system to a different network zone, adding a third-party module, or changing the encryption implementation invalidates the evaluation unless the change is documented and reviewed. I have seen teams assume the rating traveled with the software license. It does not. The rating belongs to the evaluated product configuration, not the vendor brand.
Practical next steps if you are in an audit right now
Identify the exact rating referenced in the contract or questionnaire. Locate the relevant clause in DoD 5200.28-STD. Determine whether your product has an existing evaluation report from an accredited lab. If it does, verify that the current deployment matches the evaluated configuration. If it does not, you will need a change assessment before submitting anything to the auditor. If you have no prior evaluation, decide whether pursuing a TCSEC rating makes sense for your product. For a web service running in a shared cloud environment, it likely does not. For a standalone embedded controller handling classified data, it probably does. The decision should be based on the data sensitivity, the threat model, and the contractual obligation, not on the assumption that a higher rating automatically means better security. The documentation effort is the real cost driver. Keep your security model explicit, your TCSE boundary clearly defined, your covert channel measurements documented, and your change control process tight. Those four items cover the majority of evaluation failures I have seen in practice. Everything else is refinement work that shows up in the final report rather than blocking the rating itself.
