It is highly likely that
F-Secure is the reason the registry change isn't sticking.
Because you are using F-Secure (which, as you noted, utilizes the Avira SDK for behavior detection), it takes deep control over the system's security provider registration. When a third-party antivirus is active, it often "hooks" into Windows Security settings to prevent malware (or the user) from weakening the system's defenses.
\Here is why the registry method failed and how F-Secure fits into the picture:
1. F-Secure's "Self-Protection"
F-Secure has a "Tamper Protection" or "Self-Protection" feature. Because Smart App Control (SAC) is a core component of the Windows integrity layer, F-Secure may be monitoring the CI\Policy registry keys. If it sees a change to VerifiedAndReputablePolicyState, it may automatically revert it to "Off" to maintain the state it recorded during installation.
2. The "Protected" Registry Key
There is actually a second, "hidden" registry value that Microsoft uses to prevent exactly what you tried. If you only change the main policy state, Windows detects a mismatch and resets it. To truly force it, you often have to modify the "Minimum Value Seen" key, which is usually protected by
SYSTEM permissions.
The path for the secondary check is: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI\Protected Value: <span>VerifiedAndReputablePolicyStateMinValueSeen</span>
3. F-Secure & SAC Redundancy
Since F-Secure is using the
Avira SDK behavior detection, it is already performing a similar role to SAC. Both are looking for suspicious patterns in unsigned or low-reputation binaries.
- The Conflict: Windows often forces SAC to "Off" if it detects a third-party security suite that doesn't explicitly support co-existence with SAC's enforcement mode.
- The Result: Even if you force the registry to "1" (On), F-Secure might signal to Windows that it is the primary provider, causing Windows to disable SAC again on the next boot to avoid driver conflicts.