Security Principles & Trust Boundaries.

A login is the beginning of a decision—not the end.

In Lesson 01, you learned to identify assets, vulnerabilities, threats and possible harm. Now consider a contractor who successfully signs in to Northstar Services with multifactor authentication. Does that mean the contractor may export payroll, change a firewall or delete protected backups?

No. The resource must still evaluate which operation the contractor is permitted to perform and under what conditions. This lesson starts with everyday examples; no experience with cloud identity administration, directory commands or enterprise licensing is required.

Identity is who or what requests access.

Before evaluating a request, understand which person, service, or device is making it.

An identity is the account or other identifier used to represent a person, workload, or device. An employee might sign in with a named user account; an automated backup job may run using a dedicated workload identity. Both deserve ownership, lifecycle controls and scoped permissions.

An identity is not the same as a device. A verified employee can use an unmanaged laptop; a healthy managed laptop can be used by someone who is not authorized. Describe those facts separately so a control is not assumed to establish trust it cannot prove.

Authentication checks the claim; authorization checks the action.

Successful sign-in is not permission to do everything.

Authentication asks whether a presented identity can be verified. Passwords, passkeys, certificate-based mechanisms and multifactor authentication (MFA) can contribute to that check. MFA uses independent factors in the chosen method; it does not automatically prevent every stolen session or compromised endpoint.

Authorization asks whether the authenticated principal is allowed to perform a particular operation on a particular resource. Viewing the dashboard, exporting all payroll records and modifying the payroll administrator role are distinct operations with potentially different permissions.

Every access decision needs a subject, resource and action.

Ask for the exact operation, not a vague label such as 'network access.'

A request can be described as subject (who), resource (what), action (what operation), and context (relevant conditions). For example: the Northstar help desk account requests 'read' for a workstation inventory; or a backup operator requests 'delete' for a recovery set.

Context can include the managed-device state, authentication method, network path, current risk signals or a valid change approval. These conditions help enforce policy, but they do not replace a defined permission for the exact resource and operation.

Least privilege means only the permissions needed.

A useful account should not become an all-purpose administrator by convenience.

Least privilege limits a principal to the resources and operations required for its current work. Need-to-know is the related idea that sensitive information is accessible only to people whose responsibilities require it. A help desk technician may need to reset a standard user password without having export access to payroll records.

Scope matters alongside privilege level. A regional administrator might manage one branch but not every branch. Temporary privileged access with expiration may be preferable to permanent broad membership. Removing privileges does not remove the need for audit and safe exception procedures.

Roles simplify permissions; attributes refine conditions.

Understand RBAC, ABAC and the need to enforce both server-side.

Role-based access control (RBAC) associates permissions with roles such as Payroll.Reader or Network.Operator and assigns appropriate roles to principals. It is easier to maintain than granting unrelated permissions to every employee, but an overpowered role still creates unnecessary risk.

Attribute-based access control (ABAC) evaluates properties such as department, data classification, device posture and request time. Real systems may combine roles with conditional rules. The important lesson is that the resource itself must enforce permission checks; hiding a button in the interface does not stop a direct API request.

Default deny and fail closed make missing permission safe.

If a policy cannot establish the required conditions, it should not silently grant access.

A default-deny policy allows only explicitly authorized operations; everything else is rejected. For example, a Helpdesk.Reader role may have 'view device health' granted, while 'delete backup' remains denied unless a separately approved role permits it.

Fail closed describes what to do when a crucial verification cannot succeed: do not treat a missing identity, unavailable approval record or incomplete policy result as permission. That does not mean every unavailable component should take down the whole business. Design deliberate, audited exception and recovery processes for critical operations.

A trust boundary is where one set of assumptions must be checked again.

Moving from a user session to a sensitive service changes the decision you must make.

A trust boundary separates contexts with different security expectations or authority—for example, an employee's browser and the payroll API; a workstation VLAN and backup administration; a guest tenant and an internal data store. Crossings should make the system evaluate the operation rather than assuming previous access extends automatically.

Network segmentation creates intentional routes between groups of systems, often enforced using firewalls or policy. It can limit which hosts communicate, but it does not decide whether a logged-in person may export a record. Identity and resource authorization remain important even when network controls exist.

Zero Trust asks for explicit resource access decisions.

It is an architecture principle, not a product you simply turn on.

Zero Trust architecture challenges implicit trust based only on internal network location, VPN access or past authentication. It evaluates access to individual resources under current policy and context, using identity, device information, service permissions and other relevant signals.

It does not mean all systems must constantly prompt for passwords, every packet is suspect, or a compliant device is automatically safe. A successful request can still be monitored and reevaluated when conditions change. The goal is appropriate access with limited blast radius when an identity or endpoint is compromised.

Follow the access request through every required gate.

One successful gate cannot override another failed gate.

In the explorer below, four conditions form the fictional Northstar policy: verified identity and appropriate authentication, managed device where required, permission to perform the requested action, and a valid change approval for privileged changes. If any required gate fails, the resource denies the operation.

The model is purposely simple. Real systems may add detailed scopes, group assignments, risk signals, session lifetimes, exceptions and step-up authentication. Its purpose is to show why 'logged in' is not a complete security decision. Try making an allowed request fail and restoring only the missing condition.

A session is convenient—but it is not permanent permission.

Credentials, tokens and sessions carry time and context limits.

After authentication, many applications issue a session cookie or access token so the user does not reenter credentials for every screen. A session proves that some authentication happened under certain conditions; it does not automatically mean every operation is allowed forever.

Tokens may have scopes, audiences and expiry times. A token intended for one API should not be treated as valid everywhere. Session theft, terminated employment, changed roles and risky device signals can require reevaluation or revocation. A resource must apply its own authorization rules even when a token appears valid.

Prove security with both allowed and denied tests.

A green success message is incomplete evidence when the wrong person can also succeed.

Positive testing verifies that a legitimate payroll reader can view a permitted payroll summary. Negative testing verifies that help desk and vendor identities cannot view or export sensitive records. Both outcomes matter: a system that denies every request is secure from some disclosures but useless; a system that allows every request is convenient but unsafe.

Use synthetic or authorized test identities and avoid testing against production accounts without scope and approval. Collect evidence that shows identity, resource, action, decision and relevant time, while minimizing confidential data in the logs. A denial without diagnostic context may be hard to investigate; logging sensitive token contents is not an acceptable shortcut.

Emergency access still needs rules, evidence and recovery.

Fail closed and resilience must be planned together.

Sometimes the normal access path becomes unavailable during an incident. Emergency access (often called break-glass access) may allow designated operators to restore essential services. It should be protected, time-limited or otherwise controlled as appropriate, monitored and audited, with routine tests and clear ownership.

An undocumented permanent bypass is not an emergency procedure. Establish explicit triggers, responsible approvers, limits, monitoring and after-action review. If a technician cannot verify that a requested privilege or exception is authorized, the safe action is to escalate—not to improvise an insecure workaround.

Can you explain why an authenticated user is denied?

A vendor completes MFA on a managed laptop but receives an access-denied response from a payroll API. What do we know? They met some authentication and device conditions. What is not established? Their permission to export payroll data. The next step is to examine the actual resource policy—not to disable MFA or grant blanket access.

These distinctions become especially important in Incident Response Fundamentals, where an unusual login must not be mistaken for proof that privileged access was granted.

Keep authorization decisions grounded.

The lesson stands alone. These external sources explain Zero Trust architecture, authentication and the risks of broken resource authorization in more depth.