❓ 20 Frequently Asked Questions about identity and access management
These answers 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.
Identity and access management is the collection of policies, processes and systems that determines who may access which services, under what conditions and for how long. The National Cyber Security Centre’s (NCSC) identity guidance covers appropriate checks on the means people use to sign in, account management and additional safeguards for administrators. My point is that these belong together. A smart sign-in screen is useful, but it cannot decide whether a former contractor still needs access. Leaders should therefore govern the whole service, from establishing the relationship to verifying that obsolete permissions have stopped working.
No. Authentication means checking control of a registered sign-in method; authorisation means deciding what the account may do. The article draws that distinction from the National Institute of Standards and Technology (NIST) and NCSC guidance. Imagine the payroll colleague who changes departments but keeps their old permissions. Their passkey, a device-managed digital key used instead of a password, can work exactly as intended while the access decision remains wrong. I would ask for evidence of permission review after changes, not another successful login demonstration. A working key tells us something important, but it does not make every cupboard in the building yours.
I would appoint a business owner answerable for the service’s outcomes with enough authority to resolve gaps between technology, security, customer operations, employment or volunteer management, procurement and suppliers. That is my proposed operating model, not a job title prescribed by the cited guidance. Its justification is practical: the steps people follow to obtain, change or recover account access cross organisational boundaries, and each team can complete its own task while the person remains locked out or obsolete access survives. The owner should coordinate outcomes, refer unresolved risks to someone with authority to act and involve affected people, without personally approving every account.
Start with the processes through which people obtain, use, change or recover account access where failure could cause the greatest harm: permissions that allow actions with potentially serious effects, essential customer services and recovery routes that people genuinely depend upon. The article’s risk-based approach draws on NIST and NCSC guidance; the prioritisation is my recommendation for applying it. Establish who owns each journey, which applications it touches and which other services it needs to work. Then inspect the evidence already available. Buying another tool before understanding the gap may produce an impressive inventory and remarkably little improvement for the person needing help.
Establish the person’s relationship with the organisation, the level of confidence needed in their identity and the access justified by their duties or service needs. The NCSC recommends account-management processes that cover joiners, movers and leavers, including temporary and third-party access. I would record the owner and the relevant review or end trigger at the outset. A volunteer, contractor and employee may have different agreed sources of relationship information, so do not assume one automated supply of employment updates covers everyone. Grant what is needed, and make later adjustment and removal part of the original design.
A role change should trigger a decision about what comes away as well as what gets added. The NCSC’s identity and access principle calls for reviewing rights and removing them in the systems themselves when no longer required, including after a move. My practical recommendation is to identify the affected applications, authorise the changes and check that the applications actually apply them. Otherwise, permissions can accumulate because every new role adds something while nobody owns the subtraction. The payroll-transfer example in the article is illustrative, not evidence that a particular organisation suffered that failure.
There is no universal deadline established by the sources used here. Agree timescales according to potential harm, the approved event that starts the removal process, service obligations and available safeguards. An urgent suspension may need different handling from a planned departure.
NCSC and Information Commissioner’s Office (ICO) guidance support removing unnecessary access; the article’s checks within individual applications are proposed ways of judging whether the service meets agreed conditions. Record when timing begins and verify when access actually stops, including relevant existing sessions, meaning continuing signed-in interactions. A completed ticket establishes that somebody recorded an action, not necessarily that every permission became unusable.
Yes. NCSC identity guidance explicitly asks organisations to consider populations beyond permanent employees, including contractors and volunteers. Their relationship may be recorded by a sponsor or coordinator rather than payroll, but that does not make their access somebody else’s problem. For each access process, I would identify a responsible owner, justified permissions, review arrangements and an agreed event that ends the need for access. Those are proposed implementation choices. The aim is to support people doing legitimate work while avoiding accounts that remain active simply because their departure never reached the usual employment process.
Usable recovery gives a legitimate person an understandable route when their normal sign-in method is unavailable, without quietly dropping the necessary verification. NIST’s digital identity guidance considers customer experience, privacy, alternative ways to use the service and redress, meaning routes to challenge and resolve a problem. I interpret that as a reason to design recovery alongside authentication, not bolt it on later. Test the route with the assistance people would actually have. If the service promises unassisted recovery, success only with an engineer beside the customer does not demonstrate that promise. Properly staffed assisted recovery can still be appropriate.
No. Urgency should influence escalation and service response, not erase verification. The joint Scattered Spider advisory describes reported methods in which support requests were used to obtain resets or changes to sign-in control. That evidence justifies treating recovery decisions as sensitive; it does not justify blaming everyone who answers a telephone. I would give support colleagues clear checks, a reachable route to someone authorised to resolve difficult requests and permission to pause. Targets should not punish them for following the safeguards that management expects them to uphold.
Test two questions separately: can the legitimate person recover safely, and can an inappropriate request be refused or escalated? NIST supplies the reasoning for designing around the people using the service; the Scattered Spider advisory supplies evidence for scrutinising impersonation during support. My proposed tests use authorised assessors, test accounts without sensitive information where possible, agreed conditions and a procedure for stopping the exercise safely. Record the help required, checks performed and permissions restored. One successful customer journey does not establish the ability to resist requests from someone pretending to be the account holder, just as rejecting an impostor tells us little about whether a distressed customer can navigate the service.
Accessibility belongs in the design and testing of the journey, not in an exception process discovered after somebody is excluded. NCSC guidance recognises that no single authentication method suits everyone or every environment, while NIST considers the experience of people using identity services. I would involve people with relevant accessibility needs and different levels of digital confidence. Test their approved alternatives and available support. This is not an argument for abandoning the necessary confidence in identity. It is an argument for obtaining an appropriate level of confidence in identity without assuming that everyone can use the preferred device or interaction.
Collect information proportionate to the recovery decision and its risks, rather than treating every additional question as another layer of security. The NIST guidance discussed in the article considers privacy alongside identity-service design. My recommendation is to review what each requested item contributes, how it will be protected and whether a route requiring less personal information can provide sufficient confidence that the request is legitimate. A customer who has lost their telephone should not automatically acquire a second problem: supplying an unnecessarily extensive personal dossier. The exact verification method needs technical and privacy review.
Privileged accounts can administer systems or other accounts. NCSC guidance recommends additional safeguards for them, including multifactor authentication and separate accounts for administration and everyday work. Multifactor authentication combines different kinds of evidence, such as something a person knows and something they possess. The reasoning is that authority to change security settings or other accounts deserves particular care. I would also examine enrolment (establishing an account and its means of signing in), replacement of sign-in methods and account recovery for those accounts, because a strong normal login does not settle who can change its sign-in method. Choose arrangements appropriate to the risk and actual working environment. A director’s impatience is not a technical control, however confidently it is expressed.
Where appropriate, yes. NCSC guidance on managing authority to administer systems or accounts supports approved temporary access and permissions limited to the task, with approval arrangements chosen according to risk. A narrower scope and shorter lifetime constrain the opportunity available through that permission; they do not make misuse impossible. I would define the purpose, approver, duration, recorded activity and when the permission ends, then test that the permission ends as intended. Also check that legitimate emergency work can obtain approval when needed. Temporary access is not much comfort if its expiry exists only in the sales presentation.
Examine the other services needed for sign-in, recovery, permission updates and emergency administration, rather than testing only whether a login page appears. Cloudflare’s June 2025 incident account reports disruption to logins that rely on identity information, account updates and an emergency control for disconnecting connectivity software because they relied on the same unavailable service. That is a provider’s account of specific failures, not a description of every system’s design. My recommendation is to test relevant local scenarios under agreed safety controls, including access to instructions, approved ways of continuing limited work and restoration. Establish who can authorise alternatives before the ordinary route becomes unavailable.
Restoration should meet an agreed end condition that covers both service availability and access reconciliation, meaning checking and resolving outstanding permission changes. The article proposes checking pending role changes, outstanding removals and exceptional permissions after a required service becomes available again. Cloudflare’s account motivates that concern because it reports interrupted identity updates as well as failed logins, but it does not prove how every customer’s configured service behaves. I would record unresolved exceptions and their owners. A green status indicator is welcome news; it is not evidence that every change waiting to be processed has reached the application that matters.
Ask suppliers to demonstrate outcomes under conditions representative of your users, applications, support arrangements and other required services. That is the article’s proposed approach to judging whether the service meets agreed conditions, not a claim that a standard prescribes this exact test programme. Request conditions, settings, expected and observed results, recorded times, exceptions and action owners. Separate usability, security and whether actions happen within agreed timescales. An existing customer offered as a reference can provide useful context, but their different environment does not validate yours. A supplier willing to explain a limitation is more useful than a demonstration that quietly edits the difficult bits out.
I would review cases where access removal did not meet agreed conditions, legitimate recovery outcomes, support demand, failed tests and outstanding corrections. These are proposed management measures derived from the article’s service-outcome approach, not a set of measures proven suitable for every service. Keep usability, security and whether actions meet agreed timescales visible separately, and investigate exceptions with potentially serious effects rather than hiding them in an average. Explain the scope and limitations of each measure. A dashboard can help the conversation, but counting installed features does not establish that a customer can recover safely or that a former worker’s permissions have genuinely stopped working.
No. The sources used in the article support safeguards chosen according to potential harm and likelihood, not a promise that identity failures can be abolished. Guidance informs design, and representative testing provides evidence about recorded conditions. Neither guarantees every future outcome. My view is that this uncertainty strengthens the case for accountable ownership, proportionate controls, usable recovery and continued review. Record what remains untested, correct significant gaps and retest after material changes. We should be candid about limits without using them as an excuse for accepting avoidable failures that leave people carrying the consequences.