Anti-Malware Cannot Be Disabled

PCI DSS requires that end users cannot disable or alter anti-malware on in-scope systems, except for a documented, management-approved exception that is granted case-by-case and limited to a defined time window (PCI DSS v4.0.1 Requirement 5.3.5). To operationalize it, enforce tamper protection and least privilege through centralized endpoint management, and run a controlled exception workflow with time-bound approvals and auditable evidence.

Key takeaways:

• Anti-malware must be technically enforced so typical users cannot stop, uninstall, or change protections (PCI DSS v4.0.1 Requirement 5.3.5).
• Exceptions are allowed only if documented and approved by management for a limited period, per case (PCI DSS v4.0.1 Requirement 5.3.5).
• Your audit pass hinges on prevention (policy + technical controls) plus evidence (config baselines, logs, and exception records).

“Anti-malware cannot be disabled” is an anti-tampering requirement, not a purchase decision. Assessors will look for proof that your endpoint security controls remain on, stay enforced, and cannot be turned off by standard users on systems in scope for PCI DSS. This matters most on endpoints and servers that touch the cardholder data environment (CDE) directly, and also on systems connected to it where malware could provide an access path.

PCI DSS does allow temporary exceptions, but the exception path must be narrow: you need specific documentation, a management authorization, and a time limit for each instance (PCI DSS v4.0.1 Requirement 5.3.5). In practice, the teams that struggle are the ones that treat exceptions as informal (“just disable it for troubleshooting”) or rely on local admin rights that let users change security controls.

This page translates the requirement into an operator-ready control: lock anti-malware settings behind centralized administration and tamper protection, remove local admin where possible, and run a ticketed exception process with clear ownership, expiry, and verification of re-enablement.

Regulatory text

Requirement: “Anti-malware mechanisms cannot be disabled or altered by users, unless specifically documented, and authorized by management on a case-by-case basis for a limited time period.” (PCI DSS v4.0.1 Requirement 5.3.5)

What the operator must do:
You must (1) implement technical restrictions so users cannot disable or modify anti-malware on in-scope systems, and (2) if you ever allow a temporary disablement or configuration change, you must document the reason and receive management approval for that specific instance, with a defined and limited time window (PCI DSS v4.0.1 Requirement 5.3.5).

Plain-English interpretation (what “cannot be disabled” means in real life)

For PCI, “cannot be disabled” means a typical user cannot:

• Stop the anti-malware service/process.
• Uninstall or downgrade the agent.
• Turn off real-time protection, behavioral protection, or scanning.
• Exclude paths/processes to effectively neutralize protection.
• Change update channels, disable signatures, or block cloud protection (if applicable).
• Disable tamper protection or equivalent safeguards.

If your endpoint tool allows these actions to anyone with local admin, and a large portion of your user population has local admin, your control is usually weak. You may still be able to meet the requirement, but you will need compensating design: strict admin assignment, monitoring, and a defensible exception process that shows “users” cannot do it as a practical matter.

Who it applies to (entity and operational context)

Entity types: Merchants, service providers, payment processors.

Operational scope: Any system where anti-malware is required within your PCI DSS scope (commonly endpoints and servers that store, process, transmit, or can impact the security of cardholder data). The requirement is most often tested on:

• CDE-connected Windows endpoints (call centers, POS support workstations, jump hosts).
• Windows and Linux servers in the CDE or supporting it (application servers, file servers, VDI hosts).
• VDI images and golden templates.
• Remote access endpoints used by admins to manage CDE systems.

Third parties: If a third party manages endpoints or provides managed detection and response, you still own the requirement. Contractual terms should support your need to enforce anti-tamper settings and to retrieve audit evidence on demand.

What you actually need to do (step-by-step)

1) Define “in-scope endpoints and servers” and align ownership

• Identify the endpoint populations that are in scope for PCI DSS testing (system groups, VLANs, hostnames, CMDB sets).
• Assign clear control owners: Security Engineering (technical enforcement), IT Operations (deployment and lifecycle), and Compliance/GRC (evidence and exception governance).

Output: a scoped asset list and an ownership RACI.

2) Standardize the anti-malware configuration baseline

Establish a baseline that includes:

• Real-time protection enabled.
• Automatic updates enabled.
• Tamper protection enabled (or vendor equivalent).
• Settings locked to centrally managed policy.
• User interface restrictions to prevent local changes.
• Password- or role-based access for administrative actions.

Operator tip: Write the baseline as “must” statements that map to settings names in your tool, so evidence is a screenshot/export, not a narrative.

3) Enforce least privilege so “users” really can’t disable controls

• Remove local admin from standard users on in-scope systems where feasible.
• For required admin tasks, use privileged access workflows (separate admin accounts, just-in-time elevation, or controlled remote admin tools).
• Restrict who can manage endpoint security policies in your endpoint console (role-based access control).

This is where many programs fail: if many users are local admins, the anti-malware tool must still prevent tampering by local admin, or you must strictly limit who has that level of access and show it is not “users” broadly.

4) Turn on anti-tamper controls and test them

• Enable the tool’s tamper protection feature.
• Attempt to stop services, disable real-time scanning, and add exclusions using a standard user account and any common power-user tools you see in the environment.
• Document test results and remediate gaps (policy locks, RBAC, endpoint hardening).

Minimum bar: you can demonstrate that normal users cannot disable protections. If disablement is possible, you need a compensating control plan and fast remediation.

5) Build a case-by-case exception workflow (documented + time-limited)

PCI allows exceptions only if they are documented and approved by management, case-by-case, for a limited period (PCI DSS v4.0.1 Requirement 5.3.5). Implement this as a controlled workflow:

Exception request intake (ticket):

• Business justification (why disablement/alteration is needed).
• Device identifier(s) (hostname, asset ID, owner).
• Exact change requested (disable feature X, add exclusion Y).
• Start time and end time (explicit expiry).
• Risk assessment notes and compensating steps (extra monitoring, isolation, restricted network access, file hash validation).

Approval:

• Management approval for that specific ticket (define which management roles qualify).
• Security approval if your governance model requires it (recommended for high-risk scope like CDE systems).

Execution:

• Only authorized admins execute the change.
• Record who performed the action and the method (console action, script, EDR response action).

Closure:

• Validate protections are restored at expiry.
• Attach proof (policy status, agent health, event log, console status).
• Post-incident note if the exception recurs, and convert recurring needs into engineering fixes.

6) Continuous monitoring and drift detection

• Monitor for “agent unhealthy,” “protection disabled,” or “policy not applied” events.
• Alert on and investigate any endpoint with disabled components.
• Track configuration drift through policy compliance reports.

Even if users cannot disable controls, failures still happen due to corruption, conflicts, or misconfiguration. Auditors often test whether you detect and resolve these states promptly.

7) Make it auditor-ready (mapping and narrative)

Prepare a short control narrative that states:

• How anti-malware policies are centrally enforced.
• How tamper protection prevents user changes.
• Who can change policies and how access is controlled.
• How exceptions are documented, approved, time-limited, and reviewed (PCI DSS v4.0.1 Requirement 5.3.5).

If you use Daydream to manage your PCI control library and evidence requests, store the baseline, console exports, and exception tickets as reusable artifacts so each assessment cycle is a refresh, not a rebuild.

Required evidence and artifacts to retain

Keep evidence that shows both prevention and controlled exceptions:

Technical configuration evidence

• Endpoint security policy exports (showing tamper protection and locked settings).
• RBAC screenshots/exports from the endpoint console (who can change policy).
• A sample of endpoint compliance/health reports showing protections enabled.
• System configuration evidence supporting least privilege (e.g., local admin group membership exports for in-scope endpoints, where available).

Operational process evidence

• Written standard: “Anti-malware cannot be disabled by users; exceptions require documented management approval and are time-limited” (PCI DSS v4.0.1 Requirement 5.3.5).
• Exception tickets: request, approvals, start/end times, restoration proof.
• Change records for policy modifications (who changed what and when).
• Alert records and incident notes when protection was unexpectedly disabled.

Common exam/audit questions and hangups

Assessors tend to probe these areas:

• “Show me that a standard user can’t disable it.” Expect live demonstration or documented testing.
• “Who counts as a user?” If many users have admin rights, you must show they are not “users” broadly and that controls still prevent tampering.
• “How do you handle exceptions?” They will ask for multiple examples and look for time limits and management authorization (PCI DSS v4.0.1 Requirement 5.3.5).
• “What happens if the agent is offline or unhealthy?” They will look for monitoring and response workflow.
• “Do you control exclusions?” Exclusions are a common backdoor to “disabled in practice.”

Frequent implementation mistakes (and how to avoid them)

1. Relying on policy statements without technical enforcement.
   Fix: demonstrate tamper protection and restricted permissions in the tool plus least privilege.

2. Permanent exclusions or “temporary” disablements that never expire.
   Fix: require explicit end time in the ticket and validate restoration as a closure step (PCI DSS v4.0.1 Requirement 5.3.5).

3. Shared admin accounts used to disable protections.
   Fix: unique admin identities and auditable actions in the console; keep access tightly scoped.

4. Exceptions handled over chat/email with no record.
   Fix: route all exceptions through a ticket system and attach console evidence.

5. Golden images/VDI pools where the agent is disabled during imaging and never re-enabled.
   Fix: treat images as production artifacts; add a release gate that verifies anti-malware status.

Enforcement context and risk implications

This requirement exists because malware operators commonly attempt to disable endpoint defenses to persist and move laterally. In a PCI context, that creates direct risk to cardholder data confidentiality and can turn a single compromised endpoint into a path into the CDE. From a compliance standpoint, weak anti-tamper controls often lead to assessment findings because the expectation is measurable: either users can disable it or they cannot, and exceptions must be controlled (PCI DSS v4.0.1 Requirement 5.3.5).

Practical 30/60/90-day execution plan

First 30 days (stabilize and prove control intent)

• Confirm in-scope system groups for endpoints/servers tied to PCI.
• Document the anti-malware baseline configuration (settings-level).
• Restrict endpoint-console RBAC to a small admin set.
• Enable tamper protection across the in-scope fleet where supported.
• Draft the exception workflow and required ticket fields aligned to the requirement (PCI DSS v4.0.1 Requirement 5.3.5).

Days 31–60 (close gaps and make it testable)

• Remove local admin for standard users on in-scope endpoints where feasible; document any justified exceptions.
• Test disabling attempts with standard user accounts; capture results as evidence.
• Implement alerting for “protection disabled,” “agent stopped,” and “policy not applied,” and define a response runbook.
• Run a tabletop for the exception process: request, approval, disablement, restoration, closure.

Days 61–90 (operationalize and audit-package)

• Run an internal evidence collection sprint: policy exports, RBAC lists, sample compliance reports, and exception tickets.
• Review all existing exclusions and disablement patterns; eliminate recurring exceptions by fixing root causes (app conflicts, performance tuning, change windows).
• Add a quarterly control check: verify tamper protection is on and policy compliance is consistent across in-scope groups.
• In Daydream, set this control up as a recurring evidence request package so teams attach updated exports and exception logs without rebuilding the story each cycle.

Frequently Asked Questions

Does “cannot be disabled” mean no one can ever turn it off?

No. PCI DSS allows disablement or alteration only if it is documented and authorized by management, case-by-case, for a limited time period (PCI DSS v4.0.1 Requirement 5.3.5). Your job is to make that path controlled and auditable.

If IT admins can disable anti-malware, are we noncompliant?

Not automatically. The requirement targets “users,” and admins may be authorized operators, but you still need strict access control, auditable actions, and a documented, time-limited approval process for any disablement (PCI DSS v4.0.1 Requirement 5.3.5).

Are exclusions considered “altering” anti-malware?

Yes in practice, because exclusions can neutralize protection even if the agent is still running. Treat exclusions as controlled changes with the same governance you apply to temporary disablement.

What evidence is strongest for an assessor?

Console policy exports showing tamper protection and locked settings, RBAC showing only authorized roles can change policy, and a small set of exception tickets that show management approval and restoration proof (PCI DSS v4.0.1 Requirement 5.3.5).

What if a legacy application breaks when real-time scanning is enabled?

Route it through the exception workflow, add the narrowest possible exclusion, and set an expiry with a remediation plan (patch, vendor fix, app replacement). Auditors will expect the exception to be time-limited and approved, not open-ended (PCI DSS v4.0.1 Requirement 5.3.5).

How do we handle contractors or third parties who need to troubleshoot and ask to disable the agent?

Do not give them the ability to disable protections directly. Require a ticket, management approval, and have your authorized admins perform the change with a defined end time and restoration verification (PCI DSS v4.0.1 Requirement 5.3.5).