Webroot Identity Shield: Protect, Allow and Deny explained

Identity Shield, Identity Protection and Privacy Protection can mean the same endpoint layer

Search results still say “Webroot Identity Shield,” and much of Webroot's own current support library uses that name. The Windows release notes say PC build 9.0.35.12, released in May 2023, changed UI references from Identity Shield and Identity Protection to Privacy Shield and Privacy Protection. That's a label change, not evidence that the data-protection mechanism disappeared.

Record the product and version before following a menu. SecureAnywhere consumer builds, the newer Webroot Total Protection shell and managed OpenText Core Endpoint Protection can expose different navigation or policy authority. An instruction that begins with a green SecureAnywhere window may not match the Application panel in a newer subscription.

The search term also collides with identity-monitoring products. Identity Shield in this article means the local endpoint protection wrapped around an application's sensitive data. It doesn't mean credit monitoring, identity restoration, a VPN or the browser-extension reputation service.

When the local UI has Identity Protection, select its gear and look for Application Protection. If it says Privacy Protection, use that current label. If neither exists, don't install an old agent or edit the registry to force a menu; check the active subscription's current support path.

What Identity Shield protects—and the boundary it can't erase

Webroot's protected-applications guide describes defense against information-stealing Trojans such as keyloggers, clipboard stealers and man-in-the-middle activity. It also says protected applications retain full access to system data. The shield is therefore a trust boundary around a selected app, not a sandbox that strips the app of normal permissions.

Protected screen contents and keyboard input matter because malware can steal a password without modifying the banking page. Clipboard interception matters when users paste passwords, account numbers, recovery codes or cryptocurrency addresses. Identity Shield adds resistance around these data paths while the protected application is active.

The tray padlock is a useful activity cue, not a security certificate for the site. A protected browser can still reach a convincing phishing page, and a legitimate site can still be compromised by account takeover. Keep Web Threat Shield, browser updates, MFA and independent transaction checks in place.

No honest guide should promise that this setting blocks every hardware keylogger, kernel-level implant, remote-control session, malicious browser extension or camera pointed at the screen. The feature is one layer. The Webroot keylogger FAQ confirms protection but also notes that legitimate monitoring tools may be detected because their behavior overlaps with abuse.

Protect, Allow and Deny answer two different questions

The labels combine application trust with access to protected data. “Allow” sounds safest, but it's the compatibility state with no Identity Shield protection for that application. Deny doesn't necessarily stop the executable; Webroot says the denied app can't view or capture protected data but can otherwise run normally.

Choose a state for the exact executable, not for a brand name. A browser, password manager, accessibility tool, updater and capture helper may be separate signed processes. One broad decision can either weaken the browser or break the helper.

Record the old state before changing it. The difference between “worked after Allow” and “worked after disabling Identity Shield” is substantial: the first localizes the conflict to one executable, while the second removes the layer and proves much less.

Set up or repair Application Protection without opening a security hole

Begin with evidence, not a random toggle. The visible symptom may be caused by Identity Shield, Web Threat Shield, file quarantine, Windows Firewall, a browser extension or the application itself. Capture the exact error and identify the executable before assigning a state.

1. Confirm the product and label

   Open the installed Webroot agent and record its product name and version. Look for Identity Protection, Privacy Protection or the corresponding shield settings rather than assuming every Webroot interface is identical.

2. Record the symptom before changing anything

   Note the affected application, full executable path, exact error, time and whether keyboard input, clipboard access, screen capture, download or launch behavior is failing.

3. Verify the application

   Confirm the executable came from the official publisher, lives in the expected path and has a valid digital signature. Don't relax protection for an unknown or user-writable copy.

4. Open Application Protection

   In SecureAnywhere, use the gear beside Identity Protection or Privacy Protection and open Application Protection. Managed agents may require an administrator instead of a local change.

5. Choose the narrowest correct state

   Use Protect for a trusted app that handles sensitive data, Allow only for a verified compatibility exception, and Deny for a process that must not read protected data.

6. Change one application only

   Record the previous state, change the exact executable and leave global shield defaults enabled. Don't disable the whole antivirus or allow a folder.

7. Retest one controlled action

   Restart the application and repeat the specific keystroke, capture, clipboard or download action. Avoid browsing, payments or entering real secrets during the comparison.

8. Restore and escalate with evidence

   Return temporary exceptions to Protect when possible. If the issue remains, send Webroot or the administrator the version, path, signature, screenshots and reproduction steps.

Webroot's shield-settings reference recommends keeping defaults and provides Reset to Defaults. Treat that reset as a recovery tool after recording deliberate exceptions, not as a first click that erases the evidence.

If the Add Application dialog selects a launcher instead of the child process that reads the protected data, the change may have no effect. Use Task Manager, the app's About panel and digital-signature properties to identify the active executable. Avoid files in Temp, Downloads or a random user-writable clone of a legitimate directory.

Use Protect for trusted applications that handle secrets

Supported browsers are the default example because they handle passwords, security codes, payment data and account sessions. Financial-management, tax-preparation and some messaging applications can also justify Protect when their executable is verified and the shield doesn't break required behavior.

Protect doesn't mean Webroot trusts every site or document opened by the app. It means the selected application keeps normal access while Webroot limits information-stealing behavior around its protected data. URL reputation and malware scanning remain separate checks.

Don't mark every installed program Protect. Expanding the protected set increases compatibility surface and makes the tray indicator less informative. Start with apps that genuinely process sensitive input, then add a verified application only when the use case is clear.

If a browser appears twice after an update, verify which signed path is current. Remove obsolete entries only after confirming they no longer launch. A stale entry doesn't protect a replacement executable in a different versioned path.

Use Allow only for a verified compatibility exception

Allow gives the application full access to protected data without shielding that application from information-stealing malware. Webroot specifically positions it for trusted background applications that legitimately touch screen or keyboard data. That makes Allow useful, but weaker than Protect for a browser or banking app.

Capture tools, accessibility software, keyboard utilities, password managers and security integrations can need access that resembles spying. Verify the publisher, signature and path; then allow the exact helper that needs access. Don't allow the whole suite if one component is responsible.

Make the exception temporary when possible. After the publisher or Webroot ships a compatibility fix, return the app to Protect and repeat the narrow action. An exception that remains forever because “it once fixed something” becomes undocumented security debt.

Allow here isn't the same as the file false-positive allowlist, the firewall's network process rule or a Web Threat Shield site exclusion. Use the evidence-producing layer, not the most convenient Allow button.

Use Deny to stop an application reading protected data—not to quarantine it

Deny is appropriate when a process may continue running but shouldn't see protected screen contents, keyboard input or clipboard data. That can apply to an unneeded capture helper, remote-viewing component or uncertain background process while you investigate it.

If the executable itself is malicious or unwanted, Deny isn't the full response. Disconnect as appropriate, preserve the detection, scan and quarantine the threat, rotate exposed credentials from a clean device and inspect persistence. The scan and quarantine guide owns that containment route.

A denied process may display blank content, miss input or report that capture failed. That's expected evidence that the data boundary is working, not necessarily a software crash. Decide whether the process truly needs the information before changing it to Allow.

Don't use Deny as a substitute for parental controls, account permissions or uninstalling an unauthorized monitoring tool. Those controls answer different questions and produce clearer accountability.

Keep browsers and banking sessions protected, but verify which executable is active

Webroot says browsers are automatically added to Protected Applications and assigned Protect. When the shield is active, the system-tray icon can show a padlock. Use that as a local state indicator, then separately confirm the address, TLS connection and account context before entering credentials.

Chromium browsers can have multiple processes, updaters and installed channels. Chrome Stable, Beta and a portable copy may live in different paths. Protect the trusted browser you actually launch; don't assume one old chrome.exe entry covers every channel.

A browser that fails to open after an update may expose a compatibility regression, a stale path or another security layer. Webroot's historical release notes record Chrome-loading fixes in 2021, which proves the interaction has existed, not that every current Chrome failure has the same cause. Test the exact current build and preserve version evidence.

Identity Shield doesn't replace the Web Threat Shield extension. The endpoint shield protects application data; the extension evaluates destinations and search links. Keep both where supported and diagnose their prompts separately.

Missed keystrokes, numpad failures and broken hotkeys need a one-app diagnosis

Community reports describe first keystrokes disappearing, numpad input stopping and shortcuts failing while Webroot's anti-keylogging layer was active. A more recent r/sysadmin report tied a keyboard problem across Lenovo and one Dell system to Webroot. These reports show a plausible compatibility pattern, not a measured failure rate for all 2026 users.

Record whether the problem occurs in one protected browser, every protected app or the whole desktop. Check the keyboard driver, layout, accessibility tools, hotkey utilities and remote-session software. If ordinary input works outside the protected app, Application Protection becomes a stronger lead.

Change only the verified affected application's state for one controlled comparison. Don't type a real password during the test. If Allow restores input, return to Protect and check current Webroot and application builds before deciding that a permanent exception is necessary.

The older r/webroot keyboard thread includes users who disabled the whole shield, but that isn't our recommended permanent fix. A narrow application exception plus a support ticket preserves far more protection and diagnostic value.

Black screenshots or blocked clipboard access can be deliberate protection

A screenshot tool can return a black, white or fragmented protected window when Identity Shield prevents it from reading screen contents. TechSmith's Snagit troubleshooting article specifically identifies Webroot's identity-protection module as one cause. That doesn't justify allowing every capture utility.

First confirm the target doesn't intentionally block capture for payment, DRM or privacy reasons. Then verify the capture application's signed executable and decide whether the screenshot is legitimate. Allow only that exact capture helper for the brief task, and avoid exposing unrelated passwords or recovery codes while it can read the screen.

Clipboard managers, text expanders and password tools can trigger the same trust question. A manager that reads every clipboard change may be useful and still increase exposure. Prefer one with a clear publisher, current updates, local security controls and a narrowly documented reason for the exception.

If the app needs protected screen access every day, ask whether the workflow can avoid capturing sensitive windows. A permanent Allow state may be operationally necessary, but it should be recorded as an explicit tradeoff rather than described as equally secure.

Chrome “Virus Scan Failed” has an official, version-sensitive MpoAv.dll workaround

Webroot's consumer support article says Identity Shield can block Windows Defender's MpoAv.dll and cause Chrome to display “Virus Scan Failed.” Its workaround changes that file to Allow in Application Protection.

The same article warns that the override is effective only until the file updates, after which a new override may be required. That makes it a current documented workaround, not a timeless instruction to allow any DLL with a similar name. Follow the exact current path and open a support ticket for permanent-fix status.

Verify the file path and Microsoft signature before changing it. If Chrome downloads fail for another reason—disk permissions, profile corruption, browser policy, download reputation or storage—the override may do nothing. Remove an ineffective exception rather than stacking more.

On a managed endpoint, the administrator may need to issue the approved Identity Shield command. Don't copy a consumer workaround into a global policy without testing scope and a removal plan.

Test the shield without installing a real keylogger or exposing credentials

Don't download a “free keylogger” to prove the feature works. Dual-use monitoring tools can be malicious, bundled or detected inconsistently, and running one with real accounts can create the theft you were trying to prevent. A home system isn't a malware laboratory.

Use a benign functional comparison: a temporary non-secret phrase, a trusted screenshot tool aimed at a dummy page or a clipboard sample with no personal data. Change one verified app state, repeat the action once, record the result and restore the stronger state.

A failed capture in Deny and a successful capture in Allow show state behavior; they don't prove protection against every attack class. Likewise, a tray padlock proves the local protected state, not that the page, account or network is trustworthy.

If you need product efficacy evidence, use independent lab results and controlled research rather than improvised malware. The Webroot review explains the wider detection evidence and its limitations.

Identity Shield isn't Web Threat Shield, file trust or firewall policy

Web Threat Shield is the browser/destination layer. Identity Shield or Privacy Protection is the endpoint application-data layer. Realtime scanning and quarantine decide what a file is; Firewall evaluates process/network behavior. One symptom can cross layers, but one exception doesn't configure the others.

If a site displays a reputation block page, inspect the URL and BrightCloud route rather than changing Application Protection. If an executable is quarantined, verify and restore through file controls. If the app opens but can't connect, inspect the exact outbound and inbound owner.

Keep a short change log: component, executable or URL, old state, new state, reason, time and retest. That prevents a later reviewer from mistaking a compatibility exception for a vendor recommendation.

The general troubleshooting guide covers damaged installs, stuck scans and service failures. Use this page when protected-data behavior is the real signal.

Allstate Identity Protection is a separate monitoring and recovery service

Webroot's current Application panel lists Allstate Identity Protection as a subscription feature on eligible Windows and macOS installations. Selecting it directs the user to an online account. Identity Shield isn't the same as Allstate Identity Protection: the service concerns identity monitoring and recovery; it doesn't assign Protect, Allow or Deny to local executables.

Identity Shield can't freeze a credit file, monitor a bureau or reimburse identity-theft costs. Conversely, a monitoring service doesn't stop a local screen grabber from reading a banking window. Users may benefit from both, but the evidence and controls are different.

When comparing plans, use the exact current entitlement. Don't claim every SecureAnywhere key includes Allstate services, VPN, backup or parental controls. The Webroot pricing guide tracks plan boundaries and renewal terms separately.

If a Webroot page says “identity protection,” read the surrounding nouns: application, shield, credit, monitoring or restoration. That context usually resolves which product the label means.

Webroot Total Protection and the current agent may not match old screenshots

Webroot's release notes show a Total Protection UI update in February 2025 and automatic upgrade paths added in June 2025. The current 2026 SecureAnywhere agent line also continues in those notes. A user can therefore encounter a newer shell around controls documented with older green-window screenshots.

Start from the installed product's About/version information, not the purchase email. Then use the support article tied to that product and operating system. Don't force SecureAnywhere menu labels into a Total Protection screen that organizes features under Virus Protection or Application.

The rename to Privacy Protection can make a current setting look unrelated to search results. Match behavior—application protection around input, screen and clipboard—to the label, but never assume that every Total Protection platform exposes the same local states. Mobile and macOS controls can differ from Windows.

If the feature is absent, check entitlement and platform support with Webroot. Installing a legacy build to recover one familiar tab can introduce unsupported software and conflict with the subscription's upgrade path.

Managed OpenText endpoints require policy-owner approval

OpenText's managed Identity Shield guide says a local override may require the Unmanaged endpoint policy, while administrators can issue an Allow Application command using the file's MD5. That workflow isn't permission for an employee to remove management.

Send the administrator device, username, exact path, signer, file hash, agent version, time, screenshot and the protected action that failed. If multiple endpoints changed together, the administrator can compare policy, release and device groups before applying a scoped override.

A global Allow command should have an owner and an expiry or review point. When the vendor updates the file, the hash may change; when Webroot corrects classification or compatibility, the exception may no longer be necessary.

Don't disable policy, edit registry keys, stop the agent service or install a consumer Webroot copy beside the managed agent. Those actions broaden the incident and can erase the state needed to diagnose it.