Logical Security

Logical security is the set of rules and tools that control who can access systems and data, it's not about doors, badges, or camera locks. In CompTIA A+ Core 2 (220-1202), Domain 2.0, Objective 2.1, you're expected to explain how access gets granted, checked, and limited across common business systems.

This matters in day-to-day help desk work because most tickets involve access in some form. You might reset a password, enroll a user in MFA, remove someone from a group, or confirm why an app denies access. When those controls are weak, simple mistakes turn into account takeovers or data leaks.

This section breaks down the principle of least privilege and the Zero Trust model, then ties them to tools like ACLs and identity policies. You'll also review MFA methods (email, hardware tokens, authenticator apps, SMS, voice calls, TOTP, and OTP), plus how SSO and SAML support sign-ins across apps.

Finally, you'll cover just-in-time access and PAM for privileged tasks, along with IAM and directory services that back user and group management. To round it out, you'll see where MDM and DLP fit when endpoints and data need tighter control.

Logical security in practice

In CompTIA A+ Core 2 (220-1202), Domain 2.0, Objective 2.1, logical security focuses on controlling access to systems and data through identity and policy, not physical barriers. On the job, you see it in sign-ins, access requests, group changes, and audit trails. When these controls are strong, mistakes stay small. When they are weak, a single click can turn into a data exposure.

Common risks logical security is meant to stop

Most logical security failures start with ordinary behavior, not advanced hacking. Attackers look for the easiest path to a valid login because a real account often bypasses many defenses.

Here are common risks logical security is designed to reduce:

Password reuse: One breached password can unlock multiple services, especially when users recycle it across email, VPN, and SaaS apps.
Phishing: Fake login pages trick users into handing over credentials, sometimes even MFA codes.
Weak permissions: Overly broad group membership (or sloppy ACLs) lets standard users reach sensitive files.
Shared accounts: When many people use one login, you lose accountability and can't trace actions to a person.
Unused accounts: Old contractor logins and stale service accounts often keep access long after they should.
Malware using stolen credentials: Info-stealers and remote access tools can capture session tokens, saved passwords, and browser cookies.

A short scenario shows how these issues connect. An employee receives an email that looks like a Microsoft 365 alert. They click a link and enter their password on a fake login page. The attacker then signs in as that user and opens SharePoint, downloading a folder labeled "HR".

The control gaps are usually boring but costly:

The user had no phishing-resistant MFA, so a stolen password was enough.
The account sat in a broad SharePoint group, so authorization was too permissive.
The organization lacked strong conditional access signals (device compliance, location checks), so the sign-in looked acceptable.
Logging existed, but nobody reviewed it, so the download went unnoticed.

A stolen password is only step one. The real damage happens when permissions and monitoring fail after the sign-in.

Authentication, authorization, and accounting in simple terms

Logical security often gets taught with the "AAA" model because it maps cleanly to how systems make access decisions. It also shows up in exam questions and help desk workflows.

Authentication answers: Who are you?
This is the act of proving identity, for example, typing a password, approving a push notification, or entering a TOTP code. If authentication fails, the user can't get in at all.

Authorization answers: What can you do now that you're in?
This is where permissions, group membership, app roles, and ACLs decide what the user can see, change, or delete. A user can authenticate successfully and still get "Access denied" when authorization blocks them.

Accounting answers: What happened, and who did it?
This is logging and auditing. It includes sign-in logs, file access logs, admin action logs, and alerts. Accounting supports investigations, compliance, and incident response.

This model also matches common ticket types:

A password reset or MFA re-enrollment is an authentication problem.
An access request (add to a group, grant a SharePoint role, assign an app license) is an authorization change.
A "Did this user download files?" request, or "Why did the account lock?" question is an accounting task, and it often requires escalation to security or a tenant admin.

From an exam perspective, watch for wording clues. If the question mentions "verifying identity," think authentication. If it mentions "permissions" or "least privilege," think authorization. If it mentions "audit trail," "logs," or "tracking activity," think accounting.

If a user can sign in but can't open a folder, don't chase passwords. Start with authorization, then confirm logs support the story.

Where access control happens: device, network, and application layers

Access control is rarely one gate. In most organizations, a single action touches multiple layers, which explains why "my password is correct" does not mean "I should have access."

Consider a common workflow: a user tries to access an internal app from their phone.

First, the device layer may block them. If the phone fails MDM compliance checks (no passcode, outdated OS, jailbroken device), conditional access can deny the sign-in or limit features. The user feels it as a sudden prompt, a blocked screen, or "You can't get there from this device."

Next, the network layer may add requirements. The user might need a VPN, a trusted network, or a specific DNS route. Even with correct credentials, a missing VPN tunnel can prevent the app from being reachable.

Finally, the application layer decides what the account can do. The directory might authenticate the user, but the app still checks:

Directory group membership (for example, "Finance-App-Users").
App roles (read-only vs editor).
Resource permissions (SharePoint site role, file ACLs, mailbox rights).

This layered structure is good security practice because it limits blast radius. Still, it creates real troubleshooting complexity. A help desk tech may need to separate three similar symptoms:

Can't sign in (authentication, or device policy blocking sign-in).
Can't reach the app (network path, VPN, firewall, DNS).
Signed in, but blocked inside the app (authorization, licensing, role assignment).

In other words, access control works like a series of checkpoints. Passing the first checkpoint (password) does not guarantee the rest will pass. That is why clear policies, accurate group management, and strong logs matter as much as the login screen.

Least Privilege and Zero Trust

In CompTIA A+ Core 2 (220-1202), Domain 2.0, Objective 2.1, least privilege and Zero Trust explain how to grant access without creating new risks. The goal isn't to slow people down. Instead, it keeps everyday work normal while reducing what an attacker (or a simple mistake) can do after a sign-in succeeds.

A helpful way to think about it is a building with interior doors. The front door matters, but so do the office locks, supply closet keys, and alarm logs. When you limit who can open which door, small problems stay small. That matters most during phishing, malware, and ransomware events, because the damage often depends on what the logged-in account can reach.

Principle of least privilege with real permission examples

Least privilege means each account gets only the access it needs, nothing extra. This principle applies to users, groups, service accounts, and even IT staff. When permissions drift upward over time, your environment becomes fragile. People can change settings they don't understand, and attackers can move faster after a compromise.

Start with the most common example: standard user vs local admin. A standard user can run approved apps and save files, but they can't install random software or change system-wide settings. By contrast, a local admin can install tools, disable security controls, and modify system files. That extra power often becomes the difference between a blocked infection and a full device takeover.

Shared folders show the same idea in a simple, visible way. Read-only vs modify is not a minor detail.

With read-only, a user can open and copy needed documents, but they can't overwrite or delete them.
With modify, a user can change data, rename folders, and delete files, sometimes across entire team shares.

Ransomware makes this painfully clear. If an infected account has modify rights to a shared folder, ransomware can encrypt those files too. If the same account only has read-only, the malware can still steal data, but it struggles to destroy the shared content. In other words, too much access increases both impact and recovery time.

Help desk access needs the same discipline. A support tech often needs tools like password resets and account unlocks, but they do not need broad admin rights everywhere. A well-scoped help desk role might allow:

Resetting passwords and clearing lockouts for standard users.
Managing MFA re-enrollment for users who changed phones.
Reading basic user attributes (department, manager, office).

At the same time, it should restrict high-risk actions, such as granting global admin roles, changing audit settings, or exporting large user lists. Those tasks belong to a smaller admin group with stronger oversight.

Least privilege doesn't assume people are careless. It assumes accounts get compromised, and it limits what happens next.

Accidental changes matter too. Many outages begin with a well-meaning user or tech clicking the wrong option. Tight permissions reduce those "oops" moments, because fewer people can make high-impact changes.

What Zero Trust means in day-to-day policies

Zero Trust is a policy mindset: the system should not assume access is safe just because a user is on the internal network or already signed in. Instead, the system checks trust signals each time access matters. This approach fits modern work, because users move between office networks, home Wi-Fi, mobile devices, and cloud apps.

In plain terms, Zero Trust treats each access request like a new decision. The account may be valid, but the context still needs to make sense. That is why many organizations use conditional access rules to allow, limit, or block a sign-in based on real conditions.

Common verification signals include the following:

User identity: The username and password are not enough. Strong MFA, recent password changes, and sign-in risk signals help validate the person behind the account.
Device compliance: A managed laptop with encryption and a healthy security agent is safer than an unknown device. Policies often require device enrollment, a screen lock, and an up-to-date OS.
Network and location context: A sign-in from an unusual country or from an anonymous VPN can trigger extra checks. On the other hand, a known office network may reduce prompts.
Behavior patterns: Normal users follow patterns. If an account suddenly downloads thousands of files or logs in at strange hours, the system can require step-up MFA or block the action.

These checks are not about punishing users. They support access decisions that match the risk of the moment. For example, a user might access email from a compliant phone with MFA, but the same user might get blocked from downloading sensitive files on an unmanaged home computer.

Zero Trust also changes how you think about internal resources. Being "inside" the network no longer guarantees broad access. Instead, each app and dataset gets its own controls. That reduces lateral movement, which is how attackers spread after stealing one set of credentials.

From a help desk view, Zero Trust policies explain many tickets. A user may say, "My password works, but I still can't sign in." Often, the system did authenticate them, but it rejected the attempt because the device failed compliance or the sign-in looked risky.