Should organisations keep security questions for any users at all?

Only in low-risk, tightly scoped situations where better recovery methods are unavailable and the account cannot expose sensitive access. Even then, the control should be treated as transitional, monitored, and paired with stronger verification. For privileged or business-critical identities, the default should be removal.

Why This Matters for Security Teams

Security questions are still common because they are cheap to deploy, but they are weak recovery controls and poor authentication factors. For non-human identities and privileged accounts, they create a predictable path to account takeover, especially when answers are guessable, reused, or exposed in data breaches. Current guidance from NIST Cybersecurity Framework 2.0 and NHI governance practice points toward stronger verification, better lifecycle controls, and reduced reliance on knowledge-based recovery. That matters because security questions often remain in place long after stronger alternatives exist.

The real risk is not just weak answers. It is the operational habit of preserving fallback paths that bypass MFA, PAM, and recovery workflows built around verifiable identity proofing. In NHI-heavy environments, the stakes are higher: service accounts, API keys, and recovery contacts can become indirect backdoors when support staff can override controls with nothing more than a memorised phrase. NHI governance guidance in the Ultimate Guide to NHIs makes the broader point clearly: weak identity controls accumulate into long-lived exposure, not isolated exceptions. In practice, many security teams encounter credential abuse only after a recovery workflow has already been used to sidestep stronger controls.

How It Works in Practice

The practical answer is to remove security questions wherever an account can reach sensitive systems, privileged admin tools, or production workloads. For those cases, use stronger recovery methods such as help desk proofing tied to a central identity provider, hardware-backed MFA, verified manager approval, or delegated admin workflows through PAM. The same principle applies to NHI recovery: recovery should be based on workload identity, secrets management, and lifecycle automation, not on human memory. NHI controls in the Ultimate Guide to NHIs emphasise rotation, offboarding, and visibility because recovery and revocation are part of the same trust chain.

• Use security questions only for low-risk accounts with no access to sensitive data or administrative functions.
• Prefer JIT verification flows that issue temporary access after a real-time approval or proofing event.
• Store recovery evidence in the identity platform or support system, not in the account itself.
• Apply RBAC and PAM so that support staff cannot self-authorise access outside defined process.
• Review all fallback paths as part of your identity lifecycle and incident response testing.

For control design, anchor the program in NIST Cybersecurity Framework 2.0 identify, protect, and recover functions, then map those requirements to actual recovery workflows. Where secrets are involved, the stronger pattern is short-lived, revocable credentials, not static knowledge-based prompts. This aligns with NHI research showing how often secrets persist in unsafe locations and how rarely organisations fully revoke them after exposure. These controls tend to break down when legacy help desk processes still allow manual overrides because the operational team cannot enforce proofing consistently across channels.

Common Variations and Edge Cases

Tighter recovery control often increases help desk overhead and can slow legitimate account restoration, so organisations need to balance user experience against the blast radius of a compromised fallback path. That tradeoff is real for consumer accounts, small internal tools, and temporary pilots where stronger identity proofing may not yet be available. Current guidance suggests treating security questions as transitional, not strategic, and replacing them as soon as a better recovery method exists.

There is no universal standard for this yet, but the strongest pattern is to reserve security questions for the narrowest possible use case, limit the questions to non-sensitive accounts, and expire them on a defined schedule. For higher assurance environments, pair the policy with phishing-resistant MFA, evidence-based recovery, and monitored escalation through PAM. The broader governance model in the Ultimate Guide to NHIs and the control structure in NIST Cybersecurity Framework 2.0 both support the same direction: reduce standing fallback access and make exceptions visible. The main exception is regulated or legacy environments where migration is constrained; in those cases, document the exception, monitor use, and set a removal date.

Related resources from NHI Mgmt Group

• How should security teams govern phishing-resistant authentication for privileged users?
• How can organisations keep automated access decisions current over time?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?