💡 Debunking 20 Common Myths about identity and access management
These myth-busters expand the article’s guidance and proposed practices, distinguishing evidence from interpretation and recommendation. Examples remain illustrative; neither this page nor the cited material establish supplier test results, universal guarantees or a compliance assessment.
Terminology at a Glance
- Access reconciliation means checking and resolving outstanding permission changes.
- Authentication checks control of a registered sign-in method.
- Authorisation decides what an account may do.
- Multifactor authentication combines different kinds of evidence, such as something a person knows and something they possess.
- Passkeys are device-managed digital keys used instead of passwords.
- Privileged accounts can administer systems or other accounts.
- Redress means routes to challenge and resolve a problem.
Evidence and context: see the article’s References and Further Reading, particularly NCSC identity and access management guidance. Recommendations and cautions above retain the qualifications explained in the main article.
If you come across any other terms you are unfamiliar with, visit our Glossary of Terms page – if the term you’re unsure bout is not included, write a comment and let me know what is missing and I will fill the gap with an authoritative definition.
This mistake confuses the most visible component with the service surrounding it. National Cyber Security Centre (NCSC) guidance covers more than checking how people sign in. It also addresses access decisions, account changes, removal and administrative safeguards. Installing a sign-in product leaves those responsibilities intact. It cannot determine whether a contractor’s assignment has ended, approve a customer’s recovery or decide how work continues during disruption. That is why I regard identity as an operating process supported by software, rather than software with a few administrative chores attached. A well-built front door cannot compensate for nobody knowing who should still hold a key.
The faulty assumption is that evidence about signing in also proves a right to access the service. The National Institute of Standards and Technology (NIST) describes checking control of registered authenticators, meaning the means used to sign in; NCSC guidance addresses appropriate access. Neither makes the other question disappear. The distinction becomes obvious when a colleague retains permissions from an earlier role: the sign-in check can succeed while the decision about permitted actions is wrong. Lost-device recovery presents the reverse problem, where the right to access may remain legitimate but the usual means of signing in is unavailable. Treating both as login failures obscures the remedy. My recommendation to examine continuing permissions and recovery follows from the different questions these decisions are intended to answer.
The overclaim is not that passkeys, device-managed digital keys used instead of passwords, are useful. The NCSC recommends them over passwords where available. It is the leap from stronger checks on the means used to sign in to a complete account-protection service. A permission can outlive its justification regardless of the sign-in method, and support can still be asked to change account control. The Scattered Spider advisory reports attempts involving precisely those support decisions, including changes involving multifactor authentication, which combines different kinds of evidence, such as something known and something possessed. I would therefore scrutinise enrolment (establishing an account and its sign-in methods), replacement of those methods and recovery alongside adoption. Improving the lock is progress; leaving replacement-key decisions ungoverned is not a property of the lock.
This myth turns organisational influence into evidence of lower risk. Yet NCSC guidance calls for additional protection where accounts have authority to administer systems or other accounts, precisely because mistakes can affect systems and other people. Seniority may change someone’s support needs, but it does not authenticate an urgent request or justify an automatic exemption. My management judgement is to address inconvenience through usable arrangements and reachable assistance, not preferential routes around verification. That recommendation applies reasoning based on potential harm and likelihood; it is not a separate NCSC rule about executive job titles. Greater authority is a reason for accountability, not immunity.
Calling recovery “merely” customer service hides its power to transfer control. The joint Scattered Spider advisory describes reported requests for resets and changes that moved sign-in control onto criminals’ devices. That evidence makes the decision security-sensitive; it does not diminish the legitimate customer’s need for help. NIST supplies the complementary concern: people’s experience and redress, meaning routes to challenge and resolve problems. My conclusion is that neither team can finish the design alone: recovery must assist the rightful person, resist inappropriate requests and equip support colleagues to do both. Those outcomes require separate examination, rather than one reassuring completion figure.
The error is treating social confidence as sufficient verification. Apparent familiarity, status and urgency can make a request persuasive without establishing who controls the account. The advisory’s reports of impersonation during support interactions provide a reason to distrust that shortcut, not a finding that every incident follows the same script. I favour approved proportionate checks and referral to someone authorised to resolve the request when the evidence remains uncertain. Staff must be able to pause without being labelled obstructive. The distinction matters for customers too: calm, courteous verification protects them better than a friendly conversation that hands their account to somebody else.
This presents a false choice between protection and a service people can use. NCSC guidance seeks both resistance to impersonation and straightforward legitimate access; NIST considers people’s experience and routes to challenge and resolve problems. Genuine trade-offs remain, but difficulty alone proves neither strength nor effectiveness. A recovery process that defeats the rightful customer has not demonstrated a security success. Equally, improving completion by silently relaxing verification proves little about protection. My preference is to examine usability and security separately, keeping both results visible. Otherwise, the organisation can congratulate itself on a better score while concealing which outcome it has sacrificed.
Uniformity is being mistaken for suitability. NCSC guidance recognises differences between people, devices and environments, so a convenient default cannot establish universal coverage. The article’s lost-phone, accessibility and connectivity examples expose possible design gaps; they are not statistics about how often those gaps occur. My recommendation is to establish which circumstances matter locally and involve affected people in testing approved alternatives. Access that could have serious effects still needs an appropriate level of confidence in identity. The alternative to a rigid single route is not unrestricted entry, but deliberate provision for legitimate users who cannot follow the default journey.
The hidden assumption is that quantity of personal information equals confidence that the request is legitimate. NIST’s customer-centred approach considers privacy as part of the risks created by the identity service, rather than a concern to postpone until verification is complete. I would ask what each requested item contributes and subject the checks to technical and privacy review. A longer questionnaire may burden someone already struggling with lost access without establishing that the request is genuine. The practical standard is proportionate verification with a defensible purpose for collection, not a contest to assemble the largest dossier.
This is an incomplete definition of a successful move. Delivering the new permissions says nothing about whether old authority has ended. The NCSC identity and access principle supports reviewing rights and removing unnecessary access in the systems themselves, including after a role change. The illustrative payroll transfer makes the consequence concrete: somebody can be fully equipped for the new job while retaining inappropriate access to the old one. I would assign responsibility for subtraction as well as addition and verify both in the affected services. Former permissions are not long-service souvenirs.
This substitutes an administrative action for proof of its effect in the connected services. A central account can be marked disabled without that observation establishing what every connected application or continuing session will permit. The article draws on NCSC and Information Commissioner’s Office (ICO) access-removal guidance, but proposes its own checks that applications actually prevent the access. Because connections between systems differ, we cannot assume every continuing signed-in interaction ends in the same way. Define the relevant services and completion conditions, test them and record exceptions individually. The meaningful result is that obsolete authority can no longer be exercised. The dashboard tick may be accurate about its own task while answering a narrower question.
This treats authority over information and the decision to retain it as the same thing. The article separates those questions without supplying either a timetable for keeping records that applies everywhere or a legal opinion. Necessary business records and account histories should be handled through the appropriate authorised retention and handover processes; leaving a former user’s access active is not the same thing. My recommendation is to make that separation explicit. Where an application prevents it, treat the limitation as a gap with an owner and correction, rather than preserving unnecessary authority under the comforting description of keeping the records available.
The mistaken conclusion is that a possible emergency justifies permanent unrestricted authority. NCSC guidance on administrative authority supports approved temporary access limited to the work required. Emergency administration nevertheless has to be usable: recovery staff may need instructions, approvals and credentials while ordinary routes are unavailable. I would design scope, authorisation, observation and expiry around those conditions and check that the people who need them can actually reach those resources. That is a proposal based on risk, not a single system design prescribed for every service. The objective is a controlled recovery route, not a standing exception that becomes more attractive than the safeguards it was supposed to complement.
Different labels do not establish different failure paths. Cloudflare’s June 2025 account reports that its emergency control for disconnecting its connectivity software depended on the same unavailable service, preventing use of that fallback. This is a specific provider-reported observation, not a general finding about all identity products. Its value is to challenge an assumption worth examining locally. I would map the other services needed by ordinary and exceptional access, including instructions, approvals and required credentials, then test the relevant failure conditions. Independence needs evidence about those required services. It cannot be conferred by putting “emergency” on a different screen.
This judges the refusal without examining the access restrictions it is intended to uphold. Cloudflare reports that Access denied entry when required policy or identity information was missing. This refusal when required information is unavailable, known as failing closed, can preserve the intended access restrictions while still imposing serious disruption on legitimate users. Neither consequence should be ignored. My conclusion is that leaders must decide beforehand which activities stop, which restricted alternatives are acceptable and who authorises them. That does not vindicate every refusal. It rejects the equally unsafe assumption that access should continue regardless of whether the evidence needed to approve it is available.
A supplier’s availability statement and the completion of a customer’s access changes cover different things. Cloudflare’s incident account reports interrupted identity updates as well as logins, giving the article a reason to recommend checking and resolving outstanding permission changes after service returns. It does not establish that every customer had changes waiting to be processed or that all system designs behave alike. I would check the relevant removals, role updates and temporary permissions against an agreed end condition, assign exceptions and state uncertainty. The green indicator can be truthful and welcome while leaving those customer-specific outcomes unverified. It is evidence of neither universal completion nor universal failure.
This assumes that moving work across a contractual boundary also removes the need to govern it. The Cybersecurity and Infrastructure Security Agency’s (CISA) Secure by Design programme places responsibility for customer protection on provider leadership, but does not allocate every contractual task or cancel customer responsibilities. The article’s recommendation is to make ownership observable across settings, identity checks, support, connections between systems, recovery and removal, with escalation where responsibilities meet. Agree outcomes on both sides rather than relying on the word “shared”. Outsourcing can redistribute delivery; it cannot answer an unresolved responsibility question simply by moving it into another organisation’s queue.
A commitment and an achieved result are different kinds of evidence. The CISA pledge discussed here is voluntary and not legally binding. Its goals can shape useful procurement questions, but signing does not establish performance in a particular customer’s configured service. I would follow the commitment through to included controls, settings, support and relevant evidence of recovery and removal. That is scrutiny of delivery, not dismissal of public promises. The pledge tells us what a supplier has committed to pursue; the records and observations are needed to judge whether the outcomes required by this customer have actually been demonstrated.
The mistake is generalising beyond the conditions observed. A demonstration using different people, applications, devices, support arrangements or other required services may be informative without validating the intended service. The article proposes agreeing how well the test reflects the intended environment, recording differences from the live service and assessing usability, security and completion within agreed timescales separately; it does not claim a test procedure proven suitable everywhere. Consider the logical gap: successful legitimate recovery does not establish refusal of an impostor, nor does either observation show that obsolete permissions elsewhere were removed. Each conclusion needs relevant evidence. A polished demonstration is not discredited by its limits, but those limits must travel with the result.
This turns an observation made under particular conditions into a prediction without limits. A pass describes what was observed for a particular service version, set of settings and scenario, not every future change or untested circumstance. NIST’s approach of choosing safeguards according to risk informs the reasoning, while correction, retesting and review after material change are the article’s proposed practices. Record the boundaries and assign owners to exceptions so that evidence remains usable rather than ceremonial. Tests matter because they replace some assumptions with observations. Expecting them to guarantee an uneventful future asks them to do something quite different, and considerably closer to fortune-telling.