Cybersecurity Career Foundations · Beginner · ~7 hours
Identity & Access Management
Build a practical understanding of identity, access decisions and least-privilege security.
Status: Catalogue ready. This lesson version is available in review mode while subject-matter, accessibility and assessment checks are completed.
Identity before access
Identity, authentication and authorisation
By the end of this lesson
- Distinguish an identity claim, an authentication event and an authorisation decision.
- Explain why an authenticated user is not automatically entitled to every resource.
- Describe how logs and ownership support accountability without treating logging as surveillance.
Three questions that are easy to confuse
Identity and access management begins with three separate questions. Who is the person or service asking to act? How has the system checked that the claim is genuine? What is this identity allowed to do in this particular context? An email address or username is an identity claim. A password, passkey, security key or approved second factor can help authenticate the claim. A role, group membership, resource policy or explicit approval can then inform authorisation. Keeping these stages distinct makes a system easier to explain and safer to troubleshoot. Authentication is not the same as trust for all time. A successful sign-in may prove that a person controlled an approved factor at a point in time, but the session may still expire, require a step-up check or be limited by device, location, time and resource sensitivity. Authorisation should therefore be evaluated for each meaningful action, not treated as a permanent badge. A support analyst who can read a ticket may not need permission to export a database. A salesperson who can view a customer account may not need to change billing details. The question is always whether the requested action is necessary for the person's current responsibility. Accountability means that an organisation can reconstruct relevant decisions with appropriate privacy safeguards. Logs should show a stable account identifier, the action, the resource, the time and the outcome, while avoiding unnecessary copies of personal or sensitive content. Shared accounts weaken this picture because a later reviewer cannot reliably tell which person acted. Where a technical exception is unavoidable, the organisation should document ownership, approval, monitoring and a path to remove the exception. Good IAM language is precise: “the request was authenticated” does not mean “the request was appropriate”, and “the user has a role” does not prove that every permission in that role is needed.
A useful access decision is explainable
A practical access decision can be written as a short chain of evidence. Start with the resource owner and the business task. Identify the minimum action required, the identity or service that will perform it, the duration, and any conditions such as read-only access or a second approver. Then record how the request was verified and how it will be reviewed. This approach works for a new starter, a temporary project, a supplier support account and an internal automation. It also gives a support or sales professional a safe way to discuss security without promising that a product will solve every governance problem. Consider a fictional organisation where a project coordinator asks for access to an analytics workspace. “Give me the same access as the data team” is not a sufficient requirement. A better conversation asks which reports the coordinator must read, whether they need to create or edit anything, who owns the workspace and when the project ends. If the answer is read-only access to three reports for six weeks, a narrow permission is easier to approve and easier to remove. If the request later expands, the change can be recorded and reviewed rather than quietly accumulating permissions. This evidence-led habit also helps when an access request is declined. Declining is not a judgement on the person; it is a decision that the current evidence does not support the requested scope. Offer the smallest safe alternative, explain what additional evidence would be needed and give the requester a route to challenge the decision. Never copy passwords, recovery codes, private identity documents or secret tokens into a lesson, ticket or CRM note. Use fictional identifiers in training and redact real information before sharing examples.
Workplace example
At fictional firm Alder Works, a new analyst needs to view weekly revenue dashboards but not edit source data or export customer records. The manager confirms the task, the dashboard owner approves read-only access and the end date is recorded. The analyst authenticates with their own account, and the access is reviewed when the project closes.
Try this walkthrough
- 1.Name the resource owner and describe the task in plain language.
- 2.Choose the narrowest action that enables the task: view, comment, edit, approve or administer.
- 3.Record the identity, approval, duration and review point using fictional data.
- 4.Check that the decision does not include passwords, tokens, identity documents or unnecessary personal data.
Watch for these traps
- Treating a successful sign-in as proof that every action should be allowed.
- Using a shared account because it appears quicker than assigning individual ownership.
- Granting broad administrator access to avoid asking what the actual task requires.
- Putting secret values or private identity evidence into a ticket or training example.
Knowledge check
Choose the response you think is strongest. These checks are practice until the course version has passed subject-matter review; graded attempts will be handled server-side.
For the reviewed pilot, answers are checked on the server. This draft result is not yet added to your official learning record.
Practice studio
Make a decision. Test a response. Leave evidence.
Use the case from this lesson to practise judgement without creating a score or changing your course record.
Scenario decision
At fictional firm Alder Works, a new analyst needs to view weekly revenue dashboards but not edit source data or export customer records. The manager confirms the task, the dash…
Choose a response
Branching roleplay
A colleague asks you to move this situation forward. What do you say next?
Evidence workspace
Draft a short known / assumed / next note from the fictional case. Use fictional details only.
This is a session-only practice draft. It is not saved, graded or added to your learning record. Never enter real personal or confidential information.
Practical assignment
Create a fictional access decision for a project coordinator who needs six weeks of read-only dashboard access. State the task, owner, permission, evidence, expiry and review route, and explain why two broader permissions are unnecessary.
Pass this lesson's knowledge check before recording it as complete.
Portfolio evidence
Practical portfolio project
Design an access model for a fictional company, including roles, MFA requirements, review points and an offboarding checklist.
Turn the practical project into a bounded evidence record. Save a draft while you work, then submit it for human review when it is ready.
Sign in to save practical evidence. Sign in