How to Configure a Workstation to Meet Security Best Practices for CompTIA A+ Core 2 (220-1102)
CompTIA A+ Core 2 wants you to think like you’re on the bench in the real world: figure out what’s actually at risk, leave the right protections turned on, and pick the smallest fix that still gets the job done. A workstation stays secure because you’ve got layers working together, not because of some single magic toggle. You lower the odds of unauthorized access, tampering, malware, and all the nasty downtime that comes with them by stacking controls like account restrictions, patching, endpoint protection, firewall rules, encryption, session locks, browser hardening, safe remote access, and a recovery plan you could actually use when things go sideways.
For exam purposes, remember that “given a scenario” means applied judgment. Honestly, the best answer usually isn’t the quick shortcut that looks handy in the moment. It’s the option that fixes the issue without ripping out security just to make the problem go away.
Why Workstations Need Security in the First Place
Workstations are the places where people live their digital workday—they check email, browse the web, grab files, plug in USB devices, sign in to cloud apps, and handle business data all day long. And depending on how they’re set up, they can also hold cached credentials, tokens, browser sessions, and other bits of auth data that an attacker would love to get their hands on. That makes the endpoint a primary attack surface. If somebody takes over the workstation, they might not just get one user’s files—they could get into business apps, steal data, or use that machine as a stepping stone to other systems.
A simple A+ security anchor still works: account, patch, protect, filter, encrypt, lock, limit, recover. Start with who’s signing in and what they’re allowed to do. Least privilege comes first. Keep the operating system and apps up to date. Leave Microsoft Defender Antivirus and reputation-based protection turned on. Use Microsoft Defender Firewall to filter traffic at the host. Encrypt data while it’s sitting on the device, not just when it’s moving across the network. Lock sessions. Limit software and device abuse. Plan recovery before something breaks.
Accounts, Sign-In, and Least Privilege
The most important workstation security habit is using a standard user account for daily work and a separate administrator account only for elevated tasks. Admins can make system-wide changes, while standard users usually can’t. That one choice alone can reduce the damage from phishing, malware, and plain old human error by a lot.
On current Windows systems, some tasks—like installing software, changing system settings, or wrestling with certain printer drivers—might need elevation, though the exact behavior depends on policy, the package, and the environment you’re working in. Don’t just take every “I need admin” request at face value, because honestly, a lot of them don’t hold up once you look closer. Verify whether it really needs admin rights before you hand them over.
Implementation workflow: review local administrators, remove unnecessary users from the Administrators group, keep named accounts for accountability, and avoid shared admin credentials. In a managed environment, the better setup is separate named admin accounts, controlled elevation, and policy-driven access instead of casual, everyday admin use.
Useful tools: lusrmgr.msc, Computer Management, net localgroup administrators, and whoami /groups. Note that whoami shows the current security context, which may differ from the interactive user if a process is elevated or impersonated.
Know the account types:
| Account Type | Typical Use | Security Notes |
|---|---|---|
| Local account | Standalone PC | Managed only on that device; works offline |
| Microsoft account | Home/small office | Cloud-linked sign-in; reset and lockout behavior differs from classic local/domain auth |
| Domain account | On-prem business network | Central policy and authentication through Active Directory |
| Microsoft Entra ID account | Modern cloud-managed business | Supports SSO, device management, and policy via cloud tools |
For sign-in hardening, get comfortable with passwords, PINs, biometrics, and security keys—they all play a role. A Windows Hello PIN is tied to that device, so it’s not the same as a password you can reuse everywhere. MFA is especially valuable when it’s used with Microsoft accounts, VPN access, remote gateways, and business applications.
UAC is another piece the exam likes to bring up. UAC doesn’t replace least privilege; it just adds a consent step so changes don’t slip through quietly in the background. If a task truly needs elevation, use a prompt, Run as administrator, or a separate admin credential instead of making the user permanently local admin.
Password and lockout policies are commonly configured in secpol.msc under Account Policies on standalone systems, or by Group Policy in domain environments. Lockout policies can slow down password guessing, which is a good thing, but if you make them too aggressive, you can lock out real users or even create a denial-of-service headache. Cloud identity systems may handle that differently too.
Permissions and Protecting Local Data
NTFS permissions control who can access files and folders on NTFS drives. Share permissions only matter when someone reaches the folder over the network. NTFS permissions apply whether someone opens the file locally or over the network. When users reach a shared folder over SMB, their real access depends on both share and NTFS permissions, plus inheritance, group membership, and any explicit deny rules in the mix.
Practical example: if a share allows Read for Everyone but NTFS grants Modify only to HR, a non-HR user connecting over the network may still end up with only read access or no useful access depending on the NTFS entries. And if that same user logs on directly at the machine, share permissions don’t enter the picture at all—NTFS does.
For sensitive folders, remove broad inherited access only when you really need to, assign permissions to the right group, and test everything with a standard user account. Avoid broad Modify access just because it is convenient. Also know the difference between EFS and BitLocker: EFS encrypts files per user, while BitLocker encrypts the entire volume at rest. For a lost laptop, full-disk encryption is usually the better answer.
Updates, Patch Management, and Software Hygiene
Windows patching includes quality and security updates, feature updates, driver updates, and optional updates. On current Windows versions, updates are typically managed in Settings > Windows Update, though exact paths vary slightly between Windows 10 and Windows 11. Unmanaged systems often use automatic updating. In managed environments, updates might be pushed through WSUS, Intune, Group Policy, or RMM tools, often with deployment rings and maintenance windows so the entire company doesn’t reboot at once.
The practical move is to check update status, review the history, and plan restarts with a little common sense instead of putting them off forever. If an update fails, start by checking the update history, rebooting, making sure there’s enough disk space, looking at the error code, and escalating if it looks like a bad patch or driver conflict.
Third-party software matters just as much, honestly. Browsers, PDF readers, Java runtimes, collaboration tools, and remote support tools get targeted all the time. Take inventory of installed software, find the unsupported stuff, and remove or replace anything that’s end-of-life. And if you’re using cloud sync like OneDrive, don’t mistake sync for backup—they’re related, but they’re not the same thing.
Microsoft Defender, SmartScreen, and Malware Defense
Current Windows terminology matters: use Microsoft Defender Antivirus, Microsoft Defender Firewall, and the Windows Security app. A solid Defender setup usually includes real-time protection, cloud-delivered protection, current threat intelligence updates, and tamper protection where the system supports it. Tamper protection can stop users from switching off security settings without permission.
Inside Windows Security, you can check protection status, see what’s been blocked, review quarantined items, and pick scan options. Make sure you know the scan types too: quick, full, custom, and offline. Offline scan is especially handy when malware might fight back during a normal Windows session.
Also know Microsoft Defender SmartScreen. It helps block shady sites, phishing pages, and downloads or apps that don’t have a good reputation. On the exam, if a user wants to ignore a warning for some random download, that’s usually a red flag—not a smart move.
Use exclusions very carefully. If a business app really does need an exclusion, document it, keep it as narrow as possible, and make sure the app is actually trustworthy. Don’t run multiple real-time antivirus products side by side unless they’re specifically designed to work together.
Safe troubleshooting order: check Task Manager or Resource Monitor, review Defender history, confirm whether a scan or update is in progress, inspect startup items, and review Event Viewer if needed. Don’t shut off Defender just because the machine feels slow.
Microsoft Defender Firewall and Network Exposure
Microsoft Defender Firewall filters both inbound and outbound traffic on the local machine. Windows uses Domain, Private, and Public firewall profiles. Which profile is active depends on how Windows classifies the network and whether it can reach the domain, not always on a simple manual toggle. Public is usually the more restrictive and safer choice on untrusted networks, but don’t go flipping a managed corporate connection around if policy expects Domain or Private behavior.
When an app needs access, go with the narrowest rule that still works: an app-specific or service-specific rule if you can, then tighten it by profile, protocol, port, and remote IP range. Some cases require more than a simple “open this port” approach. A remote support tool might need a program rule, while a line-of-business service may need a TCP port rule scoped to just one subnet.
Lab mindset: identify the app, determine inbound or outbound need, create the exception in wf.msc, test connectivity, and confirm the firewall remains enabled. If you need to troubleshoot, turn on firewall logging if necessary instead of just disabling the firewall.
Encryption, Secure Boot, and Firmware Security
On portable devices, full-disk encryption is one of the most valuable controls you can enable. BitLocker is the main Windows feature A+ expects you to know, but availability depends on edition. Full BitLocker management is usually tied to Pro, Enterprise, and Education editions. Windows Home may support Device Encryption only on qualifying hardware and configurations, so do not assume every system has the same options.
TPM-backed BitLocker is the preferred setup because the TPM helps protect the keys, but in some environments BitLocker can still be configured without TPM by using a startup key or password. Recovery keys need to be stored somewhere approved, like Active Directory, Microsoft Entra ID, Microsoft account escrow, Intune or another MDM store, or a secure offline escrow process. Verify status with manage-bde -status.
Know the difference between suspend and disable BitLocker. Suspending is usually temporary, like when you’re doing firmware updates or hardware changes; disabling actually decrypts the drive.
Secure Boot requires UEFI; it is not available in legacy BIOS mode. Its job is to help block untrusted or improperly signed bootloaders and other pre-OS components from loading. You can pair that with BIOS or UEFI passwords, a restricted boot order, and disabled external boot where it makes sense. Those firmware controls help, sure, but they’re still weaker than encryption because physical access can sometimes bypass or reset them depending on the hardware.
Scenario: if a laptop with client data is lost, the best answer is encrypted drive, recovery key escrow, credential reset as needed, and incident reporting. A password by itself just isn’t enough.
Session Lock, Shared PCs, and Removable Media
Workstations should lock themselves after inactivity and require sign-in again after sleep or wake. On shared systems, use accurate Windows controls such as automatic screen lock, sign-in requirements, Shared PC settings, or Assigned Access/kiosk mode where supported. “Auto-logoff” is not the standard answer unless a centrally managed session policy is actually in place.
Shared front-desk, library, and classroom systems need a little extra love: standard user access, limited local storage, restricted browser changes, and cleanup between users so one person’s session doesn’t bleed into the next. On shared systems, turn off saved passwords and autofill. If it’s really a kiosk, Assigned Access is a much better fit than pretending it’s just a normal desktop.
Removable media is another everyday risk people tend to forget about. Where policy calls for it, disable or restrict AutoRun and AutoPlay, scan USB media before opening anything, and use approved encrypted removable storage like BitLocker To Go when sensitive data has to move around. In managed environments, policy may block unauthorized USB storage altogether.
Browser Hardening, Remote Access, and Wi-Fi
Browsers are a huge attack surface, no question. Keep browser extensions to a minimum, remove anything suspicious, and leave SmartScreen or your browser’s safe-browsing features turned on. In managed environments, extension allowlists and browser policies are often the right answer. Be careful with macros, weird file associations, and those “free utilities” people download from wherever they happen to land.
For remote support and remote access, know the difference between Quick Assist, Remote Assistance, RDP, VPN-based access, and third-party remote tools. If RDP is used, require Network Level Authentication, limit which users can log on remotely, and avoid exposing RDP directly to the internet. VPN, RD Gateway, zero-trust access, or a managed support tool is usually the smarter route.
For Wi-Fi, prefer WPA3 when available; otherwise use WPA2-AES. Stay away from WEP and the older insecure modes. Forget untrusted SSIDs, turn off auto-connect to unknown networks, and use the Public firewall profile when you’re on untrusted Wi-Fi. A VPN helps, but it only helps as much as its setup allows—things like split tunneling, DNS handling, and authentication strength still matter.
Backups, Recovery, and Incident Response
Backups belong in workstation security because they soften the blow from ransomware, user mistakes, bad updates, and hardware loss. But let me be clear: sync isn’t backup, and restore points aren’t a backup for user data. A restore point can roll back system state, but it doesn’t replace a real file backup.
A solid mental model is 3-2-1: several copies, different media, and at least one copy kept isolated or offline. That matters because ransomware can still reach and encrypt backups or synced files that are online and accessible. For workstations, you want file backup, versioning, recovery media, and the occasional restore test so you know the process actually works.st so you know it actually works. A backup you’ve never tested is just a nice idea until the day you need it.
If you think a workstation may be compromised, follow a simple response flow: isolate it from the network if needed, protect the important data, scan for persistence, reset affected credentials, patch the system, and restore from a known-good backup—or reimage it if you can’t trust it anymore.
Exam Strategy and Security Baseline Review
CompTIA often tests distractors built around convenience. Some of the classic wrong answers are turning off the firewall, disabling antivirus, giving local admin rights, using a shared admin account, or skipping encryption because “there’s already a password.” Those are tempting because they are fast. They are wrong because they remove protection.
When you’re working through a scenario, ask yourself:
- What’s actually at risk here: the account, the data, the device itself, or network access?
- Is the threat coming from the local machine, the network, a physical exposure, or user behavior?
- What is the narrowest secure fix?
- Which protection must remain enabled?
Baseline verification checklist:
- Standard user for daily work; separate admin account for elevation
- Windows Update working; apps and browser supported and current
- Microsoft Defender Antivirus active; SmartScreen and tamper protection reviewed
- Microsoft Defender Firewall enabled on all profiles with only necessary exceptions
- BitLocker or Device Encryption enabled where supported; recovery key escrowed
- Automatic screen lock and sign-in after sleep configured
- Browser extensions minimized; shared PCs do not save passwords
- Backups validated; sync not mistaken for backup
Console recognition for the exam: whoami, gpresult /r, manage-bde -status, net localgroup, wf.msc, secpol.msc, eventvwr.msc, and msinfo32.
If you can look at a workstation problem and say, “Here is the risk, here is the safest narrow fix, and here is how I would verify it,” you are thinking exactly the way Core 2 wants you to think.