Lesson 1: Physical and Logical Security Controls

A lock is excellent at stopping someone who does not have the key.

It is useless against an authorized user who copies sensitive data to the wrong place.

MFA can make account takeover harder.

It does not stop a legitimate administrator from making a bad configuration change.

Security controls work at boundaries.

The technician's job is to understand which boundary is actually at risk.

Start with the asset and the unwanted event

Before choosing a control, state what you are protecting and what you are trying to prevent, detect, or recover from.

Example:

asset: server-room equipment
unwanted event: unauthorized physical access

Now physical controls make sense.

Different example:

asset: payroll folder
unwanted event: user outside Finance reads files

A bollard is not going to help.

The boundary is identity and authorization.

Diagrams open at a readable shape-aware scale. Zoom or expand when you need more detail.

Physical security controls change who can reach equipment

A+ expects recognition of several physical controls. Learn them by purpose, not as a pile of nouns.

Bollards

Bollards create a vehicle-access barrier around a protected area.

They can reduce accidental or intentional vehicle entry.

They do not authenticate a person walking through a doorway.

Fences, guards, lighting, and controlled entrances

Fences establish a perimeter. Security guards add human observation and response. Lighting improves visibility and can support deterrence or surveillance.

An access-control vestibule controls transition between spaces, often preventing both doors from being open at once.

The control matters because it shapes the path someone must cross.

Badge readers, key fobs, smart cards, mobile digital keys, and physical keys

These control possession-based access according to the facility's system.

A valid credential proves the system accepted that credential.

It does not prove the person will close the door behind them.

Door and equipment locks

A door lock restricts entry to a room or area.

An equipment lock restricts movement or access to a specific device, rack, cabinet, or laptop.

Those are different physical boundaries.

A cable lock on a laptop does not replace room access control. A locked room does not stop an authorized person from carrying an unlocked portable device out.

Video surveillance

Cameras can provide deterrence and recorded evidence.

They do not physically stop entry.

Their usefulness depends on placement, retention, visibility, monitoring, and the surrounding response process.

Alarms and motion sensors

Alarms notify or trigger response when a defined condition occurs.

Motion sensors detect movement in a monitored area.

A sensor that detects motion but has no useful response path is incomplete architecture.

Detection and response belong together.

Magnetometers

Magnetometers can detect metal and may appear at controlled-entry checkpoints.

They solve a screening problem.

They do not verify identity or decide whether the person carrying the metal is authorized to enter.

Tailgating shows the gap between technology and behavior

Suppose a server room has:

badge reader: working
camera: working
door: frequently propped open

Is access control working?

The reader is.

The security process is not.

A stronger design may combine badge access, door-position monitoring, alarms, surveillance, vestibules, and policy or training.

Security systems fail at the interaction between technology and people surprisingly often.

Biometrics are credentials too

Biometric factors can include:

• retina or iris recognition;
• fingerprint;
• palm;
• facial recognition;
• voice recognition.

Biometrics can strengthen authentication workflows, but they create privacy, enrollment, false-match, and recovery concerns.

Unlike a password, your fingerprint is difficult to replace if biometric data is mishandled.

The control has a risk surface too.

Least privilege limits what a valid identity can do

Authentication answers:

Who does the system believe this is?

Authorization answers:

What may that identity do?

Least privilege says the authorized access should be no broader than the legitimate task requires.

A common bad support shortcut is:

The app fails unless the user is an administrator, so make the user an administrator permanently.

That may remove the symptom.

It also widens the security boundary dramatically.

The stronger question is:

What exact resource or permission does the application require?

ACLs make access decisions explicit

An access control list, or ACL, defines allowed or denied access for identities or systems against a resource.

The protected object could be a file, folder, network rule, interface, or another controlled resource.

An ACL is useful because the decision can be inspected:

• who is allowed;
• who is denied;
• which action is permitted;
• which action is blocked.

A permission system is architecture expressed as rules.

MFA strengthens authentication evidence

Multi-factor authentication combines independent factor categories such as:

• something you know;
• something you have;
• something you are.

A+ expects recognition of mechanisms such as:

• email codes;
• hardware tokens;
• authenticator apps;
• SMS;
• voice;
• TOTP;
• OTP concepts;
• biometrics.

Two passwords are not two factors.

They are two examples of the same factor type.

Not every MFA method has the same strength or operational risk, so real deployments should follow current policy and guidance.

SSO and SAML solve federation and usability problems

Single sign-on lets one authenticated identity reach multiple authorized services without separate credentials at every application.

That makes the central identity more important, not less.

SAML is commonly used to exchange identity assertions between an identity provider and a service provider.

user
  ↓
identity provider
  ↓
SAML assertion / federation
  ↓
service provider

SSO does not decide every authorization rule by itself.

Just-in-time access reduces standing privilege

Suppose a technician needs administrator access for fifteen minutes to perform an approved task.

Compare:

• permanent administrator membership;
• shared admin password;
• controlled temporary elevation.

Just-in-time access reduces the time privileged capability exists.

It creates management dependencies such as approval, audit trail, expiration, and recovery if the elevation service fails.

PAM protects privileged access

Privileged Access Management can control, broker, monitor, or audit high-privilege identities and actions.

Administrator credentials can change the entire system.

They deserve stronger controls than ordinary daily user accounts.

A shared admin password on a sticky note is technically a credential strategy.

It is just a terrible one.

IAM and directory services manage identity lifecycle

Identity and Access Management covers identities, authentication, authorization, provisioning, deprovisioning, roles, and access lifecycle.

Directory services can centralize users, groups, computers, organizational units, and related policy relationships.

When an employee leaves, disabling one local account may not be enough if cloud services, VPN, badges, and applications all preserve access.

Identity has a lifecycle.

MDM controls managed endpoints

Mobile Device Management can enforce supported configuration across devices, including passcodes, encryption, Wi-Fi/VPN, certificates, applications, update requirements, and remote lock or wipe.

A local user may not be the authoritative owner of a managed setting.

That matters during troubleshooting.

DLP focuses on data leaving the approved boundary

Data Loss Prevention controls can detect or restrict sensitive data movement according to policy.

Example risk:

confidential file copied to an unauthorized removable drive or cloud service.

The user may be authenticated and authorized to read the file.

The security question is whether the data may move to that destination.

Authentication alone is not a complete security model.

Zero Trust challenges location-based trust

A simple old assumption is:

Inside the network = trusted.

Zero Trust concepts reject automatic trust based only on location.

The durable idea is:

verify access based on identity, device, context, policy, and requirement rather than trusting something just because it is inside the perimeter.

A compromised laptop plugged into an internal switch does not become safe because of the cable location.

Worked case: temporary admin access

Requirement:

technician needs privileged access
one approved maintenance task
expected duration: 15 minutes
activity should be auditable

Weak design:

Add technician to Administrators permanently.

Stronger design:

Use approved temporary/JIT privileged access with expiration and audit trail.

What risk did the stronger control reduce?

Standing administrative privilege after the task is finished.

Build a control-to-risk map

For each fictional asset, document:

asset
unwanted event / risk
boundary crossed
control selected
what the control reduces
what the control does NOT prevent
management / recovery dependency
remaining risk

Use a mix of server room, staff laptop, privileged account, confidential folder, corporate phone, cloud identity, removable storage, and guest network scenarios.

Before you move on

A security-control decision should be explainable in one sentence:

We use control X because risk Y crosses boundary Z.

If you cannot name the risk, adding the control may only be adding friction.

Next we bring that reasoning into Windows, where identity, permissions, UAC, encryption, firewall, and domain policy all make separate decisions.