Lesson 4: Secure Endpoint Configuration Lab

Security architecture is easy on paper.

The interesting part begins when the controls have to coexist with real users, recovery, applications, and management.

This lab uses a fictional staff laptop, corporate phone, and wireless environment. Nothing here changes a real account, endpoint, or network.

Start with the current state

Staff laptop

daily user: local administrator
guest account: enabled
screen lock: never
BIOS/UEFI password: none
AutoRun: enabled
unused services: several enabled
BitLocker: off
Defender Antivirus: enabled/current
Windows Defender Firewall: enabled
cloud identity MFA: enabled

Corporate phone

device encryption: enabled
screen lock: simple swipe
OS/app updates: pending
MDM enrollment: missing
remote backup: disabled
locator / remote wipe: unavailable until enrollment
failed-login restriction: not configured

Wireless environment

staff infrastructure: WPA3 capable
central user authentication: required
guest access: must remain isolated from staff resources
legacy endpoint: obsolete weak wireless mode only

The goal is not to maximize the number of green toggles.

The goal is to build a target state that satisfies the requirements and can still be recovered and supported.

Boundary 1: daily privilege

Current state:

Staff user is a permanent local administrator.

Target design:

daily work → standard user
approved maintenance → controlled elevation / technician process

Verification should include both sides:

• normal work succeeds;
• administrative changes require the approved elevation path.

Security tests need negative outcomes too.

Boundary 2: unlocked session

A strong password protects sign-in.

It does not protect an already authenticated workstation left unattended.

Choose an appropriate timeout and screen-lock policy.

Verify that the session locks at the expected time, the user can reauthenticate, and required long-running work is not unintentionally broken.

Boundary 3: guest account, default admin state, and unused services

Ask for every account and service:

What legitimate function depends on this?

If the guest account is not required, disable it under policy.

If a default administrator name or default credential creates unnecessary exposure, change or manage it according to the approved baseline.

If an unused legacy service has no business requirement, disable it.

Different case:

service: print spooler
business requirement: user prints daily

Disabling it just to reduce attack surface breaks the mission.

Hardening requires context.

Boundary 4: AutoRun and removable media

If policy disables automatic execution from removable media, verify both sides:

• approved media can still be accessed;
• content does not execute merely because the device was inserted.

The goal is controlled use, not pretending removable media no longer exists.

Boundary 5: BitLocker and recovery

Before enabling encryption, define:

• supported edition and hardware state;
• TPM/boot requirements;
• recovery-key ownership;
• approved escrow location;
• service procedure after TPM, firmware, or motherboard changes.

Then verify protection state and the authorized recovery path.

Encryption without recovery is unfinished.

Boundary 6: Defender Antivirus and firewall

These controls are already enabled.

Do not change them just because the lab is about hardening.

Verify:

• antivirus protection and current security intelligence;
• firewall enabled for expected profiles;
• no broad unnecessary exception exists.

If one approved application needs a rule, design the narrowest rule that satisfies the requirement.

Do not disable the firewall to prove the application works.

Boundary 7: UAC and elevation

Test that standard operation does not require elevation, an approved administrative task does, and the user cannot silently bypass the boundary.

A checkbox being enabled is not the same as the control behaving correctly.

Boundary 8: wireless protection and centralized identity

Staff Wi-Fi requires:

• supported WPA2/WPA3-class protection;
• modern AES-based encryption direction;
• centralized authentication where required;
• individual accountability rather than one permanent shared staff password.

Map the roles:

WPA2/WPA3 → protects wireless access/link
RADIUS → centralized network AAA role
Kerberos → enterprise identity context where used
MFA → additional authentication evidence

Do not treat the acronyms as interchangeable.

Boundary 9: guest separation

Requirement:

Guest devices need internet access but should not reach staff resources.

Success requires two tests:

1. the allowed path works;
2. the denied path stays denied.

If guest internet works and staff resources are also reachable, the network is connected and insecure relative to the requirement.

Boundary 10: legacy wireless endpoint

The old device cannot meet the staff wireless requirement.

Possible decisions:

• replace it;
• isolate it on a governed network;
• remove its wireless requirement;
• approve a narrow exception if policy permits.

Do not weaken the staff network because one old client has opinions.

Boundary 11: mobile screen lock and failed-login policy

Replace the simple swipe with an approved authentication method such as PIN, fingerprint, facial recognition, or another supported policy-approved mechanism.

Then configure the appropriate failed-login restriction and verify the behavior using fictional/supplied state.

Do not lock out a real student or personal device for the sake of a demo.

Boundary 12: mobile patching and management

The target state may include:

• supported OS/app updates;
• MDM enrollment;
• configuration profiles;
• approved Wi-Fi/VPN/certificates;
• application restrictions;
• endpoint anti-malware/antivirus where required;
• content filtering where required;
• failed-login policy.

Management exists because consistency matters.

Boundary 13: lost-device recovery

Before remote wipe, answer:

• Is backup current?
• Who can authorize wipe?
• Which account or session tokens need protection or revocation?
• Is locate or lock appropriate first?
• What must be documented?

Remote wipe is a destructive security action, not a demo button.

Boundary 14: physical protection

Choose physical controls based on the actual risk:

• equipment lock;
• locked storage;
• badge-controlled room;
• surveillance;
• motion detection;
• door alarm;
• lighting or guard coverage where required.

A camera provides evidence and deterrence. It does not physically prevent removal.

Controls have scopes.

Build the target-state record

For each major change, document:

asset
risk
current state
target state
control
why it fits the risk
management / recovery dependency
usability tradeoff
positive test
negative test
remaining risk

Do not submit a list that says:

BitLocker: enabled. MFA: enabled. Firewall: enabled.

That is inventory.

Explain what the controls are supposed to accomplish and how the evidence proves they do.

Before you move on

A supportable hardened endpoint has three properties:

1. unnecessary exposure is reduced;
2. required work still functions;
3. recovery and management remain possible.

Next we defend those decisions against mixed tickets where convenience and security pull in opposite directions.