Developers prevent use of insufficiently random values by generating secrets, tokens and identifiers with a cryptographically strong random source. They should not derive security values from timestamps, counters or other predictable inputs, and they should test that each value has enough unpredictability for its purpose.
What “insufficiently random” means in practice
Security values need unpredictability, not just uniqueness. A value can look different each time and still be guessable if it comes from timestamps, counters, user IDs, process IDs, or other inputs an attacker can observe or infer. The practical test is whether the value would remain hard to predict even when the attacker understands the application design.
That distinction matters because randomness is not a cosmetic property. Tokens, API keys, password reset links, session identifiers, CSRF tokens, and similar material depend on unpredictability to resist guessing and replay. When developers use a weak source, the value may still be “random enough” for logging or correlation, but not for security decisions.
Developers should also separate cryptography basics from ad hoc randomness. A cryptographically strong random source is designed to resist prediction under adversarial observation, which is the property security-sensitive values require.
How developers generate values that resist prediction
The safe pattern is to use the platform’s cryptographically secure random number generator or approved library wrapper, then encode the output into the format the application needs. That may mean raw bytes for internal use, URL-safe text for tokens, or a UUID variant only when the implementation is explicitly backed by strong randomness. The important part is the entropy source, not the textual shape of the value.
Developers should not build secrets by transforming predictable inputs. Hashing a timestamp, appending a counter, or combining several weak values does not create real unpredictability. Those methods can be acceptable for logging identifiers or queue keys, but they are not a substitute for a true CSPRNG when the value protects access.
When randomness feeds a cryptographic mechanism, follow established implementation guidance rather than inventing a local scheme. The OWASP Cheat Sheet Series is a useful reference for secure implementation patterns across authentication, secrets, and session handling, especially where developers need to choose the right source and format for generated values.
How to verify the randomness is good enough for its purpose
Verification is about fitness for purpose, not proving mathematical perfect randomness. For a session token or reset code, the question is whether the space of possible values is large enough and unpredictable enough that brute force and guessing are impractical within the token lifetime. For lower-risk identifiers, uniqueness may be enough, but for secrets and authenticators, unpredictability is the deciding requirement.
Teams should test the implementation path, not just the output sample. Confirm that the production code uses the intended cryptographic generator everywhere, including background jobs, test fixtures, fallback paths, and language runtime helpers. A secure function in one module does not help if another path quietly reverts to a predictable generator.
For reference implementations and review checklists, the OWASP Cheat Sheet Series is the most useful external starting point because it aligns implementation details with the security property the application actually needs.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V11 — Cryptography | Covers secure generation and handling of security values that depend on entropy. |
| Recommendation — Use a cryptographically strong generator for secrets, tokens, and nonces. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Applies to lifecycle and generation of authenticators and secret values used for access. |
| Recommendation — Generate and manage authenticators so they are unpredictable and resistant to guessing. | ||
| CIS Controls v8 | CIS-5 — Account Management | Supports secure creation of account-linked tokens and credentials with sound randomness. |
| Recommendation — Use approved randomness for account-related secrets and rotate any weakly generated values. | ||
Practitioner Guidance
What to verify: Check every code path that emits a secret, token, nonce, reset link, API credential, or session identifier, including retry logic and test utilities. The common failure is not a bad algorithm choice on paper, but one forgotten helper function that still uses timestamps or counters.
What good looks like: The application uses a cryptographically secure generator by default, the generated value is long enough for its use case, and the design does not depend on obscurity from a predictable sequence. If a value can be observed once and then guessed again, the design is still too weak.
Practitioner takeaway: Treat randomness as a security control, not a convenience feature. If the value can grant access, survive replay, or unlock a workflow, only a cryptographically strong source is acceptable.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org