← VCE Software Development U4O2

Poor identity and access management practices

Weak control of accounts, permissions and logins, such as shared accounts or no MFA, so the wrong people or systems can reach code and data.

Understanding Poor identity and access management practices in VCE Software Development U4O2

What it does: Giving an intern admin rights over every repository is excessive privilege, which breaks least privilege and widens the damage if the account is misused. An active account for someone who has left is an unmanaged identity that can be abused by the former employee or an attacker. Shared accounts break accountability. Audit trails cannot show who made a change, and one leaked password exposes everyone's access. Accounts not removed when staff leave are called orphaned accounts. They give unauthorised people a way into code and data. Without MFA, a stolen or guessed password is enough for an attacker to get in. MFA adds a second proof of identity.

Common mistakes: The account stays active after the person has left, which is an account not removed when staff leave. It should be staff.active = False so the account is disabled. Logging every login under a shared 'team' account means the audit trail cannot show who acted. It should log the individual user.id.

Class: _____________________  ·  Name: _____________________  ·  Date: _________

Free printable worksheet with full answer key — or add this module to a class and your students practise it interactively.

This module's key terms are also in a printable crossword (Modules 23–47) and word search (Modules 1–47).

Take this worksheet further — free with Cloodit

Each concept is reinforced from every angle — learned, then applied, then tested.

Learning
Duo
A whole dev team logs in to the code repository using one shared account called 'devteam'. Why is this poor identity and access management?
It makes the repository run slower for every userActions cannot be traced to one person, so accountability is lost
Matches
allow_access(user='all_staff', repo='payroll_code')
↓
Access is granted to every staff member instead of only the roles that need it, which is excessive privilege to sensitive code.
Applying
Meanings
Term
Poor identity and access management
Meaning
Weak control of accounts, permissions and logins, such as shared accounts or no MFA, so the wrong people or systems can reach code and data.
Practice
FOR EACH account IN accounts
Testing
Gaps
IF passwordOk mfaOk THEN allowLogin
Check Answer
Spots
3 staff.mfa_devices = []
4 staff.active = True

Cloodit turns curriculum-aligned coding content into journeys students work through one biome at a time.

The 'Kangaroo Rat' badge — Speed Typer, one of Cloodit's 106 collectible badges
Students earn collectable badges

Over 100 of them, across seven natural biomes.

Study Buddy
Students build a real study resource

Turns their work into revision material ready for Flash Cards and Exam study.

Diamond Dash — one of Cloodit's live, competitive Sprint games
Students lock in with Sprints

Live, competitive practice for the start of the lesson or a teacher-led lesson finisher.

A Cloodit certificate of achievement, ready to personalise and print
Custom printable certificates

Honour your top performers, or encourage a student who's trying hard — ready to print in seconds.

Quick Questions

1. A whole dev team logs in to the code repository using one shared account called 'devteam'. Why is this poor identity and access management?
A. Actions cannot be traced to one person, so accountability is lost ✓
B. It makes the repository run slower for every user
Shared accounts break accountability. Audit trails cannot show who made a change, and one leaked password exposes everyone's access.
2. Which situation shows excessive privileges?
A. A tester can only read the test results they need
B. A junior tester has admin rights to the production database ✓
Excessive privileges give users more access than their role needs. This goes against the principle of least privilege.
3. A developer leaves the company but their account stays active for months. What is the main risk?
A. The old account could be misused by the ex-employee or an attacker ✓
B. The account will delete itself and corrupt the code
Accounts not removed when staff leave are called orphaned accounts. They give unauthorised people a way into code and data.
4. Which is the best way to fix the problem of accounts not being removed when staff leave?
A. Disable the account as part of the offboarding process ✓
B. Wait for the staff member to ask for it to be closed
A formal offboarding process removes access straight away so former staff cannot reach code or data.
5. A company lets developers log in to the code repository with only a password. What control is missing?
A. A longer file name for the repository
B. Multi-factor authentication (MFA) ✓
Without MFA, a stolen or guessed password is enough for an attacker to get in. MFA adds a second proof of identity.

Match the Pairs

user: shared_dev | password: Team123 → A shared account used by many developers, so actions cannot be traced to one person and the password is widely known
mfa_enabled = false → No multi-factor authentication, so a stolen password alone gives access to the account
Excessive privileges: a user is given far more access than their job needs → grant(intern, role='admin', repo='all')
Accounts not removed when staff leave stay active and can be misused → leaver.status = 'active' # left 6 months ago
allow_access(user='all_staff', repo='payroll_code') → Access is granted to every staff member instead of only the roles that need it, which is excessive privilege to sensitive code.
login(user='shared_dev', pass='Team123') # whole team → Many developers share one account, so there is no accountability, and the weak shared password is easy to leak.

Key Term

Poor identity and access management
Weak control of accounts, permissions and logins, such as shared accounts or no MFA, so the wrong people or systems can reach code and data.

Fill in the Blanks

1. IF passwordOk AND mfaOk THEN allowLogin
Hint: Type the logical operator that requires both login checks to pass
2. IF user.left THEN disableAccount(user)
Hint: Type the function name that removes access once a staff member has left
3. GRANT SELECT ON students TO intern;
Hint: Type the SQL privilege that lets an intern only read data, not change it
4. FOR EACH dev IN team DO createAccount(dev)
Hint: Type the keyword that loops over every team member so each gets their own account instead of sharing one
5. if not user.mfaOn: requireMfa(user)
Hint: Type the logical operator that reverses the check so users without MFA are caught

Spot the Error

Question 1
A def offboard(staff):
B staff.roles = []
C staff.mfa_devices = []
D staff.active = True
Line D — The account stays active after the person has left, which is an account not removed when staff leave. It should be staff.active = False so the account is disabled.
Question 2
A user = login(name, password)
B if user.mfa_ok:
C log('team', 'login')
D show_dashboard(user)
Line C — Logging every login under a shared 'team' account means the audit trail cannot show who acted. It should log the individual user.id.
Question 3
A intern = create_user('sam')
B intern.role = 'tester'
C intern.repo_access = 'admin'
Line C — Giving an intern admin access to the repository is an excessive privilege. Least privilege means a tester only needs 'read' access.
Question 4
A require_mfa = False
B def login(user, password):
C if check(user, password):
D return send_code(user)
Line A — Turning multi-factor authentication off means a stolen password alone gives access. It should be require_mfa = True.
Question 5
A for staff in left_this_month:
B email_manager(staff)
C remove_from_groups(staff)
Line B — Emailing a manager does not stop the former staff member logging in. The account must be disabled with disable_account(staff).

Student with a class code? Join your class →