2.0 Security

Data at rest encryption protects stored information when a device is powered off, lost, stolen, removed from the building, or accessed without authorization.

Workstation hardening starts with protecting the data that lives on the device. A laptop, desktop, external drive, USB flash drive, or SD card can contain business records, passwords, cached email, customer data, HR files, financial information, saved browser data, project documents, and personal information. If that device is lost or stolen, the operating system password alone may not be enough to protect the files. An attacker may remove the drive, boot another operating system, or connect the storage to another computer.

Encryption changes that risk. When data is encrypted, the information is unreadable without the correct key, password, recovery key, TPM-backed unlock process, or authorized account. The device may still be missing, but the data is much harder to expose. For Objective 2.7, the key idea is simple: if sensitive data is stored, it should be secured.

Encrypt the Entire Device

Full-disk encryption protects the whole operating system drive. Instead of encrypting only one document or one folder, it protects the operating system, applications, user profiles, temporary files, cached files, paging files, hibernation files, and stored documents together. This matters because sensitive data often appears in more places than users realize.

If a laptop is lost, full-disk encryption helps prevent offline attacks. Without encryption, someone may remove the drive and read files from another system. With encryption enabled, the drive contents remain protected unless the attacker can unlock the key. This is why full-disk encryption is especially important for mobile workstations, executives, field users, technicians, shared office devices, and any computer that stores regulated or confidential information.

Common full-disk encryption tools include BitLocker on Windows, FileVault on macOS, and LUKS on Linux. The specific tool depends on the operating system and organizational policy, but the security principle is the same: protect the whole device so stored data remains unreadable without authorization.

Full-disk encryption should be verified, not assumed. A technician should confirm encryption is enabled, confirm the correct drive is protected, check whether the device is fully encrypted or still encrypting, and verify that recovery information is stored safely. A checkbox that says encryption is available is not the same as a protected device.

Encrypt Specific Files and Folders

Sometimes a scenario calls for protecting only certain information. A workstation may store a sensitive finance folder, HR documents, legal files, password exports, tax records, or personal data that needs extra control. File and folder encryption can add protection for specific items without encrypting every drive in the same way.

File-level encryption is useful when sensitive data must be shared securely, stored in a specific directory, or protected separately from the rest of the system. For example, an accounting folder may need stronger access control than general documents. A technician should match the control to the data: broad device risk points to full-disk encryption, while extra-sensitive folders may justify file or folder encryption as an additional layer.

Be careful with file movement and sharing. Encrypted files may lose protection if copied to an unsupported location, exported incorrectly, emailed without protection, or moved to a file system that does not preserve encryption. Users should understand how encrypted files behave before relying on them for sensitive workflows.

Do Not Forget Removable Media

Removable media is easy to lose and easy to overlook. USB flash drives, external HDDs, external SSDs, SD cards, and portable storage devices often carry exactly the kind of data that should be protected: backups, exports, transfer files, reports, install packages, user profiles, or temporary project data. If removable media is unencrypted, losing the device can become a data breach.

External drives should be treated like sensitive endpoints. Use built-in encryption or trusted tools approved by the organization. BitLocker To Go is one example in Windows environments. The exact tool matters less than the control outcome: if portable media carries sensitive information, it should be encrypted and managed.

Removable media policy should also address when portable storage is allowed, what data may be copied, how drives are labeled, where they are stored, and what happens if one is lost. Encryption reduces impact, but it does not remove the need for good handling practices.

Back Up Encryption Keys

Encryption protects data by making it unreadable without a key. That also means losing the key can lock out legitimate users. No key, no access. A secure recovery plan is part of encryption, not an optional extra.

Recovery keys should be stored securely and separately from the device. In business environments, recovery keys may be backed up to Active Directory, Azure AD, an endpoint management platform, or another centralized key-management system. In smaller environments, the key may need to be stored in a password manager, secure vault, or documented recovery process approved by the owner.

Do not store the recovery key in the laptop bag with the encrypted laptop, on a sticky note attached to the device, or in an unprotected text file on the same computer. That defeats the purpose. Recovery keys must be accessible to authorized people when needed, but protected from everyone else.

Scenario Cues

• Lost or stolen laptop: full-disk encryption protects stored data from offline access.
• Sensitive finance, HR, legal, or personal files: use file or folder encryption where extra protection is needed.
• USB drive or external disk used for transfers: encrypt removable media before storing sensitive information on it.
• User cannot unlock encrypted data: locate the recovery key through the approved key-management process.
• Recovery key stored with the device: move it to a secure, separate location because the current handling defeats the control.
• Enterprise environment: consider integration with Active Directory or centralized key management.

Exam Mindset

For Core 2, data-at-rest questions usually ask how to protect stored information if the device is lost, stolen, or accessed offline. The best answer is often encryption, especially full-disk encryption for entire devices and removable-media encryption for USB or external drives. If the question focuses on only a specific sensitive file set, file or folder encryption may be the better fit.

Watch for recovery-key clues. If the user or organization enables encryption but loses recovery keys, the data may be protected even from its rightful owner. A complete answer includes secure recovery key backup, not just turning encryption on.

Passwords are more than a login step; they are one of the first controls protecting users, devices, accounts, and stored data from unauthorized access.

Workstation hardening includes making authentication harder to guess, harder to reuse, and harder to abuse. A weak password can undermine otherwise strong security controls because it gives an attacker a direct path into the account. Once an attacker signs in as a valid user, the activity may look normal at first: files open, email works, applications launch, and network access may be granted based on that user's permissions.

A good password strategy combines strong password creation, password lifecycle rules, unique credentials, default password replacement, and user habits that reduce mistakes. The goal is not to make passwords annoying for their own sake. The goal is to reduce the chance that a guessed, reused, leaked, or factory-default password becomes the reason a system is compromised.

Build a Strong Password

A strong password is difficult for another person, automated tool, or password-cracking attack to guess. Complexity helps because it increases the number of possible combinations an attacker must try. A strong password may include uppercase letters, lowercase letters, numbers, and special characters. However, complexity alone is not enough if the password is short, predictable, or based on personal information.

Length is one of the most important factors. An eight-character minimum is a common baseline, but longer passwords are usually stronger, especially when they are not based on obvious patterns. A password such as a short word with a number at the end may technically meet a complexity rule, but it can still be easy to guess or crack. A longer passphrase, using several unrelated words or a memorable phrase with variation, can be both stronger and easier for a user to remember.

Users should avoid names, birthdays, pet names, team names, dictionary words, keyboard patterns, company names, seasonal words, and predictable substitutions. Attackers know that people often choose passwords like "Summer2026!" or "Password123!" because those formats are easy to remember. Unfortunately, they are also easy to test.

A better password or passphrase uses length, variety, and unpredictability together. For example, the infographic's stronger-password idea uses a mix of words, symbols, numbers, and capitalization. The exact password should not be reused, but the pattern is useful: longer, more varied, and less predictable is harder to guess.

Understand Password Lifecycles

Password lifecycle settings control how passwords are created, changed, reused, and retired. These settings are usually managed through local security policy, directory policy, identity provider settings, or a device management platform. For a technician, the key is to understand what each setting accomplishes and when it might appear in a scenario.

Password age tracks how long it has been since the password was last changed. This helps administrators understand whether credentials are current or stale. If an account has used the same password for years, the risk increases because that password may have been shared, reused, exposed in a breach, or known by former employees.

Password expiration forces a password to stop working after a set amount of time, such as 30, 60, or 90 days. After expiration, the user must set a new password before continuing. Some high-security environments may require more frequent changes, such as every 15 days or weekly, depending on policy and risk. The purpose is to reduce how long a compromised password remains useful.

Password history prevents users from cycling back to old passwords. Without password history, a user might change a password from Password1 to Password2 and then immediately return to Password1. History rules force the user to choose something new, which helps prevent lazy reuse and makes credential rotation more meaningful.

Lifecycle settings must be balanced with usability. Rules that are too weak expose the organization. Rules that are too frustrating can push users toward unsafe behavior, such as writing passwords down or reusing predictable patterns. Good policy supports both security and realistic user behavior.

Replace Default Credentials

Default usernames and passwords are a major workstation and device-hardening concern. Many devices, applications, routers, printers, management consoles, and services ship with factory-default credentials. Attackers know this and maintain lists of common defaults. If a device is deployed with default credentials still active, it may be vulnerable even if the rest of the environment appears well configured.

Changing default usernames and passwords should be part of setup, not an afterthought. This applies to local administrator accounts, network devices, BIOS or UEFI management interfaces, application admin panels, service portals, and any system that ships with a known login. A technician should never assume that a device is secure simply because it is new.

Trusted vendor documentation can help identify default credentials, setup requirements, and recommended password changes. This is especially useful when configuring devices that are less familiar, such as specialty office equipment, embedded systems, or vendor-managed tools. The important point is to replace factory defaults before someone else tries them.

Use Unique Passwords

Password reuse turns one compromise into many compromises. If a user uses the same password for email, a workstation, a cloud service, and a personal account, one leaked password may give an attacker multiple doors to try. Even a strong password becomes risky if it is reused across different systems.

Unique passwords limit damage. If one site or service is breached, the stolen password should not unlock the user's workstation, email, banking, VPN, administrator portal, or business applications. This is one reason password managers are often recommended: they make it easier to use long, unique passwords without expecting users to memorize every one.

For Core 2 scenarios, look for language about the same password being used everywhere, a user reusing a previous password, or multiple accounts being compromised after one password leak. The best control usually involves unique passwords, password history, stronger policy, user education, and sometimes MFA depending on the scenario.

Avoid Common Password Mistakes

Short passwords are easier to crack because there are fewer combinations to test. Single dictionary words are risky because password-cracking tools can test wordlists quickly. Personal information is risky because attackers may learn it from social media, public records, company websites, or previous breaches. Reused passwords are risky because a password exposed in one place can be tried somewhere else.

Users may not choose weak passwords because they are careless; they often choose them because they are trying to remember too many logins. Good technical controls should be paired with good user support. Password managers, clear password requirements, MFA, account lockout policies, and practical training all help users make safer choices without relying on memory alone.

Scenario Cues

• User keeps choosing short passwords: enforce minimum length and encourage passphrases.
• Password uses a name, birthday, or common word: require less predictable passwords and educate the user on guessing risks.
• User reuses the same password across accounts: require unique passwords and consider a password manager.
• User changes a password and then changes it back: configure password history.
• Account password is very old: review password age and expiration policy.
• New device or application still uses factory login: change default usernames and passwords immediately.
• Critical or high-security system: stronger lifecycle rules, shorter expiration windows, MFA, monitoring, and stricter access controls may be appropriate.

Exam Mindset

On the exam, password questions often test the difference between password length, complexity, history, age, expiration, reuse, and default credentials. Read the scenario carefully. If the issue is a password that is easy to guess, think length and complexity. If the issue is a user returning to an old password, think password history. If the password has not changed in too long, think password age or expiration. If a device ships with a known login, think default credentials.

The best answer should reduce unauthorized access without creating unnecessary disruption. Strong passwords, unique passwords, and proper lifecycle settings make accounts harder to compromise and make the entire organization more resilient.

BIOS and UEFI security protects the foundation of the workstation by controlling who can change startup settings and who can boot the device.

Before an operating system loads, the computer relies on firmware. On modern systems, that firmware is usually UEFI; on older systems, it may be BIOS. This firmware controls low-level hardware behavior, startup options, boot order, enabled devices, security settings, and sometimes virtualization or TPM-related features. If an attacker can change those settings, they may be able to bypass protections that the operating system depends on.

Workstation hardening is not only about what happens after Windows, macOS, or Linux starts. It also includes protecting the startup process. A secure startup helps keep everything else more secure because it reduces the chance that someone can boot from unauthorized media, tamper with hardware settings, disable security options, or access the device without permission.

Administrator Password

A BIOS/UEFI administrator password, sometimes called a supervisor password, protects the firmware setup utility. This password blocks unauthorized users from changing BIOS or UEFI settings such as boot order, enabled ports, security options, drive settings, virtualization options, and other hardware configuration choices.

This matters because firmware settings can weaken the whole workstation if they are changed carelessly or maliciously. For example, an attacker with physical access might try to change the boot order so the system starts from a USB drive. They might try to disable Secure Boot, alter device settings, or make configuration changes that help them bypass normal controls. An administrator password helps prevent those changes.

Only trusted administrators should know this password. It should be stored according to organizational policy, usually in a secure password vault or approved administrative credential system. If every technician uses the same undocumented firmware password from memory, the organization may lose track of who knows it. If no one stores it properly, recovery can become difficult when the device needs legitimate maintenance.

The administrator password does not usually stop the computer from booting for normal users. Its job is to protect settings. When a scenario says users should be able to use the workstation but should not be able to change boot options or firmware configuration, think BIOS/UEFI administrator or supervisor password.

User Password

A BIOS/UEFI user password controls who can start the computer. Instead of only protecting the setup screen, it requires a password before the system boots from the internal drive or another boot device. This adds a layer of defense before the operating system login screen ever appears.

A user-level firmware password can help protect against unauthorized use after physical theft, casual access, shared-space exposure, or attempts to start the computer from external media. It does not replace operating system authentication, disk encryption, or account security, but it can strengthen the startup path by adding another gate before the OS loads.

Use this control carefully. If a user password is lost, the device may become difficult to boot or service. Organizations should have a recovery process and should avoid relying on undocumented passwords. In managed environments, firmware controls may be set through endpoint management tools or vendor utilities so the settings are consistent and recoverable.

When a scenario says unauthorized users should be prevented from starting the computer at all, think BIOS/UEFI user password. When the scenario says unauthorized users should be prevented from changing setup options, think administrator or supervisor password.

Password Requirements

Firmware passwords should be required, not optional, when policy calls for them. An optional password is easy to skip, and skipped protection offers no security. Blank passwords are also unacceptable because an empty password gives the appearance of a control without actually protecting anything.

Automated logins should also be avoided. Auto-login may seem convenient, especially for kiosks, shared devices, labs, or single-purpose systems, but it bypasses authentication and gives an attacker a much easier path into the system. If the workstation needs to start automatically for a business reason, the configuration should be reviewed carefully and protected with compensating controls.

Firmware passwords should follow the same general security principles as other passwords: they should be strong, documented securely, limited to authorized staff, changed when needed, and managed consistently. If every system has a different firmware password with no central record, support becomes painful. If every system has the same password forever and too many people know it, the security value drops.

Why Startup Security Matters

Startup security reduces the chance that a person with physical access can use the device in an unauthorized way. Physical access changes the threat model. Someone who can touch the computer may try booting from USB, accessing recovery environments, changing firmware settings, removing storage, or attempting offline attacks. BIOS/UEFI controls help limit those options.

These controls are strongest when combined with other hardening measures. Full-disk encryption protects data if a drive is removed. Secure Boot helps ensure trusted boot components are used. TPM-backed encryption can protect keys. Firmware passwords restrict tampering. Operating system passwords protect accounts. Each control covers a different part of the startup and access chain.

A secure start does not solve every problem, but it makes the workstation harder to misuse. Security starts at power-on, and firmware controls help protect the rest of the system before the operating system even has a chance to defend itself.

Scenario Cues

• User should not change boot order: set a BIOS/UEFI administrator or supervisor password.
• Unauthorized person should not boot the computer: configure a BIOS/UEFI user password.
• Device may be physically accessed by others: combine firmware passwords with disk encryption and normal OS authentication.
• Blank firmware password is configured: replace it with a strong password because blank passwords offer no protection.
• Auto-login is enabled for convenience: disable it unless there is a documented business need and compensating control.
• Attackers might boot from external media: protect firmware settings and review boot order, removable boot options, and Secure Boot settings.

Exam Mindset

For Core 2, BIOS/UEFI security questions usually focus on matching the control to the risk. If the risk is unauthorized firmware changes, the answer is usually an administrator or supervisor password. If the risk is unauthorized startup, the answer is usually a user password. If the scenario mentions blank passwords or automated logins, the best answer is to remove the shortcut and require real authentication.

Do not confuse firmware passwords with operating system passwords. A Windows, macOS, or Linux login protects the OS account. A BIOS/UEFI password protects the startup environment or firmware settings before the OS takes over. Strong hardening uses both where appropriate.

Workstation hardening is not only a configuration checklist; it also depends on everyday habits that protect devices, screens, passwords, and personal information.

Security controls work best when users support them through simple, repeatable behavior. A locked screen, a secured laptop, careful handling of personal information, a privacy filter, and a password manager may seem ordinary, but together they reduce many common risks. Attackers often look for easy opportunities: an unattended workstation, a visible screen, a forgotten laptop, a reused password, or personal information shared too freely.

For Objective 2.7, these habits connect user behavior to workstation hardening. The goal is to make secure actions normal enough that users do them without needing a crisis first. Small actions make a big difference because they close the everyday gaps that technical controls alone may not cover.

Lock Your Workspace

A screen lock requires a password, PIN, biometric factor, smart card, or other approved authentication method before someone can use an unattended workstation. This protects an active session when the user steps away. Without a screen lock, a person with physical access may be able to read email, open files, send messages, access applications, change settings, or copy information while appearing to act as the signed-in user.

Automatic locking is especially important because it does not depend on perfect memory. A device can lock itself after a period of inactivity, reducing the risk when a user is pulled into a conversation, leaves for a meeting, or forgets to press the lock shortcut. The timeout should match organizational policy and the sensitivity of the environment. A public-facing workstation may need a shorter timeout than a private office workstation.

Physical device security matters too. Laptops, tablets, phones, removable drives, and other portable devices are easy to leave behind or steal. Users should lock devices when not in use, keep them with them while traveling, avoid leaving them visible in vehicles, and store them securely. If a device walks away, the data may walk away with it unless controls such as encryption, screen locks, and tracking are in place.

Protect Personal Information

Personal information is valuable. Names, addresses, phone numbers, Social Security numbers, birth dates, account numbers, employee identifiers, and other personal details can be used for identity theft, social engineering, account recovery abuse, phishing, or impersonation. Users should share sensitive information only when necessary and only through approved channels.

Protecting personal information also means being aware of surroundings. Shoulder surfers may watch what a user types, read a screen from behind, glance at documents on a desk, or observe badge information. This is especially common in public places such as airports, coffee shops, classrooms, shared offices, lobbies, trains, and customer-facing work areas.

Privacy screens can help reduce visual exposure by narrowing the viewing angle of a monitor or laptop display. They are not perfect, but they make it harder for nearby people to read the screen. This is useful for users who work in open offices, travel frequently, handle customer data, or use laptops in public spaces.

Screen position also matters. A monitor facing a hallway, window, waiting area, or high-traffic path exposes more information than one positioned away from view. Users should place displays so sensitive data is not easily visible to others. Good physical layout is a security control in its own quiet way.

Use a Password Manager

Password managers help users create and store strong, unique passwords without needing to memorize every login. This matters because secure password habits are difficult at human scale. Most users have many accounts, and expecting them to remember a different long password for each one leads to shortcuts, reuse, weak patterns, or written notes.

A password manager stores passwords in an encrypted database and can organize credentials by account, application, website, or category. Many password managers can generate random passwords, fill login forms, identify reused passwords, and sync securely across approved devices. Some also support multi-factor authentication, shared vaults, administrative recovery, policy enforcement, or enterprise reporting.

Different accounts should use different passwords. If a shopping site, personal email account, cloud service, or work application is breached, a unique password helps keep that breach from spreading to other accounts. Reuse is convenient, but it creates a chain reaction: one exposed password can unlock many unrelated systems.

Many operating systems and browsers include built-in password manager features, and organizations may provide enterprise password managers with centralized control. Enterprise tools are often better for business environments because they can support policy management, account recovery, team sharing, auditing, and user offboarding.

What Good Habits Prevent

Everyday habits reduce both accidental exposure and intentional abuse. A locked workstation prevents casual access. A secured laptop reduces theft risk. Privacy practices protect sensitive information from nearby observers. Password managers reduce weak and reused credentials. Together, these habits make users safer wherever they work.

These practices are especially important in hybrid and mobile work environments. Users may move between home, office, customer sites, public spaces, and travel locations. Security habits need to travel with them. The same user who locks a workstation at the office should also lock a laptop at a hotel, use a privacy screen in an airport, and avoid exposing customer data in a public area.

Scenario Cues

• User walks away from an unlocked workstation: enable screen lock and automatic lock timeout.
• Laptop is often left unattended: require physical security habits, encryption, screen locking, and approved storage.
• User handles sensitive data in public: recommend a privacy screen and better screen positioning.
• People can see monitors from a hallway or waiting area: reposition screens or use privacy filters.
• User reuses passwords because there are too many to remember: use a password manager and unique passwords.
• Business needs credential sharing or recovery: use an enterprise password manager instead of informal sharing.
• User shares personal information too easily: reinforce data-handling rules and social engineering awareness.

Exam Mindset

On the exam, everyday-habit questions often use practical clues. If the problem is an unattended signed-in workstation, the answer is usually locking behavior or automatic screen lock. If the problem is someone viewing information over a shoulder or from a nearby area, think privacy screen, screen position, or awareness. If the problem is password reuse, weak passwords, or too many passwords to remember, think password manager.

Choose the control that directly reduces the described risk. Do not overcomplicate a simple physical or behavioral problem. Sometimes the best hardening step is a configuration setting; sometimes it is a habit that keeps the configured protections from being bypassed in daily use.

Good account security means the right people have the right access at the right time, and unused or excessive access is removed before it becomes a risk.

Workstation hardening is closely tied to account management. Even a well-patched, encrypted, and physically secured workstation can become vulnerable if users have more access than they need, if old accounts remain active, if default credentials are still in use, or if login rules allow activity at unusual times. Account controls reduce risk by limiting what each account can do and when it can do it.

The main principle is least privilege: give each user only the access required to do their job. More access than necessary creates unnecessary risk. If an account is compromised, the attacker inherits that account's permissions. A standard user account limits damage; an unnecessary administrator account can turn a small incident into a major breach.

Give Access With a Purpose

Not every user needs administrative rights. Administrative access should be limited to people who truly need it, and even then it should be used carefully. Users who need to browse the web, read email, create documents, run standard business applications, or access shared files usually do not need local admin rights for daily work.

Limiting administrative rights helps prevent accidental changes, unauthorized software installation, malware persistence, security control tampering, and configuration drift. If malware runs under a standard user account, it may be limited in what it can change. If it runs under an administrator account, it may be able to install services, change security settings, disable tools, or affect other users.

Permissions should be based on job responsibilities. A finance user may need access to accounting folders but not HR files. An HR user may need employee records but not engineering repositories. A help desk technician may need certain support tools but not domain-wide administrative privileges. Access should match the role, not convenience.

Access reviews are part of good security hygiene. Users change roles, teams, locations, and responsibilities. Contractors finish assignments. Temporary projects end. Permissions that made sense six months ago may no longer be appropriate. Regular reviews help remove old access before it becomes a problem.

Manage Access at Scale With Groups

Managing permissions user by user becomes difficult as an organization grows. Group-based access simplifies administration by assigning permissions to groups, then placing users into the correct groups. Instead of updating every user individually, administrators manage roles such as HR, Finance, IT, Sales, Support, or Contractors.

Groups reduce mistakes because permissions are applied consistently. If the Finance group has access to a finance share, a new finance employee can be added to that group instead of manually assigning several folder permissions. If someone leaves finance, removing them from the group removes that access cleanly.

Role-based groups also make auditing easier. A reviewer can ask whether a user still belongs in the HR group or the IT support group rather than digging through many individual permissions. Group membership becomes a readable map of what the user can access.

Good group management still requires discipline. Groups should be named clearly, documented, reviewed, and aligned to real business roles. Nested groups and exceptions can be useful, but too many exceptions can make access hard to understand. The simpler the access model, the easier it is to manage securely.

Set Boundaries for Access

Access should fit the schedule and business need. Some accounts should only be usable during approved hours or from approved locations. Logon-hour restrictions can limit when an account is allowed to sign in, reducing the usefulness of stolen credentials after hours.

For example, a part-time worker, kiosk account, contractor, or temporary employee may only need access during specific business hours. If that account is used at midnight from an unusual location, the activity may be suspicious. Limiting logon hours helps prevent unauthorized or unusual activity and gives administrators another way to reduce risk.

Time-based controls are not a replacement for strong passwords, MFA, monitoring, or least privilege, but they add useful boundaries. Attackers often prefer to work when fewer people are watching. Restricting access outside approved times can make suspicious activity harder to hide.

Access boundaries can also include location, device compliance, VPN requirements, conditional access, and network restrictions, depending on the environment. For this module, the important concept is that access should be intentional, limited, and aligned to real operational needs.

Clean Up and Lock Down Accounts

Operating systems and applications often include extra accounts that may not be needed. Guest accounts, default administrator accounts, root accounts, mail accounts, service accounts, and system accounts should be reviewed. If an account is unnecessary, it should be disabled or removed. If it is required, it should be configured securely.

Unused accounts are dangerous because they may be forgotten by administrators but still useful to attackers. An old contractor account, a default admin account, or a dormant service account may provide access without drawing attention. Account cleanup reduces the number of doors an attacker can try.

Interactive logins should be disabled for service and system accounts when those accounts do not need a person to sign in with them. Service accounts should perform their service function, not act like normal user accounts. This reduces the chance that a service credential is used to log in directly and move through the environment.

Default usernames and passwords should be changed. Accounts such as admin/admin, administrator with a known password, root with a weak password, or vendor-default credentials are widely known and frequently tested. If an account is not needed, remove or disable it. If it is needed, rename it where appropriate, change the password, and protect it with strong policy.

Account expiration dates are useful for temporary users, contractors, seasonal workers, project accounts, and other short-term access. Expiration automatically disables the account after a specific date, reducing the chance that temporary access becomes permanent by accident.

Lock It Down

Automatic screen locking protects an active workstation session after inactivity or when the user steps away. This prevents someone nearby from using an already-authenticated session. Screen locking is a simple control, but it protects against a common real-world problem: unattended access.

Account lockout policies respond to failed login attempts. After a set number of incorrect passwords, the account can be locked or require additional action before more attempts are allowed. This helps slow brute-force attacks, password guessing, and repeated unauthorized login attempts.

Lockout settings must be chosen carefully. Too lenient, and attackers get many guesses. Too strict, and users may be locked out frequently or attackers may intentionally trigger lockouts to disrupt work. A good policy balances security, usability, monitoring, and support procedures.

Account expiration also belongs in the lock-down toolbox. Temporary access should have an end date. When new hires, role changes, terminations, offboarding, or contractor changes occur, account access should be updated quickly. Account management is not a one-time setup; it is an ongoing process.

Scenario Cues

• User has local admin rights but does not need them: remove admin privileges and apply least privilege.
• Permissions are managed one user at a time: use role-based groups to simplify access management.
• Temporary contractor needs access for a limited period: set account expiration and assign only required permissions.
• Account is being used after business hours: consider logon-hour restrictions and monitoring.
• Guest, default admin, root, or unused accounts exist: disable, remove, rename, or secure them according to policy.
• Service account is used for interactive login: disable interactive logon unless there is a documented need.
• Many failed login attempts appear: use account lockout policy, investigate the source, and monitor for brute-force activity.
• User walks away from an active session: configure automatic screen lock after inactivity.

Exam Mindset

For Core 2, account-access questions often test which control best limits risk without blocking legitimate work. If the user has too much access, think least privilege. If access management is messy, think groups. If access should only exist temporarily, think expiration dates. If logins should only happen during approved times, think logon-hour restrictions. If repeated password attempts are the clue, think account lockout.

Read carefully for whether the problem is permission scope, account lifecycle, login timing, failed attempts, or inactive accounts. The best answer usually reduces unnecessary access while preserving the user's ability to do their job.

Basic workstation hardening reduces attack surface by turning off features you do not need and changing the defaults attackers expect.

Many successful attacks do not require a brand-new exploit or a highly complex technique. They succeed because a system has unnecessary features enabled, unneeded services running, default credentials still in place, or automatic behavior that launches content before a user can evaluate it. Hardening starts by asking a practical question: what can this workstation do that it does not actually need to do?

Reducing attack surface means removing opportunities. Every automatic launch feature, running service, and known default account gives attackers something to test. The fewer unnecessary doorways a system has, the easier it is to defend, monitor, and maintain.

Turn Off AutoExecute and AutoRun

AutoExecute and AutoRun-style behavior allows programs to launch automatically when removable media is inserted. Historically, this was convenient for software installers, CDs, and USB devices. It was also dangerous because malware could use the same behavior to run without the user intentionally opening a file.

Older Windows systems were especially vulnerable to AutoRun abuse. A malicious USB drive could contain instructions that automatically started malware when connected. Modern supported Windows versions disable this kind of AutoRun behavior by default, and that protection should remain in place. Re-enabling it for convenience weakens the workstation.

On older systems, disabling AutoRun may involve policy settings or registry changes, such as controlling AutoRun behavior through configuration tied to files like autorun.inf. In modern environments, the best answer is usually to keep AutoRun disabled and avoid allowing removable devices to execute programs automatically.

This control is especially important in environments where users connect USB drives, external disks, cameras, phones, diagnostic tools, or vendor-supplied media. Removable media should be treated cautiously because it can carry malware, scripts, installers, or files from unmanaged systems.

Stop Automatic Play

AutoPlay is related to device convenience. When a USB drive, phone, camera, memory card, or other device is connected, AutoPlay can prompt the user to open files, import photos, launch an app, or take another action. Unlike the older AutoRun behavior, AutoPlay is usually more about presenting options than silently executing programs, but it can still create risk.

Attackers benefit when systems react automatically to connected devices. Even prompts and convenience actions can lead users toward unsafe behavior, especially if a device contains malicious files disguised as media, documents, installers, or shortcuts. Turning off AutoPlay keeps the user in control rather than letting the device steer the interaction.

In Windows, AutoPlay can be disabled in Settings under Bluetooth and devices, then AutoPlay. The safest configuration is to keep AutoPlay disabled for all device types unless there is a clear business reason to allow it. Users can still open trusted files manually after they verify what the device is and why it is connected.

The exam idea is simple: AutoRun and AutoPlay may be convenient, but workstation hardening favors control over convenience. If the question describes removable media launching actions automatically, disable the automatic behavior.

Remove Unneeded Services

Every running service is another process to patch, monitor, configure, and protect. Some services are required for the operating system or business applications. Others may be installed by default, enabled by older software, added by vendor tools, or left behind after an application is removed. Unneeded services increase risk because they may listen on the network, expose local functionality, or run with elevated privileges.

Removing or disabling unnecessary services reduces attack surface. If a service is not running, attackers cannot exploit that service directly. This also removes tools attackers might abuse after gaining access. For example, a service that allows remote access, file sharing, web administration, database connections, or device discovery may be useful in one environment and unnecessary in another.

Technicians should review services before disabling them. Some service names are unclear, and disabling the wrong service can break printing, networking, authentication, backups, security tools, or business applications. The safer process is to identify the service, confirm its purpose, check dependencies, review organizational standards, disable it in a controlled way, test the workstation, and document the change.

Less running means less risk, but only when changes are deliberate. Hardening is not randomly turning things off; it is removing what the workstation does not need while preserving required business functions.

Change Default Administrator Credentials

Default administrator usernames and passwords are well known and heavily targeted. Attackers routinely try common combinations such as admin/admin, administrator/password, root/root, vendor defaults, blank passwords, and predictable local admin passwords. If those credentials still work, the attacker does not need to break in; the system is effectively handing them a key.

Default administrative accounts should be renamed where appropriate, protected with strong unique passwords, and managed consistently across systems. Built-in administrator accounts should not use obvious names when policy supports renaming. Local administrator passwords should not be reused across every workstation because one exposed password could unlock many machines.

This applies to operating systems, routers, printers, firewalls, applications, management consoles, firmware interfaces, and specialty devices. Any system that ships with a known administrative account should be secured during setup. Default credentials are not secret; they are documentation that attackers can read too.

Organizations may use tools such as local administrator password management, endpoint management platforms, password vaults, or directory-based administrative controls to keep credentials unique and recoverable. The important principle is that default admin credentials must be changed on all systems and devices, not just the most visible ones.

Key Hardening Outcomes

These basic changes produce several security benefits. Disabling AutoRun stops unwanted programs from starting automatically. Turning off AutoPlay keeps control in the user's hands when devices are connected. Removing unused services reduces possible entry points. Changing default administrator credentials blocks a common first move for automated attacks.

Together, these controls reduce attack surface, prevent unauthorized access, and keep systems more secure. They are not glamorous controls, but they are dependable. Many incidents begin with something simple that was left enabled, unchanged, or forgotten.

Scenario Cues

• USB drive launches software automatically: disable AutoRun or AutoExecute behavior.
• Device connection opens prompts or apps automatically: turn off AutoPlay for connected devices.
• A workstation has services running that no one recognizes: review, identify, and disable unnecessary services after testing.
• A service is listening on the network but not needed: disable or remove it to reduce attack surface.
• Default administrator account still uses a known name or password: rename where appropriate and set a strong unique password.
• Same local admin password is used everywhere: implement unique local administrator passwords or centralized management.
• Older Windows system allows autorun.inf behavior: disable AutoRun through policy or supported configuration.

Exam Mindset

Core 2 hardening questions often ask for a straightforward risk-reduction step. If the clue involves removable media running something automatically, think AutoRun. If the clue involves Windows offering automatic actions when a device is connected, think AutoPlay. If the clue involves unnecessary background components, think services. If the clue involves widely known login information, think default administrator credentials.

The best answer usually removes an unnecessary path without breaking normal work. Hardening is the art of reducing what attackers can use while keeping what users actually need.

Objective 2.7 is about making workstations harder to misuse, harder to steal data from, and easier to manage securely through layered hardening choices.

The section connects several practical controls that work together. Encryption protects stored data. Password rules protect accounts. BIOS and UEFI settings protect the startup path. Everyday habits protect active sessions and visible information. Account management limits what users and attackers can reach. Basic attack-surface reduction removes unnecessary automatic behavior, services, and default credentials.

The exam mindset is to match the risk to the right hardening control. Do not choose a dramatic answer just because it sounds secure. Choose the control that directly addresses the scenario while preserving the user's ability to work.

Protect Data First

If the scenario involves lost laptops, stolen drives, removable storage, offline access, or sensitive files, think encryption. Full-disk encryption protects the entire device, including operating system files, user profiles, cached data, and documents. File and folder encryption adds extra protection for specific sensitive data. Removable media encryption protects USB drives, SD cards, and external storage that can be lost easily.

Encryption is only useful when recovery keys are handled correctly. A missing recovery key can lock out legitimate users, while a poorly stored key can defeat the protection. Store keys securely, separately from the device, and preferably in an approved centralized system when available.

Make Credentials Strong and Manageable

Passwords should be long, unique, and difficult to guess. Complexity helps, but length and unpredictability matter just as much. Users should avoid dictionary words, personal information, obvious patterns, reused passwords, and default credentials.

Password lifecycle settings support credential hygiene. Password age shows how long a password has been in use. Expiration forces a change after a defined period. Password history prevents users from returning to old passwords. A password manager helps users maintain strong, unique passwords without relying on memory or unsafe notes.

Secure the Startup Path

BIOS and UEFI protections matter because attackers with physical access may try to change boot order, start from removable media, disable security options, or tamper with firmware settings. An administrator or supervisor password protects setup changes. A user password controls who can boot the system.

Blank passwords, optional firmware passwords, and automatic logins create weak points. Startup security works best when paired with full-disk encryption, Secure Boot where applicable, and normal operating system authentication.

Build Everyday Security Habits

Hardening is not only configuration. Users also need habits that protect the workstation during normal work. Screen locks and automatic lockouts protect active sessions. Physical device security reduces theft and loss. Privacy screens and smart screen positioning reduce shoulder-surfing risk. Careful handling of personal information reduces social engineering and data exposure.

These controls are especially important for shared spaces, mobile workers, public locations, open offices, and customer-facing areas. A secure workstation can still leak data if the screen is visible, the session is unlocked, or the device is left unattended.

Control Access Deliberately

Least privilege is one of the most important account-hardening ideas. Users should have only the access they need to do their jobs. Administrative rights should be limited to users and tasks that truly require them. If an account is compromised, least privilege limits how much damage the attacker can cause.

Groups make access easier to manage at scale. Instead of assigning permissions one user at a time, assign users to role-based groups and apply permissions to those groups. Logon-hour restrictions, account expiration, account cleanup, disabled guest accounts, service-account restrictions, and lockout policies all reduce unnecessary access and make suspicious behavior easier to control.

Reduce Attack Surface

Attack surface reduction means turning off what the workstation does not need. AutoRun and AutoPlay can let removable media influence what happens when a device is connected, so disabling them keeps control with the user. Unused services should be reviewed and disabled when they are not needed. Default administrator credentials should be changed because attackers know and test common defaults.

Do not disable services randomly. Identify the service, understand its purpose, check dependencies, test the result, and document the change. Good hardening removes risk without breaking required business functions.

Scenario Decision Cues

• Lost or stolen device: choose full-disk encryption and secure recovery-key storage.
• Sensitive folder or removable drive: use file, folder, or removable-media encryption.
• Weak, reused, old, or default passwords: improve password policy, password history, uniqueness, and password-manager use.
• User can change boot settings: configure a BIOS/UEFI administrator or supervisor password.
• Unauthorized users can start the computer: configure a BIOS/UEFI user password.
• Workstation is left unlocked: enable screen lock and automatic lock after inactivity.
• Screen is visible to others: use privacy screens, awareness, and better screen positioning.
• User has excessive permissions: apply least privilege and role-based groups.
• Temporary account should not last forever: use account expiration and access reviews.
• Many failed login attempts occur: configure account lockout and investigate the source.
• USB media launches actions automatically: disable AutoRun or AutoPlay.
• Unneeded background components are running: remove or disable unnecessary services after review.

Common Exam Traps

One common trap is confusing similar controls. BIOS/UEFI administrator passwords protect settings; BIOS/UEFI user passwords control startup. Password expiration forces a change after time; password history prevents reuse of previous passwords. Full-disk encryption protects the whole device; file encryption protects selected data. AutoRun and AutoPlay both involve removable media, but AutoRun is about automatic execution while AutoPlay is about automatic actions and prompts.

Another trap is choosing convenience over security. Auto-login, blank passwords, default credentials, unnecessary admin rights, active guest accounts, and unused services may seem easier in the moment, but they increase risk. For workstation hardening, the stronger answer usually reduces unnecessary access, removes defaults, or disables unneeded behavior.

Technician Mindset

A good technician hardens systems without guessing. Identify the risk, choose the narrowest effective control, verify that the system still works, document the change, and review it over time. Security is stronger when people, process, and technology support each other.