Identity-centered architecture
A fictional architecture approach that treats identities, authority, privilege, lifecycle, context, evidence, recovery, and ownership as central design elements across every system and service.
High School AdvancedModule A2Lesson 5 of 10Identity Architecture
A2.5 Identity-Centered Architecture
Learn how advanced defenders design fictional human, service, device, workload, administrator, supplier, automation, emergency, and recovery identities across authentication, authorization, privilege, lifecycle, context, evidence, failure, and recovery.
Lesson Progress
Identity-Centered Architecture
High School Advanced • A2: Security Architecture • Lesson 5 of 10
50% complete
Readiness Check
Before You Start
0/6 ready
Professional Hook
One Login Can Control Too Much of the Architecture
A fictional support role can reach application, data, identity, logging, backup, and recovery functions. Three applications share one broad service credential, supplier access remains active after its support window, and identity administrators can approve their own privilege while changing evidence retention. Every identity may be technically valid, yet the architecture still concentrates too much authority and too little accountability.
Login-centered thinking
Confirm an identity once, assign broad roles, leave access active, and assume valid credentials equal trusted behavior.
Identity-centered thinking
Validate identity, exact action, target, purpose, context, approval, duration, evidence, lifecycle, recovery, and owner.
Objective 1
Explain identity-centered architecture as the coordinated fictional design of human, service, device, workload, administrator, supplier, and recovery identities across their full lifecycle.
Objective 2
Distinguish fictional authentication, authorization, role, privilege, approval, session, delegation, lifecycle, and evidence decisions rather than treating identity as a single login event.
Objective 3
Design fictional least-privilege access for users, services, administrators, suppliers, automation, and recovery using explicit ownership, context, separation of duties, and time limits.
Objective 4
Evaluate fictional identity architecture for privilege concentration, shared accounts, stale access, service-account risk, emergency access, supplier trust, evidence gaps, failure modes, and recovery dependencies.
Objective 5
Create a portfolio-ready fictional identity architecture package using only invented organizations, identities, systems, evidence, decisions, dates, roles, and outcomes.
Why This Matters
Every Architecture Decision Eventually Becomes an Identity Decision
Fictional users access services, applications call data, suppliers support integrations, administrators change controls, automation performs actions, and recovery operators restore systems. Each activity depends on deciding who or what is acting, what it may do, where, why, for how long, under which context, with whose approval, and with which evidence. Weak identity architecture can bypass segmentation, collapse defense in depth, hide responsibility, and prevent safe recovery.
Limit authority
Give fictional identities only the systems, actions, data, context, and time required for the task.
Preserve accountability
Keep fictional identity, approval, session, action, target, result, and lifecycle evidence.
Support resilience
Design fictional safe degraded service and recovery that do not depend entirely on one identity platform.
Core Model
Identity → Role → Context → Decision → Session → Evidence → Lifecycle → Recovery
Identity
Establish which fictional human, service, device, workload, supplier, automation, or recovery actor exists.
Role
Assign fictional responsibilities and minimum permissions aligned with mission function.
Context
Evaluate fictional time, service, action, device or workload state, approval, and risk conditions.
Decision
Allow, deny, limit, pause, require approval, or use safe fallback for the exact request.
Session
Control fictional start, scope, action, target, rate, evidence, termination, and expiry.
Evidence
Preserve fictional identity, assurance, role, decision, approver, action, target, result, and source health.
Lifecycle
Create, change, review, suspend, recover, and retire fictional identities and access.
Recovery
Restore fictional identity trust with separate authority, proofing, limited privilege, validation, and closure.
Advanced Vocabulary
Language for Identity Architecture
Human identity
A fictional named identity representing a person with defined role, lifecycle, approval, access, evidence, and accountability.
Service identity
A fictional non-human identity used by an application, process, integration, workload, or automation to request approved actions.
Device identity
A fictional identity or assurance signal representing a managed device or platform context involved in an access decision.
Workload identity
A fictional identity assigned to a software workload, service, container, process, or hosted component rather than to a human user.
Privileged identity
A fictional identity with authority to administer, configure, recover, approve, monitor, or change security-critical systems and controls.
Recovery identity
A fictional identity reserved for approved restoration, continuity, or emergency recovery actions and separated from normal production administration.
Authentication
The fictional process of establishing that an identity is who or what it claims to be at an approved assurance level.
Authorization
The fictional decision about whether an authenticated identity may perform a specific action on a specific resource for a specific purpose and context.
Role
A fictional grouping of permissions and responsibilities assigned according to mission function, ownership, and approved need.
Privilege
A fictional permission enabling sensitive, administrative, high-impact, or security-relevant action.
Least privilege
Granting a fictional identity only the minimum permissions, scope, duration, and context required for an approved task.
Separation of duties
Dividing fictional approval, execution, evidence, validation, and recovery responsibilities so one identity cannot control every stage.
Just-in-time access
Fictional privileged access activated only for an approved task and time window rather than remaining continuously available.
Just-enough access
Fictional access limited to the exact systems, actions, data, and context required for the approved task.
Conditional access
A fictional authorization decision using identity, role, device or workload state, location conceptually, time, risk, service, and action context.
Delegation
A fictional arrangement where one identity or service acts with authority granted by another under explicit scope and evidence.
Identity lifecycle
The fictional creation, proofing, activation, change, review, suspension, recovery, and retirement of an identity and its access.
Access review
A fictional evidence-based process confirming that identities, roles, permissions, ownership, purpose, and lifecycle remain appropriate.
Emergency access
Fictional tightly governed access used when normal identity controls are unavailable, with narrow scope, independent approval, evidence, expiration, and review.
Identity evidence
Fictional records showing identity, assurance, role, action, target, decision, approver, result, session, source health, time, and lifecycle state.
Orphaned identity
A fictional account or service identity that remains active without a current owner, mission need, or valid lifecycle state.
Privilege creep
A fictional condition where permissions accumulate over time without removal, review, or continuing mission need.
Identity drift
A fictional mismatch between approved roles, permissions, owners, lifecycle, and the effective access identities actually possess.
Identity Classes
Eight Fictional Identity Types with Different Risk and Lifecycle Needs
Standard user identities
Allow fictional students, staff, analysts, or service users to perform ordinary role-based tasks.
Expected access
Minimum service functions, approved data, and user-level actions.
Core controls
Named identity, approved role, authentication assurance, session limits, access review, and lifecycle.
Required evidence
Identity, role, session, action, target, result, approval where required, and lifecycle state.
Failure pattern
Broad inherited access or stale role membership exposes more services and data than needed.
Privileged administrator identities
Perform fictional approved configuration, support, security, recovery, and system-management tasks.
Expected access
Time-bound, task-specific administration to named systems and actions.
Core controls
Separate privileged identity, approval, just-in-time access, session evidence, change record, rollback, and review.
Required evidence
Administrator, approver, purpose, target, action category, start, end, result, change, and validation.
Failure pattern
One administrator controls identity, data, logs, backups, and recovery without independent oversight.
Application service identities
Allow fictional applications to call approved services and data functions.
Expected access
Specific service actions, narrow data roles, and documented dependencies.
Core controls
Registered service identity, scoped authorization, rotation, owner, health, logging, and recovery.
Required evidence
Calling service, target, action, role, data category, result, configuration version, and owner.
Failure pattern
A long-lived shared credential gives broad service and data access without clear ownership.
Automation identities
Run fictional scheduled, rule-based, or workflow actions under defined authority.
Expected access
Only the actions required by the approved automation playbook.
Core controls
Narrow scope, approval gates, rate limits, versioning, audit, rollback, owner, and disable path.
Required evidence
Automation identity, rule version, trigger, approver when required, action, target, result, and rollback.
Failure pattern
A noisy signal or bad rule scales high-impact action through broad privilege.
Device and workload identities
Represent fictional devices, platforms, services, and hosted workloads in access decisions.
Expected access
Approved connections and actions based on registered identity and current assurance.
Core controls
Registration, attestation conceptually, lifecycle, owner, context, narrow role, health, and evidence.
Required evidence
Identity, owner, workload or device state, service, action, target, result, and lifecycle.
Failure pattern
Network location or hostname alone is treated as proof of trust.
Supplier identities
Provide fictional external support, integration, or service delivery under contract and approved scope.
Expected access
Minimum named systems, interfaces, data, actions, and time windows.
Core controls
Named supplier identity, sponsor, contract purpose, approval, expiration, monitoring, fallback, and exit.
Required evidence
Supplier, sponsor, role, purpose, target, action, result, data category, health, and review.
Failure pattern
Supplier approval becomes permanent broad internal trust.
Emergency and recovery identities
Support fictional continuity and restoration when normal identity services or administrators are unavailable.
Expected access
Narrow recovery actions to approved systems and restore states.
Core controls
Separate custody, independent approval, restricted scope, expiration, evidence, integrity, exercise, and post-use review.
Required evidence
Recovery identity, custodian, approver, purpose, target, restore state, action, result, and closure.
Failure pattern
Emergency access becomes a permanent bypass or depends on the failed identity system.
Break-glass observer identities
Provide fictional limited visibility for authorized decision-makers during identity or logging disruption.
Expected access
Read-only approved status, health, evidence, and recovery information.
Core controls
Separate identity, read-only scope, owner approval, time limit, independent evidence, and closure.
Required evidence
Observer identity, approver, viewed resources, time, result, and expiration.
Failure pattern
Read-only emergency access silently gains administrative or data-export privilege.
Identity Lifecycle
Ten Stages from Request to Retirement
Request and sponsorship
Why does the fictional identity need to exist, which mission function does it support, and who sponsors it?
Requirements
Purpose, identity type, owner, sponsor, requested role, scope, duration, systems, data, and risk.
Evidence
Request record, sponsor, owner, justification, approval path, and requested expiration.
Failure pattern
Identities are created for convenience without clear mission need or owner.
Proofing and registration
How is the fictional identity established and linked to the correct person, service, device, workload, supplier, or recovery role?
Requirements
Approved registration, unique identity, ownership, assurance, service or device context, and no shared secret reuse.
Evidence
Registration record, owner, source, assurance level, and verification result.
Failure pattern
A shared or weakly registered identity cannot be attributed reliably.
Authorization design
Which exact fictional actions, resources, data, services, and time windows are required?
Requirements
Least privilege, role, purpose, separation of duties, conditional context, denial conditions, and owner approval.
Evidence
Role-to-permission matrix, policy decision, data scope, owner approval, and denied-path design.
Failure pattern
Authentication is treated as permission for every action.
Activation
When should the fictional identity or privilege become usable, and under which current conditions?
Requirements
Approved start, time limit, session context, device or workload state, service health, and monitoring.
Evidence
Activation event, approver, start, expiry, role, context, and source health.
Failure pattern
Privilege becomes permanent even though the task is temporary.
Use and session control
How is the fictional identity used safely during normal, privileged, automated, supplier, and recovery activity?
Requirements
Session limits, purpose, target, action scope, rate, approval gates, evidence, and safe termination.
Evidence
Session start, actor, action, target, result, change, approval, errors, and end.
Failure pattern
A valid session performs unrelated or excessive actions without detection.
Change and role transition
How should fictional access change when job, service, owner, supplier, system, project, or risk conditions change?
Requirements
Prompt update, removal before addition where appropriate, role conflict review, new approval, and evidence.
Evidence
Change record, old role, new role, owner, approver, effective date, and removed access.
Failure pattern
Old access remains while new privilege is added, causing privilege creep.
Periodic review
Does the fictional identity still have a current owner, mission need, correct role, appropriate scope, and valid evidence?
Requirements
Owner attestation, actual-use review, role conflicts, stale privilege, service ownership, supplier need, and expiration.
Evidence
Review date, reviewer, decision, removed access, exception, deadline, and closure.
Failure pattern
Reviews confirm access by default without examining use, need, or conflicts.
Suspension and incident handling
How is fictional access limited safely during suspected misuse, owner uncertainty, leave, supplier issue, or system risk?
Requirements
Targeted reversible action, evidence preservation, service impact, approval, communication, and recovery path.
Evidence
Reason, approver, identity, scope, action, result, service effect, and restoration decision.
Failure pattern
Broad disabling causes unnecessary outage or destroys evidence without improving safety.
Recovery
How is fictional identity trust restored after credential loss, platform failure, compromise concern, or continuity event?
Requirements
Independent proofing, separate recovery authority, limited access, rotation, session review, service validation, and closure.
Evidence
Recovery identity, approver, proofing, changed credentials, revoked sessions, validation, and signoff.
Failure pattern
Recovery depends entirely on the failed or untrusted identity path.
Retirement
How is the fictional identity removed when the person, service, supplier, workload, project, or recovery role no longer exists?
Requirements
Disablement, access removal, secret or key rotation conceptually, ownership transfer, data handling, evidence retention, and dependency review.
Evidence
Retirement event, owner, removed permissions, dependency update, replacement identity, and closure.
Failure pattern
Orphaned identities remain active and invisible.
Authorization Dimensions
Eight Questions beyond Authentication
Who
Which fictional human, service, device, workload, supplier, automation, administrator, or recovery identity is acting?
Strong design
Unique registered identity with owner, lifecycle, assurance, and current role.
Weak design
Shared account, generic credential, network location, or unowned service identity.
Required evidence
Identity, owner, type, assurance, role, lifecycle, and source health.
What action
Which exact fictional read, write, approve, configure, restore, export, or administrative action is requested?
Strong design
Narrow action permission linked to mission purpose and target.
Weak design
Broad manage-all or administrator permission.
Required evidence
Requested action, policy decision, result, denied actions, and exception.
Which target
Which fictional resource, service, system, identity, record type, or control is affected?
Strong design
Named target group or resource class with explicit owner.
Weak design
Access to all systems or all data in a broad environment.
Required evidence
Target, owner, classification, service, and result.
For what purpose
Which fictional mission task, support action, service workflow, contract need, or recovery step justifies access?
Strong design
Purpose is documented, current, and linked to an approved workflow.
Weak design
Convenience, possible future use, or general support.
Required evidence
Request, purpose, owner, approval, task, and closure.
Under which context
Which fictional time, device or workload state, service health, risk, location conceptually, and approval conditions apply?
Strong design
Access depends on approved current context and fails safely when context is unreliable.
Weak design
Once authenticated, access works from any context indefinitely.
Required evidence
Session context, assurance, time, device or workload state, approval, and result.
For how long
When should fictional access start, expire, pause, renew, or be reviewed?
Strong design
Time-bound access with explicit activation, expiry, renewal, and removal.
Weak design
Permanent access for a temporary need.
Required evidence
Activation, expiration, renewal, review, and disablement.
With which approval
Who authorizes the fictional access, and is that approver independent from the person executing the action?
Strong design
Named authorized owner and separate approver for high-impact actions.
Weak design
Self-approval or approval by the same identity controlling evidence and recovery.
Required evidence
Approver, authority, decision, time, scope, and conflict review.
With which evidence and recovery
How will fictional use, denial, change, error, emergency access, and closure be reconstructed and reversed?
Strong design
Reliable session, decision, action, change, source-health, rollback, and recovery evidence.
Weak design
Login success is the only recorded event.
Required evidence
Session, policy decision, action, target, result, change, rollback, source health, and signoff.
Role Design
Eight Fictional Roles with Explicit Boundaries
Support analyst
Review fictional user issues and perform approved low-impact support actions.
Allowed
Read approved status, update support records, trigger limited user workflows, and escalate.
Denied
Direct data administration, identity policy change, logging deletion, backup change, and recovery administration.
Approval model
Standard role approval; separate approval for exceptional user-impact actions.
Review model
Quarterly fictional owner review plus actual-use and stale-access checks.
Application operator
Operate fictional application services without controlling identity, data policy, or evidence retention.
Allowed
View service health, restart approved components conceptually, deploy approved changes, and review service logs.
Denied
Broad identity administration, unrestricted data export, logging disablement, and backup deletion.
Approval model
Named owner approval and change record for high-impact actions.
Review model
Role conflict, service ownership, change history, and unused privilege review.
Identity administrator
Manage fictional identity lifecycle, roles, approvals, and recovery under separation of duties.
Allowed
Create, change, suspend, recover, and retire identities through approved workflows.
Denied
Self-approval, unrestricted application administration, evidence deletion, and business risk acceptance.
Approval model
Separate approver for privileged grants, emergency access, and recovery.
Review model
Privileged-session, grant, revocation, recovery, and conflict review.
Data steward
Own fictional data purpose, classification, field scope, access policy, retention, and deletion decisions.
Allowed
Approve data roles, review access, define field scope, and validate lifecycle controls.
Denied
Routine system administration and unilateral evidence deletion.
Approval model
Business and privacy approval for sensitive data changes.
Review model
Data-access use, role need, field scope, retention, and exception review.
Detection engineer
Design fictional visibility and alert logic without broad authority to alter source systems or business access.
Allowed
Manage approved detection content, review evidence, tune rules, and document coverage.
Denied
Unapproved account disabling, unrestricted production administration, and silent retention change.
Approval model
Change approval for high-impact detection or response behavior.
Review model
Rule version, false-positive impact, evidence access, and separation-of-duties review.
Recovery operator
Restore fictional identity, service, data, logging, and configuration from approved states.
Allowed
Use time-bound recovery identity, approved restore states, and defined recovery actions.
Denied
Routine production administration, self-approval, unrestricted backup deletion, and permanent emergency access.
Approval model
Independent recovery owner and mission owner approval.
Review model
Every recovery session plus periodic exercise and custody review.
Supplier support specialist
Perform fictional contract-approved support for a named service.
Allowed
Time-bound access to the minimum approved service interface and diagnostic information.
Denied
Broad internal access, unrelated data, identity administration, logging deletion, and recovery control.
Approval model
Internal sponsor, service owner, and time-limited access approval.
Review model
Per-session evidence, contract scope, sponsor, expiration, and supplier lifecycle review.
Automation service
Perform fictional repeatable low-risk workflow actions under a documented playbook.
Allowed
Specific approved actions with narrow targets, rate limits, and rollback.
Denied
Self-expanding privilege, broad account disabling, role changes, and unreviewed high-impact action.
Approval model
Human approval gate for high-impact steps and versioned rule approval.
Review model
Trigger quality, action volume, failures, rollback, owner, and privilege review.
Identity Failure Modes
Eight Architecture Failures and Defensive Responses
Shared administrator identity
Impact
Fictional actions cannot be attributed reliably, and one credential may control several systems.
Design response
Use named separate privileged identities, approval, session evidence, role separation, and review.
Validation
Every privileged action maps to one named identity, approver, task, session, and result.
Stop condition
Shared privileged use remains necessary without independent accountability.
Stale role membership
Impact
A fictional user retains access after role, project, ownership, or employment changes.
Design response
Use lifecycle triggers, owner review, actual-use evidence, expiration, and prompt removal.
Validation
Old roles and permissions are removed and effective access matches the current job.
Stop condition
No current owner can confirm continuing need.
Broad service identity
Impact
A fictional application or automation can access unrelated services, data, or administration.
Design response
Use unique service identities, narrow roles, owner, rotation, path limits, monitoring, and recovery.
Validation
Approved actions succeed and unrelated actions are denied and recorded.
Stop condition
One service identity remains shared across unrelated workloads.
Identity-provider outage
Impact
Authentication, authorization, approval, administration, evidence attribution, and recovery may fail together.
Design response
Define limited safe degraded service, separate emergency authority, independent evidence, and recovery validation.
Validation
Critical functions continue narrowly while risky access remains blocked and recorded.
Stop condition
No owner can identify who may act safely during the outage.
Emergency-access drift
Impact
A fictional break-glass identity or privilege remains active after the emergency.
Design response
Use separate custody, time limit, post-use review, rotation, closure evidence, and owner signoff.
Validation
Emergency privilege expires, related sessions end, and effective access is rechecked.
Stop condition
Emergency access lacks current owner, expiration, or evidence.
Supplier identity overreach
Impact
A fictional external identity reaches systems, data, or actions beyond contract purpose.
Design response
Use named identities, sponsor, narrow scope, time limits, session evidence, fallback, and exit review.
Validation
Only approved supplier targets and actions remain reachable.
Stop condition
Supplier access cannot be linked to a current sponsor or mission need.
Privilege concentration
Impact
One fictional identity can approve, execute, alter evidence, change recovery, and accept risk.
Design response
Separate duties, approvals, evidence ownership, recovery authority, and risk acceptance.
Validation
No single identity controls every stage of a high-impact action.
Stop condition
The same identity can change systems and remove all proof.
Orphaned identity
Impact
A fictional account or service continues operating without current owner or lifecycle review.
Design response
Use ownership checks, automatic expiration conceptually, dependency review, disablement, and replacement planning.
Validation
Every active identity has current owner, purpose, role, lifecycle, and recent review.
Stop condition
The identity is active but no owner accepts responsibility.
Professional Workflow
Ten Steps from Identity Inventory to Governance
1
Inventory fictional identities
Which human, service, device, workload, administrator, supplier, automation, emergency, and recovery identities exist?
Required output
Identity inventory with type, owner, purpose, lifecycle, systems, and data.
Stop condition
Do not design access while important identities remain shared, generic, or unowned.
2
Map mission tasks and authority
Which fictional identities must perform which exact actions on which targets for which mission purpose?
Required output
Task, action, target, purpose, and owner map.
Stop condition
Reject access justified only by convenience or possible future need.
3
Design roles and permissions
Which fictional permissions belong together, which must remain separate, and what should be denied explicitly?
Required output
Role-to-permission and denied-action matrix.
Stop condition
Pause if one role crosses conflicting duties or unrelated systems.
4
Add context and approval
Which fictional time, device or workload state, service health, location conceptually, approval, session, and risk conditions apply?
Required output
Conditional-access and approval design.
Stop condition
Do not treat authentication alone as authorization.
5
Design privilege activation and use
How should fictional privileged, supplier, automation, and recovery access start, operate, expire, and leave evidence?
Required output
Just-in-time, just-enough, session, and evidence plan.
Stop condition
Do not leave temporary high-impact access permanently active.
6
Map lifecycle and review
How are fictional identities created, changed, reviewed, suspended, recovered, and retired?
Required output
Identity lifecycle and access-review workflow.
Stop condition
Pause if role or ownership changes do not remove old privilege.
7
Analyze failure and recovery
What happens when fictional identity, approval, logging, supplier, automation, administrator, or recovery controls fail?
Required output
Identity failure-state, degraded-mode, and recovery matrix.
Stop condition
Do not allow uncontrolled fail-open access or unnecessary total outage.
8
Design evidence and source health
Which fictional records prove identity, role, context, decision, approver, action, target, result, session, lifecycle, and closure?
Required output
Identity evidence and source-health coverage map.
Stop condition
Do not approve access that cannot be attributed or reconstructed.
9
Validate effective access
Do fictional actual permissions, roles, sessions, service identities, exceptions, and lifecycle states match the approved design?
Required output
Effective-access validation and identity-drift review.
Stop condition
Do not treat role documentation or policy as proof of current access.
10
Govern change and residual risk
How are fictional new roles, suppliers, services, exceptions, emergency use, orphaned identities, conflicts, and risk decisions reviewed?
Required output
Identity governance, exception, corrective-action, and risk plan.
Stop condition
Do not accept unowned identities or unresolved privilege concentration.
Identity Ownership
Ten Owners for Access, Evidence, Recovery, and Risk
Mission owner
Owns
Fictional critical tasks, user outcomes, acceptable disruption, business priority, and residual business risk.
Primary decision
Which identity capabilities are truly required for the mission.
Required evidence
Mission-task map, service priority, disruption limits, and risk acceptance.
Identity architect
Owns
Fictional identity classes, trust, roles, lifecycle, conditional access, privilege, evidence, and recovery design.
Primary decision
Whether identity architecture is least-privileged, resilient, attributable, and governed.
Required evidence
Identity model, role matrix, lifecycle, failure analysis, decisions, and validation plan.
Identity operations owner
Owns
Fictional identity creation, change, activation, suspension, recovery, retirement, source health, and operational evidence.
Primary decision
Whether approved identity changes are implemented and supportable.
Required evidence
Requests, approvals, change records, activation, disablement, recovery, and closure.
System and service owner
Owns
Fictional service functions, required actions, dependencies, service identities, continuity, and target authorization.
Primary decision
Which identities and actions the service requires.
Required evidence
Service map, action catalog, dependency review, access tests, health, and rollback.
Data and privacy owner
Owns
Fictional data purpose, categories, fields, access, sharing, retention, deletion, and privacy effects.
Primary decision
Which identities may access which data for which purpose.
Required evidence
Data inventory, field scope, role approval, access review, retention, deletion, and restore checks.
Privileged-access owner
Owns
Fictional administrative roles, approval, just-in-time access, sessions, emergency use, evidence, and review.
Primary decision
Which high-impact actions require privilege and how duties remain separated.
Required evidence
Privilege requests, approvals, sessions, actions, changes, expiration, and review.
Detection and evidence owner
Owns
Fictional identity logs, policy decisions, source health, time quality, session evidence, access, retention, alerts, and case linkage.
Primary decision
Whether identity use, denial, drift, misuse concern, failure, and recovery can be reconstructed.
Required evidence
Coverage map, sample events, source-health checks, access review, and retention.
Recovery owner
Owns
Fictional recovery identities, custody, restore authority, emergency access, exercises, closure, and service validation.
Primary decision
Whether identity trust can be restored without depending entirely on the failed identity system.
Required evidence
Recovery map, custodian records, exercise, proofing, rotation, service checks, and signoff.
Supplier sponsor
Owns
Fictional supplier identities, purpose, contract scope, systems, data, approval, expiration, monitoring, fallback, and exit.
Primary decision
Which supplier access remains necessary and acceptable.
Required evidence
Supplier register, sponsor, sessions, actions, data scope, expiration, and review.
Governance and risk owner
Owns
Fictional access exceptions, role conflicts, identity drift, orphaned identities, corrective actions, residual risk, and final acceptance.
Primary decision
Whether remaining identity risks are accepted, reduced, transferred, avoided, or monitored.
Required evidence
Decision records, exception register, deadlines, owner signoff, corrective evidence, and closure.
Fake Dashboard
Fake Northbridge Identity Architecture Dashboard
Fictional identity, role, privilege, lifecycle, evidence, supplier, emergency, and recovery review for training only.
Active identities
146
Fictional human, service, supplier, automation, administrator, and recovery identities are included.
Identity concerns
8
Orphaned services, privilege concentration, stale roles, shared credentials, supplier drift, and emergency-access closure require review.
Current status
High Risk
Effective fictional access exceeds approved role, lifecycle, and separation-of-duties expectations.
Fake SOC Alert
Privilege Concentration and Lifecycle Drift Weaken Identity Architecture
Source: Fake Northbridge Identity Governance Console • Time: 6:08 PM
One fictional support role reaches application, data, identity, logging, backup, and recovery functions. Four service identities have no owner, three applications share one broad credential, supplier access remains active after expiration, and a break-glass identity remains enabled.
Defensive recommendation: Pause high-risk grants, preserve evidence, assign owners, split roles, create unique service identities, remove stale access, close supplier and emergency privileges, design safe degraded operation, and validate effective access.
Fake Log Panel
Fake Identity Architecture Review Timeline
training-log-viewer.log
17:00 INVENTORY active-identities='146' 17:05 SERVICE owner-missing='4' 17:10 ROLE support-broad='app,data,id,logs,backup,recovery' 17:20 REVIEW stale-role-memberships='12' 17:30 SERVICE shared-credential='3-apps' 17:40 PRIVILEGE self-approval='enabled' 17:41 EVIDENCE retention-owner='same-admin' 17:50 SUPPLIER access-expired='still-active' 17:55 OUTAGE approval-dependency='same-idp' 17:56 OUTAGE recovery-dependency='same-idp' 18:00 EMERGENCY break-glass='enabled-10-days' 18:02 CLOSURE post-use-review='missing' 18:04 RISK privilege-concentration='confirmed' 18:05 RISK lifecycle-drift='confirmed' 18:06 DECISION high-risk-grants='paused' 18:08 STATUS redesign='required'
Training note: this is fake data for defensive analysis practice only.
Fictional Evidence Matrix
Evidence before Approving the Identity Architecture
IAM-01
Fictional identity inventory
Observation
Human, service, supplier, automation, administrator, and recovery identities are listed, but four service identities have no current owner.
Supports
Orphaned or weakly governed service identities may exist.
Does not prove
Does not prove the identities are misused or unnecessary.
Design use
Confirm purpose, owner, dependencies, permissions, lifecycle, and replacement or retirement.
IAM-02
Fictional role matrix
Observation
One support role includes application, data, identity, logging, backup, and recovery permissions.
Supports
Privilege concentration and role conflict may weaken separation of duties.
Does not prove
Does not prove misuse.
Design use
Split duties, reduce scope, require temporary privilege, and add independent approval and evidence.
IAM-03
Fictional access review
Observation
Twelve users retain permissions from previous roles or completed projects.
Supports
Privilege creep and lifecycle drift exist.
Does not prove
Does not prove every retained permission is inappropriate.
Design use
Validate current role, actual use, owner need, conflicts, expiration, and removal.
IAM-04
Fictional service-identity record
Observation
Three applications share one long-lived credential with broad data access.
Supports
Attribution, least privilege, rotation, and blast-radius controls are weak.
Does not prove
Does not prove the credential has been exposed.
Design use
Create unique identities, narrow roles, owners, path limits, monitoring, and recovery.
IAM-05
Fictional privileged-session map
Observation
Identity administrators can approve their own privileged access and alter related evidence retention.
Supports
Separation of duties and independent evidence are insufficient.
Does not prove
Does not prove improper action occurred.
Design use
Separate approval, evidence ownership, retention authority, and risk acceptance.
IAM-06
Fictional supplier-access record
Observation
A supplier identity remains active after the contract support window ended.
Supports
Supplier lifecycle and expiration controls failed.
Does not prove
Does not prove the identity was used after expiration.
Design use
Suspend access, preserve evidence, confirm sponsor and need, then remove or formally reapprove.
IAM-07
Fictional identity-outage exercise
Observation
Critical support cannot continue because approval and recovery access depend on the failed identity platform.
Supports
Identity architecture lacks safe degraded operation and independent recovery authority.
Does not prove
Does not prove broad fail-open access would be safe.
Design use
Design limited fallback, separate recovery identity, independent evidence, and restoration validation.
IAM-08
Fictional emergency-access review
Observation
A break-glass identity remains enabled ten days after use, with no post-use rotation or owner signoff.
Supports
Emergency-access closure and review are incomplete.
Does not prove
Does not prove the identity was used improperly.
Design use
Expire access, rotate recovery material conceptually, review sessions, validate effective state, and close with owner signoff.
Analyze the Evidence
Should the Fictional Identity Architecture Be Approved?
Four service identities have no current owner.
One support role includes application, data, identity, logging, backup, and recovery permissions.
Twelve users retain access from previous roles or completed projects.
Three applications share one long-lived credential with broad data access.
Identity administrators can approve their own privilege and alter related evidence retention.
A supplier identity remains active after its support window ended.
Critical support and recovery depend on the same identity platform.
A break-glass identity remains enabled ten days after use.
Should the current fictional Northbridge identity architecture be approved?
Common Identity Mistakes
What Advanced Defenders Must Avoid
Treating fictional identity as a username and password problem rather than architecture spanning purpose, role, privilege, lifecycle, context, evidence, failure, and recovery.
Assuming successful authentication authorizes every action, target, data set, or service.
Using shared administrator, service, supplier, automation, or recovery identities.
Assigning broad roles for convenience instead of task-specific permissions.
Allowing one fictional identity to approve, execute, alter evidence, recover, and accept risk.
Leaving temporary privilege, supplier access, emergency access, or project access active indefinitely.
Creating fictional service identities without current owner, lifecycle, narrow role, path scope, monitoring, and recovery.
Failing to remove old permissions during role, project, supplier, or ownership changes.
Performing access reviews as simple confirmation rather than examining actual use, conflicts, owner need, stale privilege, and exceptions.
Using network location, device name, or internal status as proof of identity or authorization.
Designing broad fail-open access during identity outages.
Designing total fail-closed behavior without limited safe degraded service and independent recovery.
Logging only authentication while omitting policy decisions, approvals, privileged actions, session changes, lifecycle events, and closure.
Allowing emergency or recovery access to depend entirely on the failed identity system.
Using real usernames, directories, role names, permissions, system names, logs, supplier details, or recovery identities in a portfolio artifact.
Safe Practice Lab
Build a Fictional Identity-Centered Architecture
Fictional assignment
Redesign the Northbridge Identity Model
Use only the invented evidence on this page. Do not upload, copy, quote, lightly modify, summarize, or reproduce real usernames, directories, identity systems, roles, permissions, service credentials, privileged sessions, logs, supplier identities, or recovery details.
Required deliverables
- Fictional identity inventory by human, service, device, workload, supplier, automation, administrator, emergency, and recovery type.
- Mission-task, action, target, purpose, and owner map.
- Role-to-permission and explicitly denied-action matrix.
- Conditional-access, approval, just-in-time, and just-enough design.
- Identity lifecycle from request through retirement.
- Separation-of-duties and privilege-concentration review.
- Service, supplier, automation, emergency, and recovery identity design.
- Identity evidence and source-health coverage.
- Failure-state, degraded-service, recovery, and effective-access validation.
- Reflection, revision history, and complete fictionalization statement.
This activity creates a fictional educational design only. It does not authorize access, account creation, privilege change, recovery, testing, investigation, or collection involving any real system.
Scenario Decision Lab
A Support Role Has Cross-System Privilege
A fictional support role includes application, data, identity, logging, backup, and recovery permissions. The role exists for convenience, and current task evidence shows most users need only application support.
Scenario Decision Lab
The Identity Platform Is Unavailable
The fictional identity platform provides authentication, authorization, approvals, administrator access, and recovery access. It fails during a critical support period.
Advanced Challenge
Design Identity Resilience without Permanent Bypass
Extend the fictional Northbridge architecture for a combined identity-platform and logging failure. A critical support function must continue, a supplier is assisting, and recovery requires privileged access. Design separate human, supplier, recovery, and observer identities with narrow authority, independent approval, minimum data, time limits, source-health awareness, evidence, restoration, revocation, and post-use validation.
Required architecture
Show fictional identity classes, roles, denied actions, approvals, contexts, session limits, independent evidence, recovery custody, and expiry.
Required validation
Explain how the design preserves critical service, prevents privilege concentration, restores normal identity trust, removes temporary access, and proves closure.
Defender Habits
Identity-Centered Architecture Checklist
Check Your Understanding
A2.5 Mini Quiz: Identity-Centered Architecture
Choose your answers first. Explanations appear only after submission.
1. What best describes identity-centered architecture?
2. What is the difference between authentication and authorization?
3. Three fictional applications share one broad service credential. What is the strongest concern?
4. Which design best supports separation of duties for a privileged fictional action?
5. A fictional identity platform fails. What is the strongest architecture response?
6. What should happen after a fictional break-glass identity is used?
7. What makes an A2.5 portfolio artifact safe to share?
Portfolio Prompt
Portfolio Prompt
Create a fully fictional Identity-Centered Architecture Package for Northbridge. Include the identity inventory, identity classes, mission-task map, role-to-permission matrix, denied actions, conditional access, just-in-time and just-enough privilege, separation of duties, lifecycle workflow, access-review design, service identities, automation identities, supplier identities, privileged identities, emergency and recovery identities, observer access, identity evidence, source health, failure-state decisions, safe degraded mode, recovery design, effective-access validation, identity drift, orphaned identities, exceptions, residual risk, reflection, revision history, and a statement that every organization, identity, role, permission, system, evidence item, exception, decision, date, and outcome is invented.
Separate fictional authentication from authorization for every important action.
Give each fictional human, service, supplier, automation, and recovery identity a current owner, purpose, role, lifecycle, and evidence plan.
Include at least one privilege-concentration or stale-access problem and redesign it.
Show how fictional emergency access activates, operates, expires, rotates conceptually, closes, and receives owner validation.
Keep every identity, role, permission, system, supplier, session, evidence item, exception, decision, and outcome completely invented.
Confidence / Readiness Reflection
Are You Ready to Design Logging and Visibility by Design?
Before moving to A2.6, rate your readiness from 1 to 5 for each area: identity classes, authentication, authorization, role design, privilege, context, approval, lifecycle, access review, service identities, supplier identities, emergency access, evidence, recovery, and effective-access validation.
I can explain why a fictional valid login does not authorize every action.
I can design fictional human, service, supplier, automation, privileged, emergency, and recovery identities differently.
I can separate fictional approval, execution, evidence, validation, recovery, and risk ownership.
I can identify fictional stale access, privilege creep, orphaned identities, shared credentials, supplier drift, and emergency-access drift.
I can validate fictional effective roles, permissions, sessions, lifecycle, source health, and closure.
I can keep the entire identity architecture portfolio fully invented and safe to share.
Record one fictional role you would narrow, one identity lifecycle failure you would correct first, and one evidence question you will carry into A2.6.
Key Takeaways
What You Should Remember
1.Identity-centered architecture covers human, service, device, workload, supplier, automation, privileged, emergency, observer, and recovery identities.
2.Authentication establishes identity; authorization decides whether that identity may perform a specific action on a specific target under current conditions.
3.Least privilege limits fictional systems, actions, data, scope, context, duration, and authority.
4.Separation of duties divides fictional approval, execution, evidence, validation, recovery, and risk acceptance.
5.Service and automation identities need unique ownership, narrow roles, path limits, lifecycle, monitoring, and recovery.
6.Identity lifecycle includes request, proofing, authorization, activation, use, change, review, suspension, recovery, and retirement.
7.Access reviews should examine fictional current need, actual use, role conflicts, stale privilege, owner status, exceptions, and removal.
8.Identity outages require limited safe degraded service, separate emergency authority, independent evidence, validated recovery, and strict closure.
9.Effective-access validation compares fictional approved roles and policy with actual permissions, sessions, identities, exceptions, and lifecycle states.
10.Every CyberShield identity-architecture artifact must remain fully fictional, defensive, non-operational, privacy-safe, and incapable of exposing real systems.
Navigation