CompTIA 220-1202: Endpoint, Browser, and SOHO Security

Security is 28% of the current CompTIA A+ Core 2 220-1202 exam and is written for an IT support role rather than a security architect. The domain covers physical and logical controls, Windows security settings, wireless and wired SOHO security, malware and social engineering, malware removal, workstation/mobile hardening, data destruction, and browser security. The broad Core 2 guides already cover the exam at a high level; the practical emphasis is on practical controls a support technician can configure, recognize, and verify.

Physical and logical controls protect different attack paths

Locks, badges, cameras, barriers, guards, and physical placement reduce unauthorized physical access. Logical controls such as least privilege, MFA, ACLs, Zero Trust concepts, and account policy govern digital access. A scenario can need both. A secure login does not protect an unlocked equipment room, and a locked room does not prevent compromised credentials from being used remotely.

Physical security controls should be matched to environment. A badge reader, equipment lock, camera, or secure placement has different value depending on the asset and threat. A+ scenarios are practical: protect the device or network equipment with an appropriate measure rather than assuming every control belongs everywhere.

Windows security settings should be treated as a baseline. Support technicians should recognize account and password settings, firewall configuration, updates, encryption, permissions, antivirus/endpoint protection, and basic host hardening. Endpoint hardening fundamentals organize those controls into a coherent baseline. The A+ task is to apply or verify an appropriate workstation control, not design an enterprise security platform.

SOHO wireless security begins with changing defaults

Change default administrator credentials, use modern Wi-Fi encryption, restrict management access, disable unnecessary features, review guest access, and keep router firmware current. The wireless networking fundamentals provides radio/authentication context. Physical router placement matters too; a reset button or exposed network equipment can bypass carefully chosen settings.

Guest wireless and internal wireless should have different trust expectations. Guest users usually need internet access, not access to local file shares, printers, or management interfaces. Verify isolation after configuring guest access. A guest SSID name alone does not guarantee segmentation.

SOHO firmware updates should be verified after installation. Confirm the router returns with intended configuration, internet access, wireless settings, and secure management. A firmware update can improve security while still causing service disruption if settings reset or compatibility changes.

Wired SOHO security includes ports, forwarding, and management. Unused services and ports should be disabled where practical. Port forwarding should exist only for a justified service and should map to the intended internal target. UPnP can create convenience at the cost of less explicit control. Content filtering, IP filtering, screened networks, and secure administration may also appear in scenarios. The technician should understand the risk created by each setting.

SOHO port forwarding should be reviewed like an exposure decision. A rule can make a service reachable from the internet and therefore changes the attack surface. Confirm the business need, internal target, required port, and whether a safer access method exists. Remove stale forwarding rules after the service is retired.

Social engineering is a support problem as well as a security problem

Phishing, impersonation, shoulder surfing, tailgating, baiting, and other social engineering techniques exploit people and process. A support technician should therefore follow identity-verification and escalation procedures rather than bypassing controls because a caller sounds urgent or authoritative.

Malware and social-engineering scenarios can overlap. A phishing message may lead to a malicious download, browser extension, credential theft, or remote-access tool. Do not treat removal and user education as separate worlds. Once the technical infection is remediated, address the entry path and any compromised credentials so the system is not immediately reinfected.

Keep escalation boundaries clear. A routine malware cleanup, lost device, suspicious certificate, or social-engineering attempt can cross into incident response when sensitive data, privileged accounts, widespread compromise, or legal requirements are involved. A+ technicians should recognize when the issue is no longer a normal help-desk ticket.

Malware removal should preserve evidence and prevent reinfection

Follow a controlled malware-removal process: identify symptoms, isolate when appropriate, update tools, scan/remove, address persistence or vulnerable software, re-enable/restore settings, and educate the user. Avoid wiping a device immediately when organizational policy requires evidence or specialized response. Confirm security tooling is healthy after cleanup.

Data disposal should preserve chain-of-custody or documentation where organizational policy requires it. If a drive is reused, sanitization differs from a drive that will be physically destroyed. If encryption keys are part of the sanitization approach, confirm the media was actually protected by the relevant encryption and that backup copies are handled separately.

Malware-removal workflow should include account risk. If malware may have captured credentials, cleaning the endpoint alone is incomplete. Follow organizational procedure for password reset, session revocation, MFA review, or escalation. The technical infection and identity compromise can continue independently after the initial event.

Security support should also preserve usability for legitimate users. After hardening, malware cleanup, browser changes, or SOHO configuration, confirm business applications, approved websites, printing/sharing, and remote access still work as intended. This distinguishes controlled security from indiscriminate blocking.

Workstation and mobile hardening reduces common exposure

Disable unnecessary features, keep systems patched, use secure authentication, encrypt where required, control application sources, restrict privileges, and apply MDM policy to managed mobile devices. Hardening should be appropriate to the support environment; a setting enforced by policy should be fixed at the management layer rather than repeatedly changed locally.

Mobile security can involve screen locks, biometrics, encryption, MDM, application source restrictions, remote wipe, and handling of lost devices. If a managed device is lost, the response is not merely “buy another phone.” Protect accounts and corporate data according to policy, then recover the user onto a replacement device safely.

Data destruction must match the storage and business requirement. Deleting a file or quick-formatting storage may not meet destruction requirements. Choose clearing, wiping, physical destruction, or another approved method based on media type, sensitivity, and reuse/disposal policy. Document the action where required. Security includes protecting data at the end of the device lifecycle.

Browser security combines configuration and user behavior

Core 2 includes browser features such as extension/plugin management, pop-up blocking, clearing data/cache, private browsing, proxies, secure DNS, trusted downloads, patching, certificate validity, and password managers. A browser problem can be security policy, extension behavior, cached data, certificate trust, or network proxy—not just a “bad website.”

Windows permission scenarios should distinguish share, file-system, and account privilege. A user can reach a computer but lack permission to a file, or have local administrator rights that create unnecessary risk. Apply least privilege and verify the effective result rather than granting broad access simply to make the error disappear.

Account security should include lockout, password practices, MFA where supported, standard versus administrator use, and disabling unused accounts. Support technicians often see the symptom first—a user cannot sign in—but need to determine whether the control is working as designed, whether identity needs recovery, or whether an attacker may have triggered the lockout.

Browser extensions deserve careful source validation because they run inside a high-value application where users authenticate to many services. Unexpected redirects, new search behavior, pop-ups, or permissions can indicate a malicious or unwanted extension. Remove suspicious software, patch the browser, review account sessions if credentials may be exposed, and confirm the browser operates normally afterward.

Windows security troubleshooting should distinguish policy from local configuration. A user may be unable to change a setting because Group Policy, MDM, or another management control enforces it. Repeatedly changing the endpoint is wasted effort and can create inconsistent state. Identify the source of enforcement and correct the intended management layer.

Browser certificate warnings should be investigated before users are told to click through them. Check system time, certificate validity, hostname, trust chain, proxy or inspection behavior, and whether is expected. A valid warning can indicate misconfiguration or attack, and bypassing it can defeat the control.

Remote support tools create security responsibilities. If remote access is permitted, use approved tools, authenticated sessions, least privilege, and clear user consent/visibility according to policy. Disable ad-hoc or persistent access that is no longer needed. Convenience should not create an unmanaged backdoor.

Verify the user can work after the control is applied

For the CompTIA 220-1202 exam, practice security as support: configure a secure SOHO router, harden a workstation, remove a suspicious extension, verify a certificate, recognize social engineering, and choose a data-disposal method. Then confirm the original business function still works. A control that blocks all legitimate use may be secure in theory but incomplete as a support outcome.

In final practice, combine a browser warning, suspicious email, endpoint hardening issue, and SOHO configuration into one support case. Decide what to isolate, what to verify, which credential or setting may be compromised, and what evidence proves safe recovery. This keeps the security domain focused on technician action rather than abstract policy language.

For final Core 2 practice, explain not only which security setting you would change but what risk it reduces and how you verify normal user function afterward. That simple habit keeps every answer grounded in support work rather than abstract security vocabulary.