What’s the issue?
Common Criteria Compliance is a SQL Server feature that, when enabled, configures the engine to meet the requirements of the international Common Criteria security certification at the Evaluation Assurance Level (EAL) defined for SQL Server. Enabling it changes specific runtime behaviors to comply with the certification requirements, including residual information protection, login statistics tracking, and column level GRANT permission handling.
The feature is controlled by the common criteria compliance enabled server configuration option, which requires show advanced options to be on. Enabling the option requires a SQL Server service restart for the changes to take full effect.
This finding identifies instances where Common Criteria Compliance is currently enabled. The condition is most often the result of a configuration applied to meet a specific government, defense, or regulated industry requirement.
Why is this a problem?
Common Criteria Compliance changes several behaviors that can affect performance and produce unexpected query results compared to a standard SQL Server installation. Residual information protection requires that memory be overwritten before being reallocated, which adds CPU overhead to memory management operations and can affect throughput on busy instances.
The column level GRANT behavior also changes in a way that interacts with table level DENY permissions differently than the SQL Server default. This can produce permission outcomes that surprise developers and administrators who are not aware that the option is enabled, particularly when troubleshooting access issues that appear inconsistent with the documented permission model.
The login statistics tracking adds a small amount of overhead to every login but provides useful audit information about successful and failed login attempts and the timing of those events. This is generally a positive side effect of the option, but the increased volume of statistics data should be accounted for in monitoring and audit storage planning.
The feature is also tied to specific SQL Server versions and editions that have been certified. Upgrading to a newer version may invalidate the certification status until the new version is itself certified, which can affect compliance posture even if the configuration option remains enabled. Organizations relying on the certification for compliance should track the certification status of their SQL Server version against current requirements.
What should you do about this?
Confirm whether Common Criteria Compliance is required by current compliance obligations. Engage with your compliance and security teams to determine whether the certification is genuinely needed, since it is sometimes enabled based on older requirements that have since been superseded by other standards such as FedRAMP, ISO 27001, or specific agency frameworks.
If the feature is required, document the compliance requirement, the SQL Server version’s certification status, and the operational implications of the changed behaviors so the team understands why certain queries or permission patterns may behave differently than in standard configurations. Review the column level GRANT and DENY behavior with developers so application permission models are designed with the changed semantics in mind.
If the feature is not required, disable it with EXEC sp_configure ‘common criteria compliance enabled’, 0; RECONFIGURE;. The change requires a SQL Server service restart to take full effect. After disabling, verify that any application behavior that depended on the modified permission semantics is not affected, since reverting to default behavior can change the outcome of column level permission checks for some configurations.
Read more…
Enable common criteria compliance configuration (Microsoft)
Performance degradation in SQL Server with common criteria compliance enabled (Microsoft)