DisabledByDefault and Enabled are not redundant

When DisabledByDefault flag is set to 1, SSL / TLS version X is not used by default. If an SSPI app requests to use this version of SSL / TLS, it will be negotiated. In a nutshell, SSL is not disabled when you use DisabledByDefault flag.

When Enabled flag is set to 0, SSL / TLS version X is disabled and cannot be nagotiated by any SSPI app (even if DisabledByDefault flag is set to 0).

For more information, Microsoft documentation describes what SSL version is maintained or not, and how to disable it.

In the SCHANNEL_CRED structure that is passed to AcquireCredentialsHandle as part of setting up a secure channel, you can optionally manually select the protocols to support, in the grbitEnabledProtocols bitmask field.

Thus, Enabled governs what protocols you can enable here while DisabledByDefault specifies whether the protocol is enabled if you omit this field (i.e. leave it as 0).

• The Managing SSL/TLS Protocols and Cipher Suites for AD FS | Microsoft Docs article recommends to set DisabledByDefault to 1 for disabled protocols, too, in addition to setting Enabled to 0. So it looks like DisabledByDefault is used unconditionally to autogenerate the value for this field if it's omitted.

The field's note says that it's not recommended for use in new code. So these two registry values are almost redundant:

For new development, applications should set grbitEnabledProtocols to zero and use the protocol versions enabled on the system by default.

This member is used only by the Microsoft Unified Security Protocol Provider security package.

The global system registry settings take precedence over this value. For example, if SSL3 is disabled in the registry, it cannot be enabled using this member.

It's unclear what happens if you try to use a non-enabled protocol. Judging by the last paragraph and a lack of any relevant AcquireCredentialsHandle error code for this case, my guess is it's probably ignored.