Lesson A13.1
Modern applications are distributed across cloud services, APIs, devices, networks, partners, and workloads. In that environment, identity can become one of the most important boundaries for deciding who or what may reach protected resources.
This lesson uses fictional identity records and synthetic access evidence only. It does not involve real credentials, accounts, authentication testing, or private identity systems.
Lesson Progress
High School Advanced • A13: Identity, Zero Trust, and Access Control • Lesson 1 of 10
Readiness Check
0/4 ready
Professional Hook
A counselor signing in to a web application, a workload reading a database, an administrator changing cloud policy, and a partner managing an integration can all reach important resources through different paths. The strongest common question is not simply “Which network are they on?” It is “Who or what is this identity, why does it need access, and what exactly should it be allowed to do?”
Identity becomes a perimeter when access follows verified purpose, privilege, scope, lifecycle, and evidence.
Learning Objectives
Explain why identity can function as a security perimeter across human users, administrators, workloads, applications, external parties, and temporary operators.
Distinguish authentication, authorization, identity ownership, resource ownership, trust relationships, and access paths as separate architecture concerns.
Evaluate fictional identity records using purpose, privilege, resource scope, approval, environment, lifecycle, evidence freshness, and monitoring.
Identify identity-perimeter risks such as shared identities, unowned accounts, stale external access, permanent privilege, cross-environment access, and missing workload ownership.
Build an Identity Perimeter Map that becomes the first artifact in the A13 Enterprise Identity and Zero-Trust Review.
Identity Types
Represents an employee, student worker, contractor, or other approved human user who needs access to business applications and services.
Perimeter effect
A workforce identity becomes a security boundary when authentication strength, role, lifecycle, session context, and approved resources influence access.
Useful evidence
Identity source, employment or sponsorship state, role, authentication evidence, access review, owner, and last lifecycle confirmation.
Represents administrative capability that can change identities, policies, applications, infrastructure, data, logging, or other security-sensitive state.
Perimeter effect
Privilege creates a higher-impact identity boundary because one action can change the architecture itself.
Useful evidence
Privileged role purpose, approval, time window, activation record, owner, session evidence, and post-use review.
Represents an application, service, job, function, or automation process that needs to authenticate to another service.
Perimeter effect
Workload identity lets the architecture authorize a named non-human principal instead of trusting network location or copied credentials.
Useful evidence
Workload owner, service purpose, environment, resource scope, identity binding, deployment relationship, and service-access logs.
Represents a partner, vendor, guest, consultant, or other party outside the organization's normal workforce identity lifecycle.
Perimeter effect
External identity crosses an organizational trust boundary and therefore needs sponsorship, bounded access, review, and expiration.
Useful evidence
Sponsor, business reason, allowed resources, expiration, review cadence, federation or guest relationship, and activity evidence.
Represents short-duration access for migration, recovery, support, audit, or another bounded operational need.
Perimeter effect
Time becomes part of the security boundary because access should stop when the task ends.
Useful evidence
Request, approver, start time, expiration, exact resource scope, owner, use evidence, and closure review.
Represents older automated or application access that may not use modern workload identity.
Perimeter effect
Long-lived or shared credentials can create hidden identity boundaries when ownership, lifecycle, and access purpose are unclear.
Useful evidence
Current owner, business need, credential lifecycle metadata, allowed resources, monitoring, rotation, revocation, and retirement plan.
Perimeter Dimensions
Core question: Who or what is acting?
Evidence: Stable identity record, identity type, source, sponsor, workload binding, or privileged role.
Core question: How is the identity verified?
Evidence: Authentication method or federation context recorded as safe metadata.
Core question: What exact resource and action can the identity access?
Evidence: Role, entitlement, policy decision, resource scope, action scope, and environment.
Core question: Why does this access exist?
Evidence: Business need, application dependency, support requirement, operational responsibility, or approved workflow.
Core question: Who is accountable for the identity and the resource?
Evidence: Identity owner, sponsor, service owner, resource owner, or platform owner.
Core question: When should access change or end?
Evidence: Review date, expiration, employment change, service retirement, project end, or temporary-access closure.
Core question: Which environment, application, role, or session conditions matter?
Evidence: Production vs. staging, privileged vs. standard use, application sensitivity, device or session policy metadata.
Core question: What proves the architecture claim is still current?
Evidence: Access review, authentication events, workload activity, policy history, owner confirmation, and source health.
Identity Principles
Important access should be tied to a specific human, workload, service, or external principal rather than a vague shared identity.
Review: Can the reviewer tell who or what performed the action?
Verifying an identity does not automatically grant permission to every reachable resource.
Review: Does the architecture separately define what the identity may actually do?
Administrative identities deserve stronger controls because they can modify security boundaries for many other identities.
Review: Is privileged access separated, bounded, monitored, and reviewed?
Applications and services should not rely only on private network placement or embedded shared credentials.
Review: Does each important workload authenticate as an approved non-human principal?
A partner or guest relationship should remain tied to a current business owner and explicit need.
Review: Who sponsors the identity and when does access expire or get reviewed?
Development, test, staging, and production access should not be treated as interchangeable.
Review: Can lower-environment identities reach production resources?
Access that was appropriate last year may no longer be appropriate after role, project, service, or ownership changes.
Review: What event or date should reduce, revoke, or retire the access?
A current access claim should be supported by current identity, policy, activity, and ownership evidence.
Review: Is the evidence fresh enough to support the present architecture?
Vocabulary
The set of identity, authentication, authorization, ownership, lifecycle, and contextual decisions that determine who or what can reach protected resources.
A human or non-human identity that can request or receive access to a resource.
The process of verifying the claimed identity of a user, workload, service, or other principal.
The decision about which resources and actions an authenticated identity is allowed to use.
A specific permission, role membership, resource access, or capability assigned to an identity.
A non-human identity representing an application, service, job, or automation process.
An identity with elevated administrative or security-sensitive capabilities.
An identity belonging to a partner, vendor, guest, consultant, or other party outside the normal workforce lifecycle.
The creation, activation, change, review, suspension, revocation, and retirement of identity access over time.
The internal person or team accountable for an external identity's business need and continued access.
Elevated access that remains continuously available rather than being activated for a limited approved period.
The identity-to-resource relationship through which a principal can request or receive an action on a protected service or data resource.
Fictional Identity Register
Purpose
Use Student Services Portal for approved student-support workflows
Resources
Student Services Portal
Actions
Application workflows allowed by counselor role
Environment
Production
Owner
Student Services Operations
Approval
Role-based workforce assignment
Lifecycle
Reviewed quarterly and on employment/role change
Monitoring
Authentication + application authorization events
Architecture concern
Access remains appropriate only while the user has a current counselor role.
Purpose
Perform approved platform administration
Resources
Cloud management plane
Actions
Time-bounded administrative changes
Environment
Production
Owner
Platform Engineering
Approval
Privileged activation workflow
Lifecycle
Just-in-time activation; post-use review required
Monitoring
Privileged activation + management audit
Architecture concern
One emergency activation has incomplete post-use review evidence.
Purpose
Authenticate application service to approved backend resources
Resources
Student Support Database + Generated Report Storage
Actions
Application-specific read/write operations
Environment
Production
Owner
Application Team
Approval
Application architecture approval
Lifecycle
Reviewed on deployment and dependency change
Monitoring
Workload authentication + resource access logs
Architecture concern
Network privacy is not treated as a substitute for workload identity.
Purpose
Support approved scheduling integration administration
Resources
Scheduling Integration Service
Actions
Narrow integration support functions
Environment
Production
Owner
Integration Owner
Approval
Sponsor + partner-access approval
Lifecycle
Expires in 30 days unless renewed
Monitoring
External sign-in + integration administration events
Architecture concern
Sponsor is current, but renewal decision is due soon.
Purpose
Historical scheduled reporting job
Resources
Generated Report Storage + scheduling metadata
Actions
Legacy report generation
Environment
Production
Owner
Unknown
Approval
Historical / not current
Lifecycle
No current review date
Monitoring
Partial
Architecture concern
Current owner, business need, rotation, revocation, and retirement path are unresolved.
Purpose
Process synthetic staging analytics data
Resources
Staging Analytics Dataset
Actions
Staging analytics processing
Environment
Staging
Owner
Analytics Team
Approval
Staging deployment approval
Lifecycle
Reviewed on deployment
Monitoring
Workload + dataset access events
Architecture concern
Production data and production resources are explicitly out of scope.
Purpose
Support approved data migration validation
Resources
Migration control service
Actions
Migration-specific operational actions
Environment
Production
Owner
Migration Project Owner
Approval
Time-bounded migration approval
Lifecycle
Expires at project checkpoint
Monitoring
Activation + migration-control audit
Architecture concern
Access should be revoked immediately when the project checkpoint closes.
Fake Dashboard
Fictional identity ownership, lifecycle, and evidence summary
Identity records reviewed
7
Workforce, privileged, workload, external, legacy, staging, and temporary identities
Confirmed identities
3
Counselor workforce, production workload, and staging workload have current evidence
Conditional identities
3
Privileged review, partner renewal, and temporary migration closure require follow-up
Blocked identities
1
Legacy Reporting Account has no current owner or lifecycle evidence
Fake SOC Alert
Source: Fictional Identity Governance Review • Time: 09:54
Access Paths
An identity inventory tells you what identities exist. An access path explains what each identity can reach and why. This relationship is what turns identity into an architecture boundary.
Source identity
Counselor Workforce Group
Destination
Student Services Portal
Access decision
Allow role-appropriate application workflows after approved workforce authentication.
Trust change
Workforce identity becomes application authorization context.
Owner
Application Owner
Evidence
Authentication events + counselor-role authorization records.
Source identity
Student Portal Workload
Destination
Student Support Database
Access decision
Allow application-specific database actions through workload identity.
Trust change
Application service becomes a named non-human principal.
Owner
Application + Data Platform
Evidence
Workload identity binding + database access telemetry.
Source identity
Cloud Platform Administrator
Destination
Cloud Management Plane
Access decision
Allow approved administrative changes during time-bounded privileged activation.
Trust change
Normal workforce identity enters privileged administrative context.
Owner
Platform Engineering
Evidence
Activation approval + management audit + post-use review.
Source identity
Scheduling Partner Guest
Destination
Scheduling Integration Service
Access decision
Allow only partner-support functions tied to sponsor and current review.
Trust change
External identity crosses organizational boundary into narrow application scope.
Owner
Integration Owner
Evidence
Sponsor record + external sign-in + integration audit.
Source identity
Analytics Staging Workload
Destination
Production Student Support Database
Access decision
Deny because staging workload has no production purpose or approval.
Trust change
Environment boundary prevents lower-environment identity from production data access.
Owner
Analytics + Data Platform
Evidence
Environment policy + identity scope + access decision record.
Source identity
Legacy Reporting Account
Destination
Generated Report Storage
Access decision
Blocked pending ownership and lifecycle resolution.
Trust change
Legacy service identity lacks current accountability.
Owner
Unknown
Evidence
Legacy access record + incomplete lifecycle evidence.
Fake Log Panel
[08:12] IDN-01 counselor-workforce owner=StudentServices review=CURRENT state=CONFIRMED [08:39] IDN-02 platform-admin access=JIT post_review=PARTIAL state=CONDITIONAL [09:03] IDN-03 student-portal-workload env=PROD scope=DB+REPORT state=CONFIRMED [09:28] IDN-04 scheduling-partner sponsor=CURRENT renewal_due=30d state=CONDITIONAL [09:54] IDN-05 legacy-reporting owner=UNKNOWN lifecycle=STALE state=BLOCKED [10:17] IDN-06 analytics-staging prod_scope=NONE state=CONFIRMED [10:41] IDN-07 migration-operator expires=PROJECT_CHECKPOINT state=CONDITIONAL
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Identity Anti-Patterns
Why it fails: Multiple people act through one identity, weakening accountability and making lifecycle decisions difficult.
Better approach: Use named identities with separate privileged activation.
Why it fails: A workload is authorized only because it runs on an internal or private network.
Better approach: Use named workload identity plus resource-level authorization.
Why it fails: No internal owner remains accountable for why the external identity still has access.
Better approach: Require sponsor, business purpose, expiration, and recurring review.
Why it fails: Administrative capability remains available even when the user is not performing an approved privileged task.
Better approach: Use separate, time-bounded, monitored privileged access.
Why it fails: Environment boundaries weaken and lower-trust workflows gain production access relationships.
Better approach: Use environment-specific identities and resource scope.
Why it fails: The organization cannot confidently decide whether access is still required, safe, or revocable.
Better approach: Resolve business need and ownership, modernize the identity, or retire the account.
Why it fails: A successful sign-in is treated as permission to reach every available resource.
Better approach: Separate authentication from resource-specific authorization.
Why it fails: A reviewer approves access because the entitlement name looks familiar without checking purpose, resource, privilege, lifecycle, or evidence.
Better approach: Review why access exists and what it actually allows.
Authentication vs. Authorization
Authentication establishes identity context. It may rely on workforce identity, workload identity, federation, or another approved mechanism.
Authorization uses identity and policy context to decide which resources, actions, and environments are permitted.
Scenario Decision Lab
A production reporting account still works, but no current owner, approval record, lifecycle review, or clear retirement plan exists.
Scenario Decision Lab
The Analytics Staging Workload needs synthetic staging data, but a developer proposes granting permanent read-only access to the production student-support database for convenience.
Safe Fictional Lab
Use fictional identities, resources, approvals, owners, policies, and synthetic evidence only. Do not access or inspect any real identity platform.
Create at least twelve fictional identity records.
Include workforce, privileged, workload, external, temporary, and legacy identity types.
Give every identity a stable ID.
State the identity purpose.
Record environment.
Record the resource or application being accessed.
Record allowed action scope.
Assign identity owner or sponsor.
Assign resource owner.
Record approval path.
Record review cadence or expiration.
Record monitoring evidence.
Classify status as Confirmed, Conditional, Unknown, Blocked, or Retired.
Create at least ten identity-to-resource access paths.
Identify at least two environment-boundary decisions.
Identify at least two privileged-access relationships.
Identify at least two workload identities.
Identify at least two external or temporary identities.
Identify one unowned legacy identity and keep it Blocked.
Add change triggers for role change, employment change, project end, service retirement, provider change, ownership change, and architecture change.
Lab boundary
Use fictional names, safe metadata, and synthetic evidence only. Do not use real usernames, passwords, tokens, private account identifiers, internal identity exports, or production access details.
Analyze the Evidence
Advanced Challenge
A fictional organization has shared admin accounts, two legacy service identities, permanent vendor access, one staging workload that can reach production, and weak access-review evidence. Redesign the identity perimeter conceptually.
Named workforce identities
Separate privileged identities or privileged activation
Workload identities for applications
Environment-specific workload scope
External sponsor requirements
External expiration and review
Temporary access lifecycle
Legacy identity modernization or retirement
Resource-specific authorization
Identity and resource ownership
Authentication evidence
Authorization evidence
Monitoring coverage
Review cadence
Change triggers
Blocked findings that must close before approval
Defender Habits
Skill Check
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create the first artifact for your A13 Enterprise Identity and Zero-Trust Review: a fictional Identity Perimeter Map with at least twelve identities and ten access paths. Include identity ID, type, purpose, environment, resource, action scope, identity owner or sponsor, resource owner, approval, lifecycle, monitoring evidence, status, concern, next action, and change trigger.
Confidence / Readiness Reflection
A13.2 moves into Zero Trust Principles. Before continuing, make sure you can explain why identity reduces assumed trust but does not eliminate the need for resource authorization, monitoring, lifecycle, and architecture evidence.
I can explain identity as a security perimeter.
I can distinguish authentication from authorization.
I can distinguish workforce, privileged, workload, external, temporary, and legacy identities.
I can evaluate identity access by purpose, scope, environment, owner, lifecycle, and evidence.
I can explain why private network placement does not replace identity or authorization.
Portfolio Build Guide
Make every human, workload, external, temporary, and legacy record easy to reference later in A13.
Identity records explain who or what exists; path records explain which resource/action relationship exists.
Include both identity owner/sponsor and resource owner when those responsibilities differ.
Access should have review dates, expirations, project triggers, role-change triggers, or retirement conditions.
Make production, staging, development, and recovery scope visible.
Authentication, authorization, access review, workload activity, and monitoring should support each major claim.
Use Conditional, Unknown, or Blocked when current evidence does not justify Confirmed.
A13.2 will use this map to identify where trust is explicit, assumed, excessive, or insufficiently verified.
Key Takeaways
Lesson Safety Boundary
Do not guess passwords, test authentication, enumerate users, access real identity platforms, use tokens, attempt privilege escalation, or inspect private account data. All identities, access paths, approvals, logs, and evidence in this lesson are fictional and defensive.
Lesson Complete
You now have an identity-perimeter model built around principal type, authentication, authorization, purpose, privilege, ownership, environment, lifecycle, access paths, and current evidence. Next, A13.2 focuses on Zero Trust Principles.