I6.5 Privileged Access and Administrative Accounts
Learn how defenders govern fictional administrative identities, temporary elevation, privileged sessions, emergency access, separation of duties, action evidence, de-elevation, and post-use review.
Lesson Progress
Privileged Access and Administrative Accounts
High School Intermediate • I6: Identity and Access Management • Lesson 5 of 8
Readiness Check
Before You Start
0/5 ready
Professional Hook
Administrative Access Should Exist Only for the Approved Task
Privilege is not a permanent reward for technical skill. A fictional administrator should receive only the actions, resources, conditions, and time required for an approved task. Strong governance separates ordinary work from administration and preserves evidence from request through post-use review.
Weak response
“Give permanent administrator access because this user handles technical support.”
Strong response
“Define the exact action and target, approve a narrow temporary role, use a protected session, preserve evidence, and verify de-elevation.”
Objective 1
Explain privileged access, administrative accounts, standing privilege, temporary elevation, emergency access, and separation of administrative duties.
Objective 2
Evaluate fictional privileged-access requests using owner, purpose, resource, action, duration, approval, device, MFA, session, logging, and rollback evidence.
Objective 3
Identify excessive standing privilege, shared administration, stale privileged roles, unowned emergency accounts, session gaps, and weak monitoring.
Objective 4
Distinguish privileged authentication, privileged authorization, elevation, action execution, validation, and post-use review.
Objective 5
Create a professional fictional Privileged Access Review Report with confirmed facts, findings, owners, remediation, validation, monitoring, and residual risk.
Why This Matters
Privilege Can Change Other Identities, Controls, and Evidence
Administrative access can create accounts, assign roles, change policies, disable controls, alter services, approve workflows, or remove evidence. That makes ownership, separation of duties, temporary elevation, monitoring, rollback, and independent validation especially important.
Privileged Account Types
Eight Administrative Identities with Different Control Needs
Named administrative account
Represents one fictional administrator performing approved elevated work.
Strong controls
Unique ownership, separate standard account, MFA, approved device, temporary elevation, logging, session limits, and periodic review.
Common risk
The account is used for normal browsing or email, keeps standing privilege, or is shared by multiple administrators.
Application administrator
Manages fictional application users, roles, settings, integrations, or protected business functions.
Strong controls
Application owner, exact administrative scope, fresh authentication, change approval, local-access review, and application audit logs.
Common risk
Central identity records do not show local application privilege or the role includes unrelated configuration powers.
System administrator
Manages fictional servers, operating systems, services, updates, storage, or infrastructure settings.
Strong controls
Restricted administrative device, separate account, approved maintenance window, command or action logging, rollback, and validation.
Common risk
Broad access across unrelated systems, use from personal devices, or insufficient review of high-impact changes.
Identity administrator
Manages fictional accounts, groups, roles, factors, policies, access reviews, or privileged elevation.
Strong controls
Separation of duties, temporary role activation, strong MFA, protected workstation, approval, monitoring, and independent verification.
Common risk
One identity can request, approve, assign, and conceal its own privilege.
Security administrator
Manages fictional defensive tools, alerts, policies, exclusions, quarantine, isolation, or security configuration.
Strong controls
Narrow tool role, evidence preservation, approval for disruptive actions, change control, rollback, and post-action validation.
Common risk
Broad exclusions, unreviewed containment, disabled logging, or excessive access to private security data.
Service administrator
Represents a fictional non-human identity that performs an approved elevated service or automation function.
Strong controls
Named owner, exact workload, restricted source, minimal permissions, managed identity or protected credential, logging, and lifecycle review.
Common risk
No active owner, nonexpiring credential, interactive use, unexpected source workload, or broad permissions.
Emergency or break-glass account
Provides fictional recovery access when normal identity or administrative services are unavailable.
Strong controls
Strict storage, strong monitoring, limited permissions, periodic testing, named owners, immediate post-use review, and credential rotation.
Common risk
Routine use, stale credentials, unknown ownership, no alerting, or failure to rotate after use.
Shared legacy administrator
Supports a fictional legacy environment that cannot yet use unique named administrative identities.
Strong controls
Documented exception, named authorized users, restricted device, session recording, limited permissions, expiration, and replacement plan.
Common risk
Weak individual accountability, password sharing, permanent exception status, and incomplete action attribution.
Privileged Access Lifecycle
Eight Phases from Request to Post-Use Review
Request
Required evidence
Fictional requester, account, role, resource, exact actions, purpose, urgency, start, duration, owner, and expected outcome.
Failure pattern
The request says only “admin needed” without defining scope or business need.
Approval
Required evidence
Resource owner, privileged-role owner, separation-of-duties reviewer, conditions, maintenance window, and expiration.
Failure pattern
The requester approves their own privilege or an unrelated manager approves access they do not own.
Authentication
Required evidence
Fictional administrative account, strong MFA, approved device, fresh session, source environment, and policy result.
Failure pattern
A remembered standard-user session becomes privileged without fresh authentication.
Elevation
Required evidence
Exact role, permissions, activation time, expiration, ticket, approver, session, and reason.
Failure pattern
A broad permanent role is assigned instead of a narrow temporary role.
Execution
Required evidence
Fictional actions, targets, commands or changes at a safe conceptual level, timestamps, results, errors, and linked change record.
Failure pattern
The session is active but the system records no traceable action evidence.
Validation
Required evidence
Required function, configuration state, service health, user experience, negative tests, rollback readiness, and owner confirmation.
Failure pattern
The change is considered complete because the administrative console shows success.
De-elevation
Required evidence
Role removal or expiration, session revocation or refresh, account state, remaining privilege, and effective-access check.
Failure pattern
The temporary role expires, but an older privileged session remains active.
Post-use review
Required evidence
Request, approval, actions, outcome, exceptions, monitoring, evidence gaps, owner acceptance, and residual risk.
Failure pattern
No one reviews emergency or high-impact administrative use after the work ends.
Just-Enough and Just-in-Time Access
Eight Questions Before Elevating Privilege
Which exact privileged action is required?
Strong practice
Grant only the needed action, such as restart one service or manage one application role.
Weak practice
Grant full system administrator because it includes the required action.
Which exact resource is in scope?
Strong practice
Limit the fictional role to the named server, application, tenant, group, project, or policy.
Weak practice
Grant access to every environment for one local task.
How long is privilege needed?
Strong practice
Use automatic expiration tied to the approved maintenance or support window.
Weak practice
Leave privilege standing because the administrator may need it again.
Which account should be used?
Strong practice
Use a separate named administrative identity or approved service identity.
Weak practice
Use the everyday account for email, browsing, and privileged work.
Which device and session are approved?
Strong practice
Require a protected fictional administrative device and fresh authenticated session.
Weak practice
Allow elevation from any device or remembered session.
Who approves and verifies the work?
Strong practice
Use accountable owners and independent review for sensitive actions.
Weak practice
Let one fictional identity request, approve, implement, and close the same task.
What evidence must be preserved?
Strong practice
Preserve request, approval, role, session, actions, target, results, validation, and review evidence.
Weak practice
Keep only a screenshot showing the final dashboard.
How will access end?
Strong practice
Define role expiration, session revocation, access verification, monitoring, and closure.
Weak practice
Assume closing the administrative window removes privilege automatically.
Core Concept
Privileged Access Requires Five Connected Boundaries
Identity
Use the approved named administrative or service identity rather than an everyday or unowned account.
Authority
Match the fictional role and permissions to the exact approved action, resource, and duration.
Session
Use fresh authentication, a protected device, a traceable session, and appropriate expiration.
Action
Preserve the exact target, change, result, error, deviation, and linked change record.
Closure
Remove privilege, refresh sessions, validate outcomes, review evidence, and document residual risk.
Evidence Matrix
What Privileged-Access Evidence Can and Cannot Prove
Evidence source
Privileged-access request
Can support
The fictional requester, purpose, role, resource, actions, urgency, duration, owner, and expected outcome.
Limitation
The implemented privilege can be broader, longer, or different from the request.
Evidence source
Approval record
Can support
The fictional approver, scope, conditions, maintenance window, expiration, separation-of-duties review, and decision.
Limitation
Approval does not prove the approver understood the technical permissions or that the system enforced the exact scope.
Evidence source
Role and permission record
Can support
The fictional privileged role, permissions, resource scope, activation time, expiration, owner, and assignment path.
Limitation
Application-local permissions, nested roles, or active sessions may create additional effective access.
Evidence source
Authentication record
Can support
The fictional administrative account, MFA, device, source, application, policy, session, and sign-in result.
Limitation
Successful authentication does not prove approval, safe intent, or correct authorization for every privileged action.
Evidence source
Privileged session record
Can support
The fictional session start, account, role, device, target, duration, recorded actions, result, and end state.
Limitation
A session record may be incomplete if some tools, local consoles, or connected systems do not forward evidence.
Evidence source
Change or action log
Can support
The fictional target, action, setting, object, result, error, time, and administrative identity associated with a change.
Limitation
The log may show a technical result without business purpose, owner approval, or full impact.
Evidence source
Validation evidence
Can support
The fictional required function, service health, configuration state, positive test, negative test, rollback state, and owner confirmation.
Limitation
One test may not cover delayed effects, other environments, cached sessions, or alternate access paths.
Evidence source
Post-use review
Can support
The fictional evidence summary, deviations, exceptions, findings, owner acceptance, monitoring, lessons learned, and residual risk.
Limitation
A review is only as reliable as the completeness and independence of the evidence.
Privileged Access Findings
Eight High-Value Risks and Narrow Corrections
Standing administrator privilege
Evidence
A fictional account retains a broad administrative role continuously despite using it only during monthly maintenance.
Impact
The account has elevated capability during normal activity and outside approved maintenance windows.
Correction
Replace standing privilege with narrow time-limited activation, fresh authentication, logging, and expiration validation.
Shared administrative account
Evidence
Four fictional administrators use one legacy account to manage an application.
Impact
Actions cannot be attributed reliably to one person, and factor or session ownership is unclear.
Correction
Move toward named accounts; meanwhile restrict use, record sessions, identify users, limit permissions, and maintain an approved exception.
Self-approved elevation
Evidence
A fictional identity requests and approves its own temporary identity-administrator role.
Impact
Separation of duties is bypassed and unauthorized privilege can be concealed.
Correction
Require an independent privileged-role owner or approved emergency review path.
Expired role with active session
Evidence
A fictional elevated role expires, but the existing administrative session continues to allow privileged actions.
Impact
The technical session remains more powerful than the current authorization state.
Correction
Revoke or refresh the session, verify effective access, and test similar applications.
Unowned emergency account
Evidence
A fictional break-glass account has broad privilege but no current owner or recent test.
Impact
No one is accountable for storage, monitoring, rotation, or post-use review.
Correction
Assign owners, restrict permissions, test safely, verify alerting, document storage, and define post-use rotation.
Broad service privilege
Evidence
A fictional service identity has write and administrative access even though the workload reads one data set.
Impact
A non-human identity can change unrelated resources or permissions.
Correction
Reduce to the exact read scope, restrict source workload, validate reports, and monitor denied write attempts.
Administrative use from standard device
Evidence
A fictional privileged session begins from a general-purpose device used for email and browsing.
Impact
The administrative session is exposed to a broader set of everyday risks and weaker separation.
Correction
Require the approved administrative device or protected environment and fresh authentication.
Incomplete action logging
Evidence
A fictional privileged role activates and a change occurs, but no session or action record links the administrator to the exact target.
Impact
Reviewers cannot reconstruct what changed, validate scope, or investigate an error.
Correction
Improve logging and evidence routing before allowing similar privileged work.
Separation of Administrative Duties
Six Workflows That Need Independent Responsibility
Privileged role request
Request or execution
A fictional administrator describes the exact task, target, actions, urgency, and duration.
Independent role
A resource owner or privileged-role owner approves the scope.
The requester cannot create and approve their own elevated authority.
Identity administration
Request or execution
A fictional support reviewer identifies an account or role change.
Independent role
An identity administrator implements the approved change and another reviewer validates effective access.
Request, implementation, and verification remain separate.
Security-tool policy change
Request or execution
A fictional analyst proposes a narrow defensive-tool rule adjustment.
Independent role
The tool owner approves and a separate reviewer validates alerting and false-negative coverage.
The same person does not silently reduce security coverage and approve the result.
Emergency access
Request or execution
A fictional incident lead authorizes break-glass use under an approved emergency condition.
Independent role
A separate owner reviews the session, rotates the credential, and confirms closure afterward.
Urgency does not remove post-use accountability.
High-impact configuration
Request or execution
A fictional system owner approves a critical service configuration change.
Independent role
One administrator performs the change and another verifies service health, logs, and rollback readiness.
Independent validation reduces the chance that an unnoticed error becomes accepted evidence.
Privileged-access recertification
Request or execution
The fictional account manager confirms current job responsibility.
Independent role
The resource owner confirms exact privileged need and the identity team removes rejected roles.
Each reviewer answers a distinct ownership and technical question.
Emergency Access
Eight Checks for a Fictional Break-Glass Account
Named ownership
Which fictional leaders or teams own the emergency account, storage method, review schedule, and escalation path?
Failure pattern
The account exists, but no current owner accepts responsibility.
Narrow emergency purpose
Which fictional outage, recovery, or identity-service failure justifies use?
Failure pattern
The account is used for routine convenience or normal maintenance.
Protected storage
How is the fictional emergency credential or factor protected, accessed, inventoried, and changed?
Failure pattern
The credential is stored in an unreviewed document or shared message.
Strong monitoring
Which fictional alerts, session records, action logs, owner notifications, and case workflows begin when the account is used?
Failure pattern
Emergency access produces no immediate alert or independent review.
Periodic safe test
Can the fictional account authenticate and perform only the approved recovery actions during a scheduled test?
Failure pattern
The organization discovers during an emergency that the account is expired or unusable.
Post-use rotation
How are fictional credentials, factors, sessions, and stored recovery materials changed after use?
Failure pattern
The same emergency authentication material remains valid after an incident.
Post-use review
Who confirms the fictional reason, actions, target, duration, outcome, exceptions, and residual risk?
Failure pattern
The session ends without evidence-based review.
Replacement and retirement
When should the fictional emergency account, method, or dependency be redesigned or removed?
Failure pattern
A temporary emergency workaround becomes permanent standing privilege.
Privileged Access Validation
Eight Tests for Safe Elevation and De-Elevation
Approved action succeeds
Confirm the fictional administrator can complete the exact required task during the approved window.
Fictional example
The temporary service-operator role can restart one named training service.
Successful result
The required action succeeds and is linked to the correct session, ticket, target, and owner.
Unrelated action remains denied
Confirm the fictional role does not include broader administrative powers.
Fictional example
The service operator cannot create users or change network policy.
Successful result
The unrelated actions are denied and the decision reason is logged.
Resource boundary holds
Confirm the fictional privilege applies only to the approved target.
Fictional example
The role can manage training-server-04 but not other servers.
Successful result
The approved target works and neighboring resources remain denied.
Expiration removes role
Confirm the fictional elevation ends automatically at the approved time.
Fictional example
The temporary role disappears after forty-five minutes.
Successful result
The role assignment and effective access both show no remaining privilege.
Session refresh removes claims
Confirm existing fictional sessions do not retain expired privilege.
Fictional example
The administrative console requires a new access decision after expiration.
Successful result
The old session cannot continue privileged actions.
Rollback remains available
Confirm the fictional change can be reversed safely if service or policy validation fails.
Fictional example
The previous approved configuration is preserved and tested in the rollback plan.
Successful result
The team can restore the prior state without improvising.
Monitoring records the work
Confirm fictional activation, actions, errors, results, and closure reach the expected monitoring systems.
Fictional example
The privileged session and change appear in the review dashboard with matching timestamps.
Successful result
Another reviewer can reconstruct the work from preserved evidence.
Business function remains healthy
Confirm the fictional service, application, or user workflow works after the privileged change.
Fictional example
The training application operates normally and the owner accepts the result.
Successful result
Technical and business validation agree.
Defensive Workflow
Review Privileged Access in Six Steps
Define the privileged need
Identify the fictional administrator, role, target, exact actions, owner, purpose, urgency, and duration.
Verify approval and separation
Confirm independent approval, resource ownership, change control, conditions, and conflict checks.
Establish trusted elevation
Use the approved administrative account, protected device, fresh MFA, session, and time-limited role.
Monitor the privileged work
Preserve activation, actions, targets, results, errors, deviations, and security-tool evidence.
Remove privilege
Expire or revoke the role, refresh sessions, verify effective access, and handle emergency credential rotation.
Validate and review
Confirm required function, negative tests, owner acceptance, evidence completeness, monitoring, and residual risk.
Key Vocabulary
Privileged Access and Administration Terms
Privileged access
Fictional access that can create, change, delete, approve, configure, monitor, or control identities, systems, applications, policies, or sensitive resources.
Administrative account
A fictional account used for elevated system, application, identity, security, or resource-management actions.
Standard account
A fictional account used for ordinary work that should not carry unnecessary administrative permissions.
Standing privilege
Fictional privileged access that remains continuously assigned rather than being activated only when needed.
Temporary elevation
A fictional privileged role or permission activated for a limited approved time and purpose.
Just-in-time access
A fictional process that grants privileged access only when approved and needed, then removes or expires it automatically.
Just-enough access
A fictional design that grants only the specific privileged actions required for the approved task.
Privileged session
A fictional authenticated session used to perform elevated administrative actions.
Break-glass account
A tightly controlled fictional emergency account used only when normal administrative or identity paths are unavailable.
Separation of duties
Dividing fictional request, approval, implementation, and verification responsibilities among different accountable identities.
Elevation approval
The documented fictional decision authorizing a specific privileged role, action, resource, duration, and condition.
Post-use review
A fictional review of the privileged request, actions, evidence, outcome, validation, and residual risk after the elevated work ends.
Fake Dashboard
Fake Privileged Access Review Dashboard
Training dashboard for the fictional Northstar Learning Services environment.
Elevations reviewed
21
Fifteen normal temporary activations, two emergency tests, two standing-role findings, one service identity, and one incomplete session.
Privilege findings
8
Standing access, shared administration, self-approval, stale session, unowned emergency access, broad service privilege, weak device separation, and incomplete logging.
Validated closures
18
Each includes role removal, session review, positive and negative tests, owner confirmation, monitoring, and residual risk.
Fake SOC Alert
Temporary Administrative Role Expires but the Session Retains Privileged Claims
Source: Fake Privileged Access Review Console • Time: 01:57 PM
Fake Log Panel
Fake Temporary Privileged-Access Timeline
13:00:00 REQUEST admin='training-akal' role='service-operator' target='training-service-04' action='restart' 13:04:00 OWNER_APPROVAL scope='restart_only' duration='45m' 13:07:00 CHANGE_REVIEW rollback='approved' validation='approved' 13:10:00 AUTH account='admin-training-akal' device='admin-workstation-08' mfa='fresh' 13:11:00 ELEVATION role='service-operator' expires='13:56' 13:15:00 ACTION target='training-service-04' operation='restart' result='success' 13:20:00 NEGATIVE_TEST action='manage_users' result='deny' 13:20:10 BOUNDARY_TEST target='training-service-05' result='deny' 13:30:00 OWNER_VALIDATION service_workflow='healthy' 13:56:00 ROLE state='expired' 13:57:00 SESSION old_claims='present' 13:58:00 SESSION action='revoked' 14:00:00 TEST privileged_action='deny' 17:00:00 POST_USE_REVIEW closure='approved' residual_risk='documented'
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Which Privileged-Access Conclusion Is Best Supported?
Which conclusion is strongest?
Common Mistakes
Mistakes That Weaken Privileged-Access Governance
Safe Practice Lab
Review a Fictional Privileged-Access Packet
Fictional Environment
Meadowbrook Administrative Access Review
Review thirty-two supplied fictional records involving named administrators, standard accounts, service identities, temporary roles, standing privilege, emergency access, devices, sessions, approvals, actions, validation, monitoring, and post-use review.
Required Analysis
- Identify every fictional privileged identity, owner, account type, role, resource, action, and duration.
- Trace request, approval, authentication, elevation, execution, validation, de-elevation, and review evidence.
- Find standing privilege, broad scope, self-approval, shared administration, session gaps, and emergency-account weaknesses.
- Separate confirmed actions from assumptions about intent or impact.
- Recommend narrow owner-approved corrections with preserved evidence and rollback.
- Validate approved actions, unrelated denials, resource boundaries, expiration, session refresh, monitoring, and business function.
- Document evidence gaps, owners, residual risk, and closure criteria.
Scenario Decision Lab
A Support Administrator Has Permanent Broad Privilege
A fictional support administrator uses a standing system-admin role for monthly service restarts and everyday work. The role also permits user management, policy changes, and access to unrelated systems.
Scenario Decision Lab
A Break-Glass Account Is Used During a Fictional Identity Outage
A fictional identity-service outage requires emergency access. The break-glass account restores service, but the credential has not been rotated and no independent post-use review has occurred.
Defender Habits
Privileged Access and Administrative Accounts Checklist
Check Your Understanding
I6.5 Mini Quiz: Privileged Access and Administrative Accounts
Choose your answers first. Explanations appear only after submission.
1. What is standing privilege?
2. What is just-in-time access?
3. What is just-enough access?
4. Why should privileged work use a separate named administrative account?
5. What should happen when a temporary privileged role expires?
6. Which emergency-account control is strongest?
7. Which privileged-access validation plan is strongest?
Portfolio Prompt
Portfolio Prompt
Create a fictional Privileged Access Review Report containing at least thirty-two request, approval, administrative-account, device, MFA, role, permission, resource, session, action, result, error, rollback, validation, emergency-access, monitoring, and post-use-review records. Include standing privilege, temporary elevation, just-enough access, just-in-time access, separation of duties, shared administration, service privilege, emergency-account governance, session cleanup, narrow recommendations, positive tests, negative tests, residual risk, and closure criteria.
Key Takeaways
What You Should Remember
Navigation