Trust, but Verify: Why Identity Pros Shouldn't Outsource Their Judgment to NIST, ACSC, or GCHQ

Overview

There's a reflex in our industry that I want to challenge. Someone proposes a control, a reviewer asks "does it follow NIST?", and the conversation ends. The citation is the argument. The standard becomes a substitute for thinking.

I rely on these bodies constantly. NIST SP 800-63 is the backbone of how most of us reason about identity assurance, authenticator strength, and federation. The ACSC's Essential Eight is a genuinely useful baseline. NCSC guidance is often the clearest writing in the field. None of that is in dispute.

What I'm pushing back on is deference — the habit of treating government guidance as neutral, disinterested truth rather than as the output of organizations with their own mandates, incentives, and blind spots. For identity and security professionals, that distinction matters more than for almost anyone else, because the things we build are exactly the things a signals-intelligence agency has a professional interest in being able to defeat.

The conflict of interest is structural, not hypothetical

Start with who actually writes a lot of this guidance.

In the United States, NIST is a civilian standards body — but by statute it is required to consult with the NSA on cryptographic matters. The NSA, in turn, has two missions that sit in direct tension: signals intelligence (breaking into communications) and information assurance (protecting them). The same institution is paid to weaken cryptography for its targets and to strengthen it for its own side.

The UK and Australia don't even maintain the fiction of separation. The NCSC is part of GCHQ. The ACSC sits inside the Australian Signals Directorate. In both countries, the body issuing your defensive best-practice guidance is housed within the national agency whose other job is offensive interception. These are talented, well-intentioned people doing serious defensive work — but the org chart contains an unresolved conflict, and pretending otherwise is naïve.

There's even a doctrine for it. Inside the intelligence community it's sometimes called NOBUS — "Nobody But Us." The idea is that if you discover or introduce a weakness that only you can realistically exploit, it's acceptable to leave it in place. The obvious problem: "nobody but us" is a bet, not a guarantee. A backdoor with a key is still a backdoor, and key custody has a way of failing — through leaks, theft, parallel discovery, or a shift in who counts as an adversary.

This isn't a fringe concern. In 2013, a review group appointed by President Obama recommended splitting the NSA's defensive arm out into a separate organization precisely to remove this conflict of interest. The NSA declined, and in its 2016 reorganization moved the offensive and defensive functions closer together instead. Bruce Schneier has written about this competing-priorities problem at length — he argued for breaking the NSA's attack and defense functions apart in Data and Goliath, and his 2015 essay "Hacking Team, Computer Vulnerabilities, and the NSA" makes the point that an agency tasked with both eavesdropping and protecting will always be tempted to prioritize surveillance over security. If you read one thing alongside this post, read him.

The encryption wars: governments at war with their own advice

To see why deference is dangerous, it helps to zoom out. The tension I'm describing isn't a one-off scandal; it's a thirty-year pattern in which the same Western governments — and especially the same agencies — have been simultaneously for and against strong encryption. They tell you to encrypt, and they try to make sure they can decrypt. Both messages come from the same building.

The first Crypto War (1990s). When strong cryptography began escaping government hands and showing up in consumer software, the US response was twofold. First, export controls: encryption was regulated as a munition, and to sell software abroad you shipped deliberately weakened "export-grade" ciphers presumed to be within the NSA's reach. Those weakened ciphers were so durable that they were still breaking real web traffic two decades later, via attacks like FREAK and Logjam in 2015. Second, the Clipper chip (1993): an NSA-designed chipset using the classified Skipjack algorithm with built-in key escrow — a copy of every key held for government access. It was, in plain terms, a mandated backdoor. The cryptographic community revolted, Matt Blaze publicly demonstrated a fatal flaw in the escrow scheme in 1994, and the program was dead by 1996. But the idea — lawful access by design — never died.

Bullrun and Dual_EC (2000s–2013). The offensive side never stopped. As detailed in the next section, the NSA is credibly understood to have engineered a backdoor into a NIST-standardized random number generator and, per the Snowden disclosures, run a broad program (Bullrun) to undermine commercial cryptography. This is the same period the agency was publicly trusted to help set the standards everyone relied on.

The Five Eyes go coordinated (2018–2020). The fight then went multinational and explicit. In 2018, the Five Eyes — the US, UK, Canada, Australia, and New Zealand — issued a joint Statement of Principles on Access to Evidence and Encryption, warning that if industry didn't provide "lawful access solutions" voluntarily, the governments "may pursue technological, enforcement, legislative or other measures." In October 2020, the Five Eyes plus India and Japan went further with an International Statement on End-to-End Encryption and Public Safety, opening with praise for encryption and then asking providers to engineer access into end-to-end-encrypted systems anyway. The framing is always the same: encryption is vital, but — and the word "but" is doing enormous work.

Australia (2018). Australia turned the rhetoric into law with the Assistance and Access Act (TOLA), which lets agencies compel "designated communications providers" to build access capabilities. The penalties run to millions; the oversight was, by the government's own independent reviewer's account, inadequate. (I cover TOLA in detail in the companion CyberCon post.)

The UK (2016–present). The UK's Investigatory Powers Act 2016 — the "Snooper's Charter" — lets the Home Office issue secret Technical Capability Notices compelling providers to remove "electronic protection." In a case that became public in early 2025, the UK reportedly served Apple with such a notice demanding access to Advanced Data Protection — Apple's end-to-end-encrypted iCloud — for users worldwide. Apple's response was to withdraw ADP from the UK rather than build the backdoor, and to challenge the order. After US diplomatic pressure the demand was reported withdrawn in August 2025, only for reporting later in 2025 to indicate the UK had renewed it in narrower, UK-only form. The notable feature throughout: the orders are secret, gagged, and extraterritorial by design.

New Zealand. The smallest Eye is also a signatory to those joint statements and operates interception-capability obligations on telecommunications providers (under its TICSA regime), with the GCSB as its SIGINT agency. It hasn't gone as far as Australia legislatively, but it sits inside the same coalition pushing the same line.

And yet — the other face. Here's the part that should make any architect wary of taking guidance at face value. The very same apparatus is also the loudest advocate for strong encryption when its own side is the target. The NSA leads US government cryptology and helped drive the open competitions behind AES and SHA-3 and the current post-quantum standards. And in December 2024, after the Chinese "Salt Typhoon" intrusions into US telecom carriers, US government agencies urged Americans — especially high-value targets — to abandon SMS and adopt end-to-end-encrypted messaging like Signal. So within a few years you have Western governments telling their own citizens to use Signal to defeat foreign interception, while simultaneously pressuring Apple and others to weaken the equivalent protections so domestic agencies can intercept. Encryption is a vulnerability when they want in, and a necessity when someone else wants in.

That contradiction is the whole point. These bodies are not anti-encryption or pro-encryption; they are pro-access — access for themselves, denial of access to their adversaries. That is a coherent institutional goal. It is simply not the same goal as "build the most secure system possible for the user in front of you," which is yours. When you treat their guidance as neutral, you quietly inherit their threat model — one in which lawful interception of your users is a feature, not a bug.

Exhibit A: Dual_EC_DRBG

If the conflict were only theoretical, this would be an easier argument to wave away. It isn't.

Dual_EC_DRBG was a random number generator standardized by NIST in SP 800-90 (2006). Random number generation is foundational — if an attacker can predict your "random" values, they can predict your keys, and everything built on those keys collapses.

The problems surfaced almost immediately:

• In 2007, Microsoft researchers Dan Shumow and Niels Ferguson demonstrated at a conference that the algorithm's fixed parameters could conceal a backdoor: whoever generated those constants might hold a secret value that lets them predict all output.
• That same year, Bruce Schneier wrote a piece bluntly titled "Did NSA Put a Secret Backdoor in New Encryption Standard?" The cryptographic community had a name for the weakness and a plausible suspect.
• Despite all of this, the algorithm stayed in the standard for years.
• Then in 2013, documents from the Snowden leaks pointed to exactly the kind of program — NSA's Bullrun effort — that the skeptics had suspected. Reporting later indicated RSA had been paid roughly $10 million to make Dual_EC the default generator in its widely used BSAFE library.

NIST recommended against the algorithm in 2013 and formally removed it when it published SP 800-90A Revision 1 in 2015. To its credit, NIST acknowledged the loss of public confidence and reviewed its own standards process afterward.

But sit with the timeline. The weakness was demonstrated publicly in 2007. It was not removed until 2015. For roughly seven years, the official, government-blessed recommendation was an algorithm that respected cryptographers were openly warning carried a likely backdoor. Anyone whose answer to "should we use this?" was "it's the NIST standard, so yes" was wrong for the better part of a decade.

Exhibit B: when the ASD deplatformed its critics

Dual_EC is about the cryptography these bodies touch. But the conflict of interest shows up in their behavior too — and that's the part most people miss, because it doesn't look like a math problem.

In October 2019, Australia's flagship security conference, CyberCon, was co-run for the first time by the Australian Cyber Security Centre — which, recall, sits inside the ASD, the country's signals-intelligence agency. Days before the event, two confirmed speakers were dropped: NSA whistleblower Thomas Drake, who was to speak on the modern surveillance landscape, and University of Melbourne researcher Dr Suelette Dreyfus, whose topic was anonymous whistleblowing technology like SecureDrop. Both had been on the program for nearly a year. ACSC's then-head publicly confirmed she made the call, citing the speakers' associations with unauthorised disclosure of classified information.

Read that back. The agency we're asked to treat as a neutral authority on cyber security used its position to remove, from the security community's own stage, the people whose talks were critical of surveillance. That is not a defensive-security judgment; it is an institutional one, made in the interests of the agency and the government — and it tells you exactly whose priorities win when those priorities collide with open debate.

This is the deeper reason not to grant reflexive trust. It's not just that these bodies might weaken a primitive. It's that they are organizations with interests, and when pushed, they will act on those interests even at the expense of the very openness that good security depends on. An authority that will quietly edit the conversation is an authority whose guidance you read with your eyes open. (I wrote up the full CyberCon affair, and the "anti-encryption" Assistance and Access Act it sat alongside, in a companion post.)

Even good-faith guidance goes stale — and that's the more common failure

It would be a mistake to make this only about backdoors. The more frequent way deference burns you is mundane: the guidance is sincere, widely adopted, and simply wrong or outdated.

Our own field is the cleanest example. For decades, the consensus — backed by standards and auditors everywhere — was to force complexity rules and periodic password rotation. We all enforced it. We all built CIAM flows around it. In 2017, NIST reversed itself: composition rules and arbitrary expiry don't help and often hurt, because they push users toward predictable patterns. Revision 4 of SP 800-63B reinforced the new position, leaning on length, breach-list screening, and phishing-resistant authenticators.

Here's the uncomfortable part for the deference reflex: the practitioners who'd reasoned from first principles — that Password1! → Password2! was theater — were right years before the standard caught up. The people who deferred enforced bad policy for a generation of users and called it best practice because a document told them to.

But — and this is the point — the new guidance shouldn't be swallowed whole either, because it is itself contested. Two examples from exactly the recommendations people now cite reflexively:

• Dropping permanent account lockout. NIST's preference for rate-limiting and throttling over hard lockout is well-reasoned: permanent lockout after N failures is a gift to an attacker who doesn't care about getting in and only wants to lock everyone else out. Submit a handful of bad passwords against every account and you've built a denial-of-service attack out of the security control itself. That's a real argument. But it cuts both ways — throttling that's too permissive can leave you exposed to the credential-stuffing and password-spraying you were trying to stop. There's no setting that's correct for every organization; there's only the setting that's correct for your abuse profile.
• Dropping complexity rules in favour of length. The cryptographic logic is sound — a long passphrase beats a short P@ssw0rd!. But security isn't only cryptographic; it's also perceived. A signup form that accepts aaaaaaaaaaaaaaaa with a green tick and no complexity requirements can read, to an ordinary user, as a company that simply isn't taking their security seriously — eroding the trust that CIAM exists to build. The right answer is usually to pair length with breach-list screening and clear feedback, but that's a design judgement you have to make, not a box NIST ticks for you.

Neither of these means NIST is wrong. It means the current guidance, like the guidance it replaced, encodes a particular set of trade-offs — and whether those trade-offs fit depends on your threat model, your abuse history, and your users. The lesson isn't "follow the old rules" or "follow the new rules." It's that companies should implement controls that match their own threat model, not mindlessly follow NIST in either direction.

Standards are a lagging indicator of good thinking, not a leading one.

So what should an identity architect actually do?

Not throw the standards out. That's the lazy overcorrection, and it gets people hurt. The right posture is critical engagement — use the guidance, but keep ownership of the judgment. Concretely, in CIAM work:

1. Read the threat model the guidance assumes, not just the recommendation. A control that's right for a federal agency defending against nation-states may be wrong for a consumer signup flow optimizing for conversion and recovery. Lift the reasoning, not the checkbox.

2. Then test it against your threat model and your own incident history. This is the step most teams skip. Take NIST SP 800-63B: it steers you away from password composition rules and away from aggressive account lockout (favoring rate-limiting and throttling instead). For most consumer-facing services that's exactly right — it reduces user friction without materially helping an attacker. But "right for most" isn't "right for you." If your organization has a history of targeted credential-stuffing, password spraying, or account-takeover incidents, the throttling thresholds NIST contemplates may be too loose for the abuse you actually see, and dropping lockout entirely may hand attackers a cheaper path than your own incident reports can justify. The recommendation isn't wrong; it just assumes a threat model that may not be yours. Hold each control up against your last twelve months of incidents and ask: does this defend against what actually attacks us, or against what attacks the average org NIST had in mind?

3. Prefer open, peer-reviewed cryptography with broad scrutiny. Favor primitives that survived public competition and independent analysis (AES, the SHA-3 process, modern curves with transparent provenance) over anything whose constants or design rationale you can't inspect. "Nothing-up-my-sleeve" parameters exist for a reason.

4. Treat a citation as the start of due diligence, not the end. "It's NIST-compliant" is a fact about a document, not a security property of your system. Ask what attack it stops and whether that attack is in your model.

5. Watch for the dual-mandate fingerprint. Be most skeptical exactly where defensive guidance touches something an interception agency benefits from weakening: RNGs, key escrow and "lawful access" proposals, curve and parameter choices, and anything that nudges you toward a single mandated default.

6. Cross-reference across bodies and the independent community. When NIST, the NCSC, ISO, the IETF, and respected academic cryptographers all converge, confidence is high. When they diverge — or when the wider community is uneasy — that disagreement is signal, not noise.

Use the standards. Respect the expertise behind them. But the moment "the standard says so" becomes the whole of your reasoning, you've stopped being an engineer and started being a compliance function. Dual_EC is what that costs.

And it's worth naming what's actually happening when "NIST says so" ends the conversation: that's the appeal to authority, one of the oldest logical fallacies there is. A claim isn't true because a respected body endorsed it; it's true because the reasoning and evidence hold up. Authorities are a useful shortcut to that reasoning, not a substitute for it — and as we've seen, sometimes the authority has a thumb on the scale. So cite NIST, the NCSC, the ASD. Just don't let the citation do your thinking for you.

References