Career path
Identity and Access Management
What people in this area work on
Almost every system asks two questions: who are you, and what are you allowed to do? Identity and access management covers both, along with how access changes over time.
IAM teams manage sign-in methods, multi-factor authentication, and role-based permissions. A large part of the work is the account lifecycle: granting the right access when someone joins, adjusting it when their role changes, and removing it when they leave.
Stolen or overly powerful accounts play a part in many incidents, so careful access design has a direct security payoff.
Terms used on this page
- Authentication
- Proving who you are, for example with a password and a second factor.
- Authorization
- Deciding what an authenticated account is allowed to do.
- Multi-factor authentication (MFA)
- Signing in with more than one kind of proof, such as a password plus a code from an app.
- Role-based access control
- Assigning permissions to roles, such as member or officer, and then assigning people to roles.
- Least privilege
- Giving each account only the access it needs.
- Account lifecycle
- The joiner, mover, and leaver process of creating, changing, and removing access.
How the work flows
One piece of work, start to finish. Every step below is something you can practise in the starter project.
- RolesDecide what each role may do
- GrantGive new people only that
- ChangeAdjust access when roles change
- ReviewCheck who still needs what
- RemoveClose access the day someone leaves
Examples of everyday tasks
- Design roles and the permissions each role needs.
- Review who can reach sensitive systems and remove access that is no longer needed.
- Automate account creation, changes, and removal.
- Configure single sign-on and multi-factor authentication.
- Investigate suspicious sign-ins and accounts with excessive permissions.
Related job titles
- IAM analyst
- Identity security engineer
These are career areas to explore, not a checklist. Some of these job titles usually require experience, and completing a starter project does not by itself make someone ready for them.
Starter project
Design and Test Role-Based Access
Use a local demo with member, officer, and administrator roles. Test what happens when someone joins, changes roles, and leaves.
This is a local practice lab with made-up accounts, for learning how access works.
What you’ll use
- A small local demo app, database, or directory service that you set up yourself
- Made-up test accounts for each role
- A spreadsheet for the permissions matrix
Resources to start with
- OWASP Authorization Cheat Sheet (opens in a new tab)
Guidance on designing and enforcing permissions, including least privilege.
- NIST SP 800-63 Digital Identity Guidelines (opens in a new tab)
The National Institute of Standards and Technology’s guidelines on identity and authentication.
More projects for this path
Each one comes with the framework to follow, five name ideas and a walkthrough for publishing it on GitHub.
- Role-Based Access Lab
Design member, officer and admin roles, then test joining, changing role and leaving.
- Joiner, Mover, Leaver Automation
Script the access changes for joining, changing role and leaving, then prove they ran.
Project walkthrough
- List the actions in your demo, such as viewing events, editing events, and changing someone’s role.
- Build a permissions matrix: one row per action, one column per role, and yes or no in each cell.
- Create a test account for each role and confirm each one can do only what the matrix allows.
- Joiner: add a new member account and test its access.
- Mover: change a member to an officer, confirm the new permissions work, and check that nothing extra was granted.
- Leaver: remove an account and confirm it can no longer sign in or keep any access.
What to publish
- A permissions matrix
- Access-test results for each role
- An account lifecycle walkthrough covering joining, changing roles, and leaving
Optional extension
Automate an access change and verify that obsolete permissions are removed.
Example résumé bullet
Numbers are what make a bullet worth reading, so count them while you work: how much data you searched, how many findings you fixed, how many tests you added. Every figure should be one a reader can find in your report. Write the line after the work is done, and leave out impact or experience you cannot show.
Numbers to record while you work
| Count | Where it comes from |
|---|---|
| Roles defined | permissions matrix |
| Actions mapped per role | matrix columns and rows |
| Access tests run | test results table |
| Excess permissions removed | before-and-after matrix |
Project name | tools, datasets and frameworks | link
TurnstileKeycloak, RBAC design, NIST SP 800-63, Permissions matrix, DockerGitHub
Designed 3 roles across 18 actions in a local demo; tested all 54 permission combinations, corrected 5 that granted more than intended, and verified that a leaver lost access to all 18 actions.
Give the project a name of its own: “Turnstile” is an example, not a label to copy. List the tools, datasets and frameworks you actually used, since several relevant ones show more than a single tool does. Hyperlink the last part to your published repository or report.
A day on the job
Try the work before you try the project
A short walkthrough of a realistic situation. Nothing is scored: each choice explains what would happen, so you can talk through the reasoning later.
New officers start Monday, old ones still have access
Eight officers are rotating out and six are rotating in. Everyone currently has access to everything, including the alumni mailing list.
Where do you start?
The treasurer needs the finance folder only during the budget cycle. What do you set up?
Choose above to continue.
How do you prove the change worked?
Choose above to continue.
Turn your project into a portfolio piece
A project becomes easier to evaluate when someone can understand what you did, inspect the evidence, and follow your reasoning.
Create a short report, GitHub README, or portfolio page. A clear two-to-four-page report is a useful starting point, not a strict requirement.
Include:
- Goal: What question or problem did you investigate?
- Environment: What tools, practice data, or systems did you use?
- Your work: What did you personally do, and why?
- Evidence: Include useful screenshots, queries, code, or test results.
- Findings: What did you discover? What remains uncertain?
- Fix or recommendation: What should change, and did you test it?
- Sources and limitations: Credit datasets and guides. Clearly identify simulated work.
Use sample or redacted information in the public version.
Publish the report somewhere accessible without requesting permission, and check the link before putting it on a résumé.
Put numbers in it
Count as you work, and put the figures in the report: records searched, findings confirmed, tests added, checks failing before and after. A reviewer can check every one of them against your evidence, which is exactly why they are worth including. Leave out business impact you cannot show.
Name it, then show your tools
A résumé line works best in three parts: your project’s own name, the tools and frameworks you used, and a link to the work. “Role-Based Access Lab” reads like a class exercise. A name plus a tool list tells a reviewer what you can actually work with, and every tool, dataset or framework you list honestly is another thing an interviewer can ask you about.
Project name | tools, datasets and frameworks | link
- Role-Based Access LabTurnstile | Keycloak, RBAC design, NIST SP 800-63, Docker | GitHub
- Login HuntBeacon | Python, pandas, Sigma, MITRE ATT&CK | GitHub
- Cloud ProjectBedrock | Terraform, Checkov, AWS IAM, CIS Benchmarks | GitHub
Why link a report?
Your résumé gives a short description of the project. The linked report lets a reviewer inspect your work and gives you concrete evidence and decisions to discuss during an interview.
Not every recruiter will open it, but it makes your work available for review.
BeaconPython, pandas, Sigma, MITRE ATT&CK, LANL authentication datasetGitHub
Investigated a public authentication-log dataset for repeated failed logins followed by successful access; documented search queries, supporting evidence, and limitations in a reproducible hunt report.
Hyperlink the last part to the published work, so “GitHub” or “Project Report” opens your repository or report. Check the link before you send the résumé.
Preview the write-up template
# Project title > Practice project. Describe the simulated scenario, practice data, or lab used. ## Goal What question or problem did you investigate? ## Environment What tools, practice data, or systems did you use? Link datasets and guides. ## My work What did you personally do, and why? ## Evidence Screenshots, queries, code, or test results. Use sample or redacted information only. ## Findings What did you discover? The numbers behind it (records searched, findings confirmed, tests added). What remains uncertain? ## Fix or recommendation What should change, and did you test it? ## Sources and limitations - Datasets and guides used: - What was simulated: - Limitations: