An Evaluated Products List (EPL) is an approved register of products that have been assessed against defined security or technical criteria. Defenders use it to restrict procurement to tested components and check whether a device, platform or module has the required evaluation before deployment. Attackers may exploit unapproved substitutions or unsupported versions.
What an EPL does in procurement and deployment
An Evaluated Products List, or EPL, turns security evaluation into a procurement gate. Instead of treating every vendor claim as equally acceptable, defenders use the list to narrow approved purchases to products that have already been assessed against defined criteria.
That matters because the EPL is not just documentation, it is an operational control. It helps organisations decide what can enter the environment, whether a product belongs in a regulated or high-assurance deployment, and whether a proposed replacement really matches the required assurance level.
Why an EPL exists
An EPL exists to reduce uncertainty at the point of acquisition. When a device, platform, or module has been evaluated, the buyer does not have to start from zero on every procurement decision; the evaluation history becomes part of the trust decision.
This is especially useful where product provenance, supported configuration, and baseline security properties matter more than features alone. A product can be technically functional and still be unsuitable if it has not been evaluated, is outside the approved register, or does not meet the required criteria for the target environment.
What the list tells you and what it does not
An EPL is a curated approval record, not a guarantee of perfect security. It usually tells you that a product met a defined evaluation standard at a point in time, but it does not automatically prove that every deployed instance is configured safely or that later versions remain equivalent.
It also does not replace asset inventory, vendor advisories, or version tracking. A product can be on an approved list and still become risky if teams deploy an unsupported release, accept an unapproved substitute, or fail to confirm that the deployed build matches the evaluated one.
How EPLs support security assurance
EPLs improve assurance by creating a clear boundary between tested and untested components. They support procurement review, architecture review, and deployment decisions by giving defenders a defensible basis for saying that only evaluated products may be used in sensitive environments.
They also help reduce supply chain drift. If teams can only procure from the approved register, it becomes harder for unauthorised components to slip into production through convenience, vendor pressure, or shadow purchasing. That makes the EPL a practical control for security governance, not just a reference list.
Risk and Threat Considerations
When organisations rely on products that are not on the approved list, they increase the chance of introducing unassessed security behaviour, unsupported code, or weaker configurations into a trusted environment. The most common failure is substitution, where a similar-looking product bypasses the evaluation gate and enters deployment anyway.
Failure mechanism: An attacker or careless procurement path can exploit gaps between approved-product policy and real purchasing, then leverage the weaker controls, missing hardening assumptions, or unknown vulnerabilities of the unapproved component.
Impact: The result can be weaker system integrity, reduced assurance over the deployment stack, and a larger attack surface if the substituted product is easier to misconfigure, harder to monitor, or outside the expected support and patching path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | EPLs depend on knowing which products are approved and actually deployed. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Evaluated products still need trusted configuration after approval. | |
| CIS-18 — Penetration Testing | Validated products should still be tested in the target environment for weak spots. | |
| Recommendation — Maintain an approved software register and block unapproved product installs. Enforce hardened configurations for approved products before deployment. Test deployed products to confirm approved components behave securely in practice. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | An EPL is only useful when matched to an accurate component inventory. |
| SA-22 — Unsupported System Components | EPLs help prevent the use of unsupported or unassessed components. | |
| Recommendation — Track deployed components against the approved product register. Prevent deployment of unsupported components that fall outside approved evaluation. | ||
Practitioner Guidance
Why practitioners should care: Treat the EPL as a control that must be operationalised, not merely archived. Its value depends on whether procurement, architecture, and deployment teams actually check the register before approval and installation.
What to watch for: Watch for mismatches between the approved list and what is actually running, especially where teams accept “equivalent” replacements, deploy unsupported versions, or inherit products through mergers, contractors, or legacy estates. Those are the moments when the approval boundary breaks down.
Practitioner takeaway: An EPL is most effective when it is paired with inventory discipline and deployment verification, so that approved status is checked against the real asset, not just the purchase request.