In RSA, ECDSA, ElGamal and quite a few other schemes, using a secret (random) value equal to 1 might not provide any form of security, while still being mathematically sound.
For RSA, ECDSA or ElGamal, the secret random value might typically be the secret exponent, for example. Or for ElGamal and ECDSA, it might be the ephemeral secret we need to encrypt or sign (the infamous $k$ for ECDSA).
Arguably this holds for secret values smaller than 80 bits, as it might otherwise well be attacked using a brute force search attack.
The same might hold for secret values whose secrecy is crucial to the security of the scheme at hand, such as the ephemeral $k$ used in ECDSA signatures, although specific scheme might have specific guidelines depending on their specific requirements.
In order to avoid such obvious problems, are there any kind of (official or standard) recommendations regarding the rejection of "bad" random values based on certain criteria?
Or more broadly, in the same way that we have recommendations for the group size or the way to generate large primes (see keylength.com), do we have some kind of guidelines for the generation of the "secret random values" we have in cryptographic software. (For instance, I do not see any kind of "sanity checks" being performed on the $k$ values generated for ECDSA as per FIPS 186-4, even though it is crucial for $k$ values to be unbiased. The only "standard" that I'm aware of that specify how the secret random value should be generated, and it only covers the specific case of the generation $k$, is the RFC6979 and is using derandomization, like the standard for EdDSA (RFC8032). But this is not always possible for secret values.)
Is this documented in some other NIST document, or in some RFC?
PS: notice this question is assuming randomness is difficult for implementation, and that as such it might be best to have "fail-safes" in place in a way to have defense in depth.