A loose thought - haven't really thought it through, and don't know exactly how SSFs are used today either:

I'm wondering if we need one or two "Bind DN SSF"s which describe how reliable a Bind DN is - how secure the server-side authentication system is, as well as the Bind method and connection security at the time of the Bind. Then one can set access controls, 'security' directive, and a new 'rootdn-ssf' directive which requires a certain quality of the rootdn/pw. Possibly rootdn-ssf should be nonzero by default, or nonzero by default for cn=config.

The ultimate example of an insecure Bind DN is probably database config rootdn cn=foo,cn=nil # config's rootdn is very powerful database null suffix cn=nil bind on # accept any password for any DN which hopefully doesn't happen outside tests. (That's why this occurred to me, I'd like to support cd tests/ && ./run -b null. Not when one could accidentally write a test like this, though.)

There are other reasons the quality of the authentication or password store might differ - different authentication methods, a sloppily-written back-perl instance, whatever. So as a source of the Bind DN SSF one would configure SSFs to subsystems used for authentication - databases, SASL, etc.