Seven identity security myths, checked against the published facts

Published 2026-09-20 · NextGen Identity Security desk · 3 min read

Identity security has picked up a set of shorthand beliefs that are only partly true. Each one below is checked against a standard or a vendor's own documentation, and each links to the page on this site that goes further.

Myth 1: MCP requires authorization

It does not. Authorization is optional in the MCP specification. What the specification does say is that implementations using HTTP should follow its OAuth-based authorization rules, and implementations using local STDIO should take credentials from the environment instead. Whether an MCP deployment is protected depends on how it is set up, not on the protocol alone.

Myth 2: A one-time code makes sign-in phishing-proof

A one-time code stops password reuse and guessing, but an adversary-in-the-middle page can relay the code to the real site as the victim types it. Methods that tie the sign-in to the real site's address, such as passkeys and FIDO2 security keys, resist this. Microsoft lists those among its phishing-resistant methods, and NIST SP 800-63B-4 sets out the assurance levels vendors refer to.

Myth 3: ITDR makes stronger sign-in unnecessary

ITDR tools detect and respond to attacks on identity systems. Some, such as Silverfort, can block an attempt before authentication completes; others, such as Microsoft Defender for Identity, are positioned for detection, investigation and response. None of them makes a phishable sign-in method harder to phish. Detection and prevention are separate layers, and most organizations need both.

Myth 4: Secrets management and non-human identity security are the same

A secrets manager stores and rotates the secrets it holds: CyberArk's secrets management centrally rotates and manages credentials for applications and pipelines. Non-human identity tools also look for identities and secrets that were never put in a vault and tie them to owners: Entro searches clouds, code, CI/CD, on-premises systems and collaboration tools, and maps every NHI and secret to a human owner. The two overlap, but a vault only knows what is in it.

Myth 5: An AI agent is just another service account

Agents are non-human identities, and OWASP's Non-Human Identities Top 10 applies to them in full. The difference is that an agent chooses its own next action. A service account running a fixed script does the same thing every time; an agent with the same permissions may not. That is why checks at the moment of each call matter more for agents.

Myth 6: A new identity provider means removing the old one

Not necessarily. Federation standards such as SAML and OpenID Connect were designed to let identity systems trust one another, and some products are built to run next to an existing identity provider. NewCore describes an agent-driven coexistence model that preserves existing federations and policies.

Myth 7: A token is safe once the user has passed MFA

The token is what an attacker wants, precisely because it represents a completed sign-in. NIST IR 8587, final since 15 September 2026, is devoted to protecting tokens and assertions from forgery, theft and misuse. The controls it points to include short token lifetimes, re-evaluating sessions when risk changes, and protecting the keys that sign tokens.

Why this matters for scoring

Each myth maps to a criterion on one of our topic pages. Where a vendor's public material leaves the question open, the cell is tagged Gap in public material. That tag is not a verdict on the product; it is a prompt to ask.