Lesson 3: Wireless Authentication and Device Hardening

A hardened system is not a computer with every feature disabled.

That would be easy.

It would also be useless.

Hardening means reducing attack surface and unnecessary privilege while preserving the legitimate job the system is supposed to perform.

The question is always:

What does this system need, what does it not need, and which controls keep the required path safe enough under policy?

Wireless security protects the radio-access boundary

Modern Wi-Fi environments use WPA2 or WPA3 under supported configurations.

Older WEP and weak or deprecated settings should be treated as legacy security problems, not compatibility conveniences.

A strong wireless design answers two separate questions:

1. How is the radio traffic protected?
2. How is the user or device authenticated to the network?

Those are related, not identical.

WPA2/WPA3 and TKIP/AES belong to the link-protection layer

WPA2 and WPA3 provide modern Wi-Fi security frameworks.

AES-based protection is the modern direction for supported deployments.

TKIP is associated with older compatibility and should not be preserved merely because one obsolete endpoint cannot support stronger configuration.

If one legacy device forces a weaker design, document the real choices:

• replace the device;
• isolate it;
• create a narrowly approved compatibility exception;
• explicitly accept defined risk if policy allows it.

Do not quietly weaken the entire staff network.

Centralized authentication is another layer

Recognize these enterprise authentication concepts:

RADIUS

Commonly used for centralized authentication, authorization, and accounting for network access.

TACACS+

Commonly associated with centralized AAA for administrative access to network devices.

Kerberos

Ticket-based authentication common in domain and enterprise environments.

MFA

Adds independent authentication evidence.

These do not replace wireless encryption.

Think in layers:

radio protection
   ↓
network-access authentication
   ↓
identity / authorization
   ↓
application access

Data at rest needs a different control

Wireless encryption protects traffic on the wireless link.

It does not protect the laptop SSD after the device is stolen.

That is a different risk.

Use approved data-at-rest encryption where required.

Security is often several controls protecting different moments in the data path.

Password policy is one part of account security

Organizations may define requirements for:

• minimum length;
• password type;
• uniqueness and history;
• complexity where applicable;
• expiration where policy requires it;
• failed-attempt lockout;
• account expiration;
• allowed login times.

Technicians should implement current policy, not invent arbitrary rules because an old study guide used them.

Password managers reduce reuse when managed well

An approved password manager can help users maintain unique credentials without memorizing every one.

It creates its own high-value boundary:

• strong primary authentication;
• MFA where appropriate;
• recovery process;
• managed vault policy.

A control can reduce one risk while creating a new dependency that must be protected.

Session locks protect an already authenticated system

A strong password does nothing when a user walks away from an unlocked desktop.

Use appropriate screen-lock, timeout, logoff, and session-protection rules.

The risk is unauthorized use of an active session.

Different risk from password guessing.

BIOS/UEFI passwords protect firmware configuration

Firmware passwords can restrict access to BIOS/UEFI settings on supported systems.

That can help protect boot and security configuration.

It also creates recovery and administration requirements.

A forgotten firmware password is not a security success.

Reduce unnecessary account and service exposure

Workstation hardening can include:

• disabling guest accounts where not required;
• restricting permissions and login times;
• configuring failed-attempt lockout;
• configuring session timeout and screen lock;
• using account-expiration rules where appropriate;
• changing default administrator names or credentials according to policy;
• disabling AutoRun;
• disabling unused services;
• removing unsupported software;
• removing unnecessary standing privilege.

The key word is unnecessary.

Do not disable a required service and celebrate the smaller attack surface while the business function is broken.

Patching closes known software weaknesses

Operating systems and applications require supported updates.

Patch management is more than "turn automatic updates on."

A managed process may include:

identify update
→ assess compatibility / risk
→ deploy under policy
→ verify installation
→ confirm required functions still work

A patch that installs but breaks the required workflow becomes an operations problem.

Security and change control meet here.

Mobile devices need the same reasoning with different controls

A corporate phone may need:

• device encryption;
• strong screen lock;
• current OS and application patches;
• MDM enrollment;
• configuration profiles;
• approved Wi-Fi/VPN/certificates;
• endpoint antivirus or anti-malware where supported and required;
• content filtering where policy requires it;
• application restrictions;
• locator capability;
• remote backup;
• remote lock or wipe;
• failed-login restrictions.

The device is portable, so loss and theft become larger risks.

That increases the value of encryption and remote management.

Mobile screen locks are not equal authentication

Mobile devices may support:

• facial recognition;
• PIN;
• fingerprint;
• pattern;
• swipe.

A simple swipe may provide convenience without meaningful authentication.

The lock method should match the organization's policy and risk.

MDM makes policy authoritative above the local device

Configuration profiles and MDM can enforce passcodes, encryption, Wi-Fi/VPN, certificates, application controls, updates, remote actions, and other settings.

If the user changes a managed setting and it returns, that may be expected behavior.

Do not fight the management layer locally.

Identify who owns the policy.

BYOD and corporate ownership create different privacy boundaries

A personally owned device used for work raises questions about:

• what the organization may manage;
• what work data it may remove;
• user privacy;
• work/personal data separation;
• support responsibility.

A corporate-owned device generally gives the organization broader control under policy.

The technician should not improvise the ownership model.

Lost-device response is a sequence

Suppose a corporate phone is reported lost.

An approved response may include:

confirm user / device identity
→ lock or locate if authorized
→ assess account/session risk
→ verify backup state
→ revoke or protect credentials/tokens as required
→ remote wipe only when authorized
→ document outcome

Remote wipe is high impact.

If the device contains unsynchronized data, that data may be lost permanently.

Security response still has a recovery boundary.

Worked case: old client only supports weak Wi-Fi

Requirement:

staff Wi-Fi: modern WPA2/WPA3 configuration
central user authentication: required
legacy device: obsolete weak mode only

Weak answer:

Enable the old mode for everyone.

Stronger reasoning:

• the legacy endpoint cannot meet the current requirement;
• weakening the shared network expands risk for every client;
• isolate, replace, remove the network dependency, or govern a narrow exception.

Compatibility does not automatically outrank security policy.

Worked case: user wants permanent admin rights

Reason:

One maintenance tool needs elevation once a month.

Better design:

• standard daily account;
• approved elevation, JIT, or technician process when needed;
• audit the privileged action.

Permanent privilege solves convenience by enlarging the attack surface every day.

Build two hardened endpoints

Design target states for:

1. a staff Windows laptop;
2. a corporate smartphone.

For each, document:

required mission
wireless / authentication model
data-at-rest protection
daily account privilege
password / session rules
firmware protection
update / patch ownership
unused account/service reduction
management policy / MDM
endpoint protection / content filtering
backup / recovery dependency
lost-device response
one usability tradeoff
positive verification
negative verification

Before you move on

Hardening is not:

turn everything off.

It is:

remove unnecessary exposure, protect the boundaries that matter, preserve recovery, and prove the required work still functions.

Next we build a complete secure endpoint design and test whether the controls work together instead of just existing on a checklist.