Hardening is the process of reducing a device's attack surface by turning on protective settings, removing weak defaults, and limiting what an attacker can do if the device is lost or compromised, and it matters because most real-world breaches start with simple gaps like no lock screen, weak authentication, or unprotected storage. For CompTIA A+ Core 2 (220-1202), Domain 2.0, Objective 2.8 (Hardening techniques), you're expected to recognize these gaps fast, choose the right control, and explain why it fits the scenario, which is also the same thinking you'll use on the job. This post focuses on four areas you'll see often in questions and in daily support work: device encryption to protect data at rest, screen locks (types) to control access when a device is unattended, biometric vs knowledge-based locks to weigh convenience against risk and recovery needs, and configuration profiles to apply secure settings at scale. Along the way, you'll get practical examples that match common environments, such as a phone used for email and MFA, a laptop that travels between home and campus, and shared devices in a front desk or lab. By the end, you should be able to map each hardening choice to a clear goal, protect user data, and pick the best answer under exam time pressure.
Hardening Basics
For CompTIA A+ Core 2 (220-1202), Domain 2.0, Objective 2.8, hardening means making a device harder to misuse or break into by reducing weak entry points and enforcing safer defaults. The goal is simple: protect data at rest, limit unauthorized access, and reduce the damage if an account, device, or network connection gets compromised. In practice, hardening focuses on two things you can control today, settings and exposure. When you remove what you do not need and lock down what you must keep, you give attackers fewer chances to succeed.
Hardening also protects against everyday risks, not just advanced attacks. A lost laptop, a shared tablet at a front desk, or a phone left unlocked in a classroom can all lead to data exposure. Good hardening assumes mistakes will happen, so it builds in barriers that still work when users get busy.
Attack surface in simple terms: fewer ways in, fewer ways to fail
Think of the attack surface as every door, window, and spare key to a system. The more openings you leave, the more likely someone finds one that works. Many openings are not dramatic; they are routine defaults that no one revisits after setup.
Here are easy examples that show up in real support work:
- Open ports and services: If a device runs remote access services that no one uses, it offers an extra path for probing and brute force attempts.
- Unused accounts: Old local accounts, shared logins, and forgotten admin users create extra identities an attacker can target.
- Auto-login: Convenience features can turn a stolen device into an open book, especially for email, saved passwords, or company apps.
- Unlocked screens: A device left unattended for two minutes is still unattended, and casual access is often enough to cause harm.
A strong hardening habit is to apply least privilege. In plain terms, each user and each app should have only the access required to do the job, and nothing more. Standard users should not run daily tasks as admins. Similarly, apps should not have permissions they never use, such as location access for a basic note tool. This reduces the impact of malware, mistakes, and misuse.
Default settings deserve extra caution because vendors often ship products to be easy to start, not strict to protect. Defaults may include simple PIN rules, permissive sharing settings, broad app permissions, or features enabled "just in case." Attackers know these defaults well, so leaving them unchanged can turn a common device into an easy target.
To keep your decisions consistent, use a short mindset checklist. It helps you choose controls quickly without getting lost in options:
- Remove what is unnecessary (apps, accounts, services, auto-login).
- Restrict what must remain (ports, permissions, admin rights).
- Require proof of identity (strong screen locks, MFA where possible).
- Record key events (logs, audit trails, device management reporting).
Hardening is less about adding tools and more about removing weak paths and enforcing basic controls consistently.
What the exam expects you to recognize for Objective 2.8
Objective 2.8 questions often test whether you can match a hardening tool to a practical goal. The exam also expects you to choose the best option in a scenario, not just an option that works. That means you should think about ownership (personal vs company-owned), the setting (shared vs single user), and the risk (lost device vs curious coworker).
Here is how the listed items map to real outcomes:
- Device encryption: Protects data at rest if someone steals the device or removes the drive. Encryption matters most when the attacker has physical access because it prevents easy offline data reading.
- Screen locks: Prevent casual access when a device is unattended. A lock with a short timeout reduces exposure in offices, classrooms, and front desks.
- Facial recognition: Improves ease and speed, so users are more likely to keep a lock enabled. However, you still need a backup method because cameras can fail, lighting can be poor, and policies may require a fallback.
- Fingerprint: Similar benefit to face unlock, quick access with less typing. Still, you must plan for backup access and align with policy for sensitive roles.
- PIN codes: A strong, non-trivial PIN offers a good balance of security and usability, especially on mobile devices. Longer PINs reduce guessing success.
- Pattern: Often easier to use, but also easier to observe and smudge-trace. It can be acceptable in low-risk cases, but it is weaker than a strong PIN in many environments.
- Swipe: Provides minimal protection. It blocks accidental taps, not intentional access, so it rarely meets business security needs.
- Configuration profiles: Enforce settings at scale, such as encryption requirements, password rules, screen lock timeouts, and app restrictions. This matters when you manage many devices and need consistent compliance.
Scenario framing is a common exam trick. A "lost phone" points toward device encryption plus a strong lock method. A "shared tablet" points toward strict screen lock rules and configuration profiles to prevent users from changing settings. A "company-owned laptop" usually implies policy enforcement, so encryption and centrally managed settings become the safest choice.
When you read an Objective 2.8 question, tie each option back to the outcome it provides. If the outcome is "protect data after theft," encryption should rise to the top. If the outcome is "stop walk-up access," screen locks and timeouts should lead. If the outcome is "make every device comply," configuration profiles are often the best fit.
Device Encryption
For CompTIA A+ Core 2 (220-1202), Domain 2.0, Objective 2.8, device encryption is a core hardening control because it protects data at rest when a laptop or phone goes missing. Encryption turns readable files into ciphertext, so a thief can't simply pull the drive, boot from a USB, or mount storage and browse documents. In practice, encryption works best when you pair it with a strong screen lock and a clear recovery plan, because encryption alone doesn't fix weak access controls.
Full-disk encryption vs file-based encryption and when each helps
Full-disk encryption (FDE) protects almost everything on the drive when the device is powered off. That includes the operating system, apps, swap space, and most user files. If someone steals the device, FDE blocks offline attacks such as removing the drive and reading it in another computer. This is why FDE is the default answer for "lost laptop" scenarios on exams.
File-based encryption (FBE) encrypts specific files, folders, or user profiles, often tied to a user sign-in. It commonly protects user data (documents, photos, email caches) and app data (app storage tied to a user). On shared systems, FBE can isolate one user's data from another. On mobile devices, FBE often works with hardware keys and the lock screen, so app data stays protected until the user unlocks.
The comparison below helps you match the control to the risk:
| Feature | Full-disk encryption (FDE) | File-based encryption (FBE) |
|---|---|---|
| Best for | Lost or stolen devices | Protecting specific users, apps, or folders |
| Protection when powered off | Very strong, covers most data | Strong for encrypted files, other areas may remain readable |
| Multi-user separation | Limited by design | Often strong, each user's data can be isolated |
| Common failure mode | Weak pre-boot PIN or poor recovery handling | Files saved outside protected locations |
Encryption also has clear limits. It doesn't stop malware that runs after the device is unlocked. It also doesn't fix weak accounts, such as shared passwords or no screen lock. Once an attacker gets legitimate access, encryption no longer blocks reading your files.
Treat encryption like a safe. It protects what's inside when it's locked, not when you leave it open.
Recovery keys, escrow, and the risk of locking yourself out
Encryption creates a new risk: you can lock out the rightful owner. A recovery key (or recovery code) is the backup method that restores access when the normal unlock path fails.