Lesson A13.2
Zero trust is not a product, a firewall setting, or a command to deny everything. It is an architecture strategy for reducing assumed trust and making access decisions more explicit, least-privileged, observable, and reviewable.
This lesson uses fictional identities, synthetic policy decisions, and safe evidence only. It does not involve real accounts, authentication testing, bypass attempts, or credential use.
Lesson Progress
High School Advanced • A13: Identity, Zero Trust, and Access Control • Lesson 2 of 10
Readiness Check
0/4 ready
Professional Hook
Imagine a counselor, an administrator, a production workload, and a partner all successfully authenticate. A weak design might treat that one fact as enough. A zero-trust design asks a deeper set of questions: Which resource is being requested? Which action? Which environment? How much privilege? For how long? What current evidence supports the decision?
Zero trust reduces assumptions by making trust decisions explicit.
Learning Objectives
Explain zero trust as an architecture strategy that reduces assumed trust through explicit verification, least privilege, bounded access, continuous evidence, and policy-aware decisions.
Distinguish identity verification, resource authorization, contextual access, segmentation, session evaluation, monitoring, and lifecycle review as related but separate zero-trust capabilities.
Evaluate fictional access relationships for excessive standing trust, missing context, weak ownership, stale evidence, overbroad access, and unreviewed exceptions.
Connect zero-trust principles to human identity, workload identity, privileged access, device and session context, application sensitivity, monitoring, and governance.
Build a Zero Trust Principles Assessment that becomes the second artifact in the A13 Enterprise Identity and Zero-Trust Review.
Core Principles
Access decisions should use relevant identity and policy evidence rather than assuming trust because the user or workload is already inside a network or organization.
Architecture question
What evidence supports the identity, resource, action, environment, and current access decision?
Evidence
Authentication context, workload identity, policy result, resource sensitivity, role, session context, and monitoring.
Grant only the access required for the approved purpose, resource, action, environment, and time window.
Architecture question
What is the smallest practical access scope that still supports the business or service need?
Evidence
Role or entitlement scope, access review, task duration, approval, resource ownership, and activity evidence.
A valid access relationship today may become inappropriate after role, device, project, service, provider, or risk-context changes.
Architecture question
What events should cause the access decision to be reviewed or changed?
Evidence
Lifecycle triggers, device/session state, role changes, project end, policy updates, and owner review.
A successful sign-in to one application should not automatically create access to unrelated services or data.
Architecture question
Which resource-specific authorization decision protects each important service or dataset?
Evidence
Application authorization, service roles, workload permissions, data access policy, and environment scope.
High-impact administrative access should not remain continuously available when it is only needed for occasional tasks.
Architecture question
Can privileged capability be time-bounded, separately approved, and reviewed after use?
Evidence
Privileged activation records, approval, duration, session evidence, and post-use review.
Applications and services should authenticate as named non-human principals rather than depending only on network location or shared secrets.
Architecture question
Does the service have a distinct workload identity with resource-specific authorization?
Evidence
Workload binding, service owner, resource policy, deployment relationship, and service-access logs.
Identity and policy decisions should be supported by current telemetry, lifecycle evidence, and source health.
Architecture question
Can the organization tell whether the identity, policy, and activity evidence are still current?
Evidence
Authentication, authorization, policy-change, privileged-action, workload, review, and source-health telemetry.
A temporary deviation from the preferred access model should have an owner, reason, risk, review date, and target state.
Architecture question
Is this access intentionally exceptional, or is it simply ungoverned drift?
Evidence
Exception record, owner, expiration, compensating control, approval, and closure requirement.
Trust Assumptions
Why it fails: Network location does not prove the identity, business purpose, or authorization for a resource.
Better approach: Use identity and resource-specific authorization even on private networks.
Why it fails: A valid sign-in to one service does not justify access to every application or dataset.
Better approach: Evaluate authorization at each important resource boundary.
Why it fails: Continuous standing privilege increases the impact of mistakes, misuse, or identity compromise.
Better approach: Use separate, time-bounded privileged activation where practical.
Why it fails: Team ownership does not automatically justify staging identities accessing production resources.
Better approach: Keep environment-specific identity and resource scope.
Why it fails: Business trust does not remove the need for narrow technical scope, sponsorship, monitoring, and review.
Better approach: Use explicit external identity, bounded resource access, and lifecycle governance.
Why it fails: Silence is not strong evidence when telemetry sources may be stale or incomplete.
Better approach: Monitor both identity events and source health.
Decision Context
Zero trust does not mean every access decision must use every possible signal. It means the architecture should use the context that is relevant to the sensitivity and purpose of the request.
Is the principal the expected human or workload identity?
Examples: Workforce identity, workload identity, external identity, privileged identity, federation relationship.
How important or sensitive is the requested application, data, control plane, or service?
Examples: Public content, internal application, sensitive report storage, restricted student-support data, management plane.
Is the requested action standard, sensitive, or administrative?
Examples: Read application data, update workflow, manage identity policy, change infrastructure configuration.
Is the access request for development, staging, production, or recovery?
Examples: Staging workload to staging data, production workload to production database, temporary recovery operator.
Does the policy consider relevant session or managed-device context without treating it as the only control?
Examples: Approved managed device, expected session posture, step-up requirement, temporary session restriction.
Is access still appropriate at this moment and within its approved duration?
Examples: Temporary migration window, partner expiration, privileged activation window, workforce role change.
Does current activity or evidence suggest the access relationship should be reviewed?
Examples: Unexpected administrative activity, inactive external identity, stale source, unusual resource request.
Who is accountable for the identity, resource, policy, exception, and next decision?
Examples: Service owner, identity owner, sponsor, platform owner, risk owner.
Vocabulary
An architecture strategy that reduces assumed trust by explicitly verifying access, limiting privilege, protecting resources, using current evidence, and continuously reassessing decisions.
Access confidence granted because of location, prior authentication, organizational relationship, or another condition without enough current resource-specific evidence.
Using relevant identity, resource, policy, context, and evidence to support an access decision.
Limiting access to the minimum practical resources, actions, environment, and duration required for an approved purpose.
An authorization decision that considers identity plus relevant conditions such as resource sensitivity, privilege, environment, device/session context, time, or risk.
Access that remains continuously available rather than being activated only when needed.
Reassessing access as identity, session, device, service, ownership, risk, or policy conditions change.
Making access decisions for the specific protected resource rather than relying on broad network or organizational trust.
Separating resources, environments, applications, or trust zones so one access relationship does not automatically extend to unrelated systems.
Requiring stronger identity assurance before allowing a more sensitive action or resource access.
The allow, deny, limit, step-up, or review outcome produced by an access-control policy using available context.
A documented, bounded deviation from the preferred access architecture with owner, reason, risk, expiration, and target state.
Fictional Zero-Trust Register
Principal
Counselor Workforce Identity
Resource
Student Services Portal
Purpose
Approved student-support workflow
Verification
Current workforce authentication + counselor role
Privilege
Application-level counselor functions only
Context
Production; standard workforce session
Monitoring
Authentication + authorization telemetry
Owner
Student Services Operations
Architecture concern
Access must change if the workforce role changes.
Principal
Privileged Administrator
Resource
Cloud Management Plane
Purpose
Approved administrative change
Verification
Named workforce identity + privileged activation
Privilege
Time-bounded administration
Context
Production; privileged session
Monitoring
Activation + management audit + post-use review
Owner
Platform Engineering
Architecture concern
One emergency activation lacks complete post-use review evidence.
Principal
Student Portal Workload Identity
Resource
Student Support Database
Purpose
Application data operations
Verification
Named workload identity
Privilege
Application-specific database actions
Context
Production workload only
Monitoring
Workload authentication + database access telemetry
Owner
Application + Data Platform
Architecture concern
Private network path is supporting context, not the authorization basis.
Principal
External Partner Identity
Resource
Scheduling Integration Service
Purpose
Narrow integration support
Verification
Approved external identity + current sponsor
Privilege
Limited support actions
Context
Production; partner support scope
Monitoring
External sign-in + administration logs
Owner
Integration Owner
Architecture concern
Partner access review is due in 30 days.
Principal
Analytics Staging Workload
Resource
Production Student Support Database
Purpose
None approved
Verification
Staging workload identity is valid
Privilege
Requested read access
Context
Cross-environment request
Monitoring
Policy denial event
Owner
Analytics + Data Platform
Architecture concern
Valid identity does not create production authorization.
Principal
Legacy Reporting Service Account
Resource
Generated Report Storage
Purpose
Historical reporting job
Verification
Long-lived service credential metadata
Privilege
Report generation access
Context
Production
Monitoring
Partial
Owner
Unknown
Architecture concern
Owner, lifecycle, review, and modernization path are unresolved.
Principal
Temporary Privileged Identity
Resource
Migration Control Service
Purpose
Approved migration validation
Verification
Named identity + temporary privileged approval
Privilege
Migration-specific operations
Context
Production; approved project window
Monitoring
Activation + migration audit
Owner
Migration Project Owner
Architecture concern
Access must expire at the project checkpoint.
Fake Dashboard
Fictional access, verification, standing privilege, and evidence summary
Zero-trust relationships reviewed
7
Workforce, privileged, workload, partner, cross-environment, legacy, and temporary access
Explicitly verified
5 / 7
Two blocked legacy/cross-environment relationships fail purpose or ownership requirements
Standing privileged paths
0
Privileged administration is modeled as time-bounded activation
Open conditions
3
Privileged post-review, partner renewal, and temporary migration expiration require follow-up
Fake SOC Alert
Source: Fictional Zero-Trust Policy Review • Time: 09:49
Resource-Centric Authorization
Zero trust is strongest when resources make their own authorization decisions based on the identity and policy context that matters. This prevents one broad trust decision from spreading across unrelated applications, data stores, and administrative services.
A workforce identity may be valid but still needs the correct application role.
An application workload may reach a database only for approved operations.
Normal workforce access should not automatically include management-plane privilege.
Staging identities should not automatically cross into production.
External identities should remain limited to the specific integration or support purpose.
Emergency access should remain exceptional, bounded, monitored, and reviewed.
Fake Log Panel
[08:14] ZT-01 counselor->portal identity=CURRENT role=COUNSELOR decision=ALLOW [08:37] ZT-02 admin->management activation=JIT post_review=PARTIAL state=CONDITIONAL [09:01] ZT-03 portal-workload->database identity=WORKLOAD scope=APP_ONLY decision=ALLOW [09:24] ZT-04 partner->integration sponsor=CURRENT review_due=30d state=CONDITIONAL [09:49] ZT-05 staging-workload->prod-db purpose=NONE decision=DENY state=BLOCKED [10:13] ZT-06 legacy-reporting owner=UNKNOWN lifecycle=STALE state=BLOCKED [10:39] ZT-07 migration-operator expires=PROJECT_CHECKPOINT state=CONDITIONAL
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Zero-Trust Anti-Patterns
Why it fails: The organization treats zero trust as an access-denial slogan rather than a method for making better access decisions.
Better approach: Allow legitimate access when identity, purpose, resource, privilege, context, and evidence support it.
Why it fails: Authentication at one boundary becomes assumed authorization across unrelated resources.
Better approach: Use resource-specific authorization decisions.
Why it fails: Applications and users inside a private network receive broad access without identity-aware authorization.
Better approach: Keep identity and policy controls active regardless of network location.
Why it fails: Standing privilege remains available even when no approved administrative task is happening.
Better approach: Use time-bounded privileged activation and post-use review.
Why it fails: The policy ignores resource sensitivity, privilege, environment, or session context.
Better approach: Use proportionate contextual decisions for more sensitive access.
Why it fails: External access continues indefinitely after sponsorship or business need changes.
Better approach: Use sponsor, review date, expiration, and narrow resource scope.
Why it fails: The team can see sign-ins but cannot explain authorization decisions, privilege use, policy changes, or resource access.
Better approach: Monitor the full identity-to-resource decision path.
Why it fails: A temporary deviation remains indefinitely because nobody owns closure.
Better approach: Keep exceptions bounded, owned, time-limited, and linked to a target state.
Scenario Decision Lab
A staging analytics workload authenticates successfully and requests read access to a production database. No approved production purpose exists.
Scenario Decision Lab
A partner identity has narrow integration access and a current internal sponsor, but the next access review is due in 30 days.
Safe Fictional Lab
Use fictional identities, resources, policies, owners, sessions, environments, and evidence only. Do not test any real access-control system.
Create at least twelve fictional identity-to-resource relationships.
Include workforce, privileged, workload, external, temporary, and legacy identities.
Give each relationship a stable ZT ID.
Record principal and resource.
State business or technical purpose.
Record verification context.
Record allowed action scope.
Record environment.
Record relevant session/device context where appropriate.
Record monitoring evidence.
Assign identity and resource owners.
Classify whether trust is explicit, assumed, or unsupported.
Classify status as Confirmed, Conditional, Unknown, Blocked, or Accepted Risk.
Identify at least three examples of excessive standing trust.
Identify at least two places where resource-specific authorization improves the design.
Identify at least two privileged-access relationships.
Identify at least two workload identity relationships.
Identify at least two external or temporary relationships.
Create at least two time-bounded exceptions with target states.
Add change triggers for role, project, provider, device/session policy, service, ownership, environment, and architecture changes.
Lab boundary
This is a fictional architecture assessment only. Do not attempt authentication bypass, privilege escalation, credential testing, token use, real account access, session manipulation, or policy changes in any live system.
Analyze the Evidence
Advanced Challenge
A fictional organization currently trusts internal network location, gives administrators permanent privilege, lets one application sign-in unlock several resources, and leaves partner access active until someone remembers to remove it. Redesign the access model using zero-trust principles.
Named human and workload identities
Resource-specific authorization
Environment-specific access
Least-privilege roles or entitlements
Time-bounded privileged activation
Partner sponsorship and expiration
Temporary-access lifecycle
Workload identity instead of network trust
Relevant contextual access decisions
Authentication monitoring
Authorization monitoring
Policy-change monitoring
Source-health monitoring
Exception governance
Review/change triggers
Blocked findings that must close
Defender Habits
Skill Check
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create the second artifact for your A13 Enterprise Identity and Zero-Trust Review: a fictional Zero Trust Principles Assessment with at least twelve identity-to-resource relationships. Include relationship ID, principal, resource, purpose, verification context, privilege, environment, relevant session/device context, monitoring evidence, owners, trust assumption, status, concern, next action, exception reference where needed, and change trigger.
Confidence / Readiness Reflection
A13.3 moves into Federation and Single Sign-On Concepts. Before continuing, make sure you can explain how zero trust can support federated access without assuming that one successful sign-in should automatically unlock every connected application.
I can explain zero trust without describing it as deny everything.
I can distinguish identity verification from resource authorization.
I can explain least privilege in terms of resource, action, environment, and time.
I can identify excessive standing trust.
I can explain why access should be reassessed as conditions change.
Portfolio Build Guide
Show exactly what the current design assumes before proposing a stronger verification or authorization model.
Every access relationship should clearly identify who or what is acting and what protected resource is being requested.
Record exact action scope, environment, and duration instead of broad labels such as standard access.
Use only the device, session, privilege, or risk context that meaningfully improves the decision.
Authentication, authorization, policy, privileged activity, review, and source-health evidence should support major claims.
Partner, temporary, privileged, and workforce access should have clear review or change triggers.
Make owner, expiration, compensating control, target state, and closure requirement visible.
A13.3 will use these trust relationships to analyze federation and single sign-on architecture.
Key Takeaways
Lesson Safety Boundary
Do not attempt password guessing, account enumeration, authentication bypass, session hijacking, privilege escalation, token theft, credential testing, or access to real identity systems. All decisions and evidence in this lesson are fictional and defensive.
Lesson Complete
You now have a zero-trust architecture model built around explicit verification, resource-specific authorization, least privilege, bounded trust, current evidence, lifecycle, monitoring, and exceptions. Next, A13.3 focuses on Federation and Single Sign-On Concepts.