System Vulnerabilities

A vulnerability is a weakness that can lead to harm, such as data loss, outages, or unauthorized access. In CompTIA A+ Core 2 (220-1202), Domain 2, Objective 2.5, you're expected to recognize common vulnerabilities and respond with practical first steps.

This matters in help desk and junior tech roles because these issues show up in everyday tickets and routine checks. A missed patch can turn into a malware cleanup, and an out-of-date system can fail an audit. Even when you don't "own" security, you're often the first person to spot risk and report it clearly.

In this section, you'll learn the five areas in the objective: non-compliant systems, unpatched systems, unprotected systems (missing antivirus or missing firewall), end-of-life (EOL) systems, and bring your own device (BYOD) risks. You'll also learn what each one looks like in the real world, from warning banners in management tools to users who bypass controls.

Finally, you'll get a simple triage approach: what to verify first, what evidence to capture, and when to escalate. That way, you can act fast without guessing or overcorrecting.

Everyday Vulnerability Causes

In CompTIA A+ 220-1202, Domain 2, Objective 2.5, a system becomes vulnerable when everyday habits and small misconfigurations pile up. In practice, that often means a device is non-compliant, unpatched, unprotected (missing antivirus or firewall controls), end-of-life (EOL), or loosely managed under BYOD rules. You do not need a scanner to notice the early warning signs. Most of the time, the first clues show up in the ticket text, the user's story, and a few basic checks you can do safely.

Quick signs something is wrong before you run tools

Before you run any utilities, treat the ticket like a short investigation. Start with what you can observe, then move to what you can verify. The goal is to spot common vulnerability patterns without making the situation worse.

A practical checklist to use on a ticket includes the following:

Unusual pop-ups: Repeated prompts, fake alerts, or "security" warnings that look out of place.
Slow boot or sudden lag: A device that used to start quickly now takes several minutes, or apps freeze often.
Unknown browser extensions: Toolbars, search changes, or add-ons the user does not recognize.
Disabled security settings: Antivirus turned off, firewall disabled, or tamper protection unexpectedly unavailable.
Repeated update failures: Windows Update errors, stalled patch installs, or constant rollback after restart.
Local admin rights without a need: Users who can install anything, especially on shared or standard workstations.

Once you see one or two signs, use an ask, check, confirm flow. It keeps you calm, consistent, and easy to audit later.

Ask (what changed?)
Ask what happened right before the issue started. Focus on simple triggers: new software, browser prompts, USB use, travel, Wi-Fi changes, or a password reset. Also ask if anyone else used the device. Small details often point to BYOD exposure, unapproved installs, or policy bypasses.
Check (basic settings first)
Verify the obvious items that map to Objective 2.5. Confirm the device reports the expected antivirus and firewall status, check whether updates are paused, and look for signs of EOL software that cannot patch. If the user has local admin, note it as a risk even if it is not the root cause.
Confirm (with logs or the management console)
Confirm what you found using a trusted source. That might be event logs for update failures, the endpoint management console for security status, or a patch dashboard for compliance. This step prevents guesswork and helps you document a clear escalation.

If the user reports pop-ups and you also see disabled protection, treat it as a security incident until proven otherwise.

Why "low risk" devices still matter

Spare laptops, shared kiosks, and old tablets feel harmless because nobody "stores data" on them. However, those devices often still authenticate to email, connect to Wi-Fi, or access shared files. That is enough for an attacker. In many environments, the weakest device becomes the easiest starting point.

Several everyday factors make these devices risky:

Patch gaps: Kiosks and spares miss regular update cycles because no one "owns" them day to day.
Unprotected configurations: Shared devices sometimes run with relaxed controls to reduce user friction.
EOL exposure: Older tablets or legacy kiosk software may not receive security updates at all.
Non-compliance drift: A device can fall out of policy, such as missing disk encryption, firewall rules, or required agents.
Credential proximity: Users often sign in quickly and forget to sign out, especially at shared stations.

Attackers like these targets because they provide quiet access. A kiosk in a lobby might sit untouched for weeks, so warning signs go unreported. After compromise, the attacker does not need to "hack the server" first. They can steal tokens, capture passwords through fake login prompts, or use the device as a stepping stone into internal systems.

Consider a short scenario: a shared front-desk kiosk runs an older browser and misses patches because it is "just for check-in." A user notices a minor slowdown but ignores it. Later, the kiosk shows a login prompt that looks normal, so staff enter their email password. The prompt is fake, and the credentials get sent out. Within hours, the attacker signs into webmail, resets a few passwords, and accesses shared files. The entry point was not a critical server, it was an unpatched, lightly monitored kiosk.

The takeaway is simple: classify devices by access and trust, not by how "important" they seem. If it can reach company services, it can create a vulnerability chain.

Non-compliant Systems

In CompTIA A+ 220-1202, Domain 2, Objective 2.5, a non-compliant system is a device that fails required security settings, even if it seems to work fine. Policies often look clear on paper, yet real devices drift over time. Users travel, updates fail, settings get changed during troubleshooting, and older hardware behaves differently after upgrades. As a result, compliance becomes less like a single switch and more like a set of guardrails that need constant checks.

Non-compliance also hides in plain sight. A laptop can browse the web and open email while still missing encryption or running with a weak login policy. That gap matters because security controls work together like layers of a seatbelt system. If one layer is missing, the impact of a mistake or attack grows fast.

Common compliance baselines you should recognize

Most organizations define a basic compliance baseline, which is the minimum set of security controls every endpoint must meet. These baselines often come from device management tools (for example, mobile device management) or from central policy settings on corporate networks. You don't need to memorize vendor names to be effective. You only need to recognize what "good" usually looks like.

Here are common baseline controls, stated in plain language:

Disk encryption enabled (laptops and desktops): BitLocker on Windows or FileVault on macOS, so lost devices don't leak data.
Secure Boot enabled: The device boots trusted software, which helps block certain rootkits.
Firewall turned on: Host-based firewall runs and applies the expected profiles (such as work vs public networks).
Antivirus or endpoint protection running: The agent is installed, active, and updated, not expired or disabled.
Updates enabled: Automatic updates are on, and the device is not paused for weeks.
Standard user accounts by default: Daily work happens without local admin rights unless approved.
Mobile device encryption on: Phones and tablets use built-in encryption, not optional "screen lock only."
Screen lock timers set: Auto-lock triggers after a short idle period, then requires sign-in.
Approved remote access tools only: Remote support uses company-approved tools, not random consumer apps.

A quick mental check helps: if a device is lost, stolen, or phished today, do these controls reduce damage? If the answer is "not really," the system likely falls out of baseline.

A policy is only real when the endpoint enforces it. Anything else is a suggestion.

How to respond without blaming the user

Non-compliance tickets often feel personal to users, especially when access gets blocked. Your job is to reduce risk while keeping the conversation calm and factual. Start from the policy requirement, not from assumptions about what the user did.

Use a simple response flow that you can repeat every time:

Verify the requirement: Confirm what the baseline expects for that device type. For example, some kiosks have different rules than laptops.
Gather evidence: Record what you see before you change anything. Capture key details such as error messages, security status screens, and the device's policy or management status.
Fix what you can safely fix: Re-enable the firewall, restart the security agent, trigger updates, or apply the correct settings if you have permission.
Escalate what needs approval: If the user needs admin rights, a remote access tool, or a policy change, route it to the right owner. Keep the request tied to business need and risk.
Document the outcome: Note what was non-compliant, what you changed, and what remains open. Clear notes prevent repeat tickets and help audits.

When you communicate, frame the issue like a safety rule. Say, "This device must meet the baseline to protect accounts and data," not "You disabled security." If you suspect a user changed something, stay neutral. Focus on facts you can prove, such as "encryption is off" or "updates are paused."

Exceptions happen, especially for legacy apps or lab devices. Handle them with discipline:

Get written approval from the policy owner.
Set a time limit for the exception.
Add a review date so it doesn't become permanent by accident.

That approach protects the organization, and it also protects the user from unclear expectations.

Unpatched Systems

In CompTIA A+ 220-1202, Domain 2, Objective 2.5, unpatched systems are a top cause of real security incidents because attackers often rely on known flaws, not magic tricks. When a device misses updates, it stays vulnerable to exploits that already have public write-ups and sometimes ready-made attack code. As a result, a single missed patch can turn a normal email click or website visit into malware, credential theft, or remote access.

Most attacks follow a simple pattern: the attacker scans for outdated versions, sends traffic that triggers the flaw, then drops a payload or steals a token. Think of patching like replacing worn locks. You can still close the door without it, but someone else may already have a key. Safe patch habits reduce that risk without creating avoidable outages.

The patching scope people forget: apps and firmware

Operating system updates matter, yet attackers often go after apps because people open them all day. Browsers, PDF readers, and Office tools handle untrusted content constantly. That makes them common entry points for drive-by downloads, malicious documents, and fake update prompts.