ANAVEM
EnglishFrancais
ANAVEM
Languagefr
Windows security monitoring dashboard displaying audit policy events in a cybersecurity operations center
Event ID 4963InformationMicrosoft-Windows-Security-AuditingWindows

Windows Event ID 4963 – Microsoft-Windows-Security-Auditing: Object Access Auditing Disabled

Event ID 4963 indicates that object access auditing has been disabled on a Windows system. This security event fires when audit policies for file, folder, or registry access monitoring are turned off.

Emanuel DE ALMEIDAEmanuel DE ALMEIDA
18 March 20269 min read 0
Event ID 4963Microsoft-Windows-Security-Auditing 5 methods 9 min
Event Reference

What This Event Means

Event ID 4963 is generated by the Windows Security Auditing subsystem when object access auditing policies are disabled. Object access auditing is a critical security feature that logs attempts to access files, folders, registry keys, and other Windows objects that have been configured with System Access Control Lists (SACLs).

When this event fires, it indicates that one or more audit subcategories under the Object Access category have been turned off. These subcategories include File System auditing, Registry auditing, Kernel Object auditing, SAM auditing, Certification Services auditing, Application Generated auditing, Handle Manipulation auditing, File Share auditing, Filtering Platform Packet Drop auditing, Filtering Platform Connection auditing, and Other Object Access Events auditing.

The event provides forensic value by creating an audit trail of when security monitoring was reduced. This is particularly important in environments where compliance regulations require continuous monitoring of sensitive data access. The event helps security teams identify potential gaps in their monitoring coverage and investigate whether audit policy changes were authorized.

In enterprise environments, this event often correlates with Group Policy changes, system maintenance activities, or security configuration modifications. Understanding when and why object access auditing was disabled helps maintain the integrity of security monitoring programs and ensures that appropriate compensating controls are in place during periods of reduced auditing.

Applies to

Windows 10Windows 11Windows Server 2019/2022/2025
Analysis

Possible Causes

  • Manual disabling of object access audit policies through Local Security Policy or Group Policy
  • Group Policy updates that modify audit policy settings across domain-joined systems
  • System maintenance scripts or automation tools that temporarily disable auditing for performance
  • Security software installations that modify audit configurations
  • Administrative actions to reduce audit log volume in high-activity environments
  • System restore operations that revert audit policy settings to previous configurations
  • Third-party security tools that manage Windows audit policies
  • PowerShell scripts or command-line tools executing auditpol.exe commands
Resolution Methods

Troubleshooting Steps

01

Check Current Audit Policy Status

First, verify the current state of object access auditing to understand which subcategories are disabled.

Step 1: Open an elevated Command Prompt or PowerShell session.

Step 2: Run the following command to check all audit policy settings:

auditpol /get /category:"Object Access"

Step 3: Review the output to identify which subcategories show "No Auditing" status.

Step 4: For detailed policy information, use:

auditpol /get /category:* | findstr "Object Access" -A 15

Step 5: Document the current settings and compare against your organization's security baseline requirements.

02

Investigate Event Details in Event Viewer

Examine the specific Event ID 4963 entries to understand the context and timing of audit policy changes.

Step 1: Open Event Viewer → Windows Logs → Security.

Step 2: Filter for Event ID 4963 using the following PowerShell command:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4963} -MaxEvents 50 | Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap

Step 3: Double-click on recent 4963 events to view detailed information including:

  • Subject Security ID and Account Name
  • Audit Policy Change details
  • Process Information
  • Timestamp of the change

Step 4: Correlate the timing with other security events around the same timeframe:

Get-WinEvent -FilterHashtable @{LogName='Security'; StartTime=(Get-Date).AddHours(-2); EndTime=(Get-Date)} | Where-Object {$_.Id -in @(4719,4902,4963)} | Sort-Object TimeCreated
03

Review Group Policy and Local Security Policy

Investigate whether the audit policy changes originated from Group Policy or local policy modifications.

Step 1: Check local security policy by running:

secpol.msc

Step 2: Navigate to Local Policies → Audit Policy and review Object Access settings.

Step 3: For domain-joined systems, check effective Group Policy settings:

gpresult /h C:\temp\gpresult.html

Step 4: Open the generated HTML file and search for audit policy settings under Computer Configuration.

Step 5: Use Group Policy Management Console to review the source GPO:

Get-GPOReport -All -ReportType HTML -Path C:\temp\AllGPOs.html

Step 6: Check for recent Group Policy changes in the event log:

Get-WinEvent -FilterHashtable @{LogName='System'; Id=1502} -MaxEvents 10
04

Analyze Process and User Context

Determine which process or user account initiated the audit policy change to identify the root cause.

Step 1: Extract detailed information from Event ID 4963 entries:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4963} | ForEach-Object { [xml]$xml = $_.ToXml(); $xml.Event.EventData.Data | Where-Object {$_.Name -in @('SubjectUserName','ProcessName','ProcessId')} }

Step 2: Check for related process creation events (Event ID 4688) around the same time:

$auditTime = (Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4963} -MaxEvents 1).TimeCreated
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=$auditTime.AddMinutes(-5); EndTime=$auditTime.AddMinutes(5)} | Where-Object {$_.Message -match "auditpol|secpol|gpedit"}

Step 3: Investigate the user account that made the change:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} | Where-Object {$_.TimeCreated -gt $auditTime.AddHours(-1) -and $_.Message -match "SubjectUserName"}

Step 4: Check for any scheduled tasks or services that might have triggered the change:

Get-ScheduledTask | Where-Object {$_.Actions.Execute -match "auditpol|secpol"}
05

Restore Object Access Auditing and Implement Monitoring

Re-enable appropriate object access auditing and establish monitoring to prevent unauthorized changes.

Step 1: Re-enable object access auditing for critical subcategories:

# Enable File System auditing
auditpol /set /subcategory:"File System" /success:enable /failure:enable

# Enable Registry auditing
auditpol /set /subcategory:"Registry" /success:enable /failure:enable

# Enable Handle Manipulation auditing
auditpol /set /subcategory:"Handle Manipulation" /success:enable /failure:enable

Step 2: Verify the changes took effect:

auditpol /get /category:"Object Access"

Step 3: Create a monitoring script to alert on future audit policy changes:

# Create event subscription for audit policy changes
wevtutil create-subscription AuditPolicyMonitor /c:Security /q:"*[System[EventID=4719 or EventID=4902 or EventID=4963]]"

Step 4: Configure Group Policy to enforce audit policy settings if in a domain environment:

Navigate to Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration

Step 5: Document the incident and update security procedures to include regular audit policy reviews.

Overview

Event ID 4963 fires when object access auditing is disabled on a Windows system. This event appears in the Security log whenever an administrator or system process turns off audit policies that monitor access to files, folders, registry keys, or other securable objects. The event serves as a security notification that tracking of object access attempts has been stopped.

This event typically occurs during system configuration changes, Group Policy updates, or manual audit policy modifications. While disabling object access auditing is sometimes necessary for performance reasons or specific security configurations, it represents a reduction in security monitoring capabilities that should be carefully tracked and justified.

The event contains details about which audit subcategory was disabled, the user account that made the change, and the timestamp of the modification. Security administrators use this event to maintain awareness of audit policy changes and ensure compliance with organizational security requirements.

Frequently Asked Questions

What does Event ID 4963 mean and why is it important?+
Event ID 4963 indicates that object access auditing has been disabled on your Windows system. This event is important because it represents a reduction in security monitoring capabilities. Object access auditing tracks attempts to access files, folders, registry keys, and other protected objects. When disabled, you lose visibility into who is accessing sensitive resources, which can impact security investigations, compliance requirements, and incident response capabilities.
How can I tell which specific audit subcategory was disabled when Event ID 4963 occurs?+
The Event ID 4963 entry contains detailed information about which audit subcategory was disabled. You can view this by examining the event details in Event Viewer or using PowerShell to extract the specific subcategory information. The event data includes fields like 'Subcategory' and 'Subcategory GUID' that identify exactly which type of object access auditing was turned off. Common subcategories include File System, Registry, Handle Manipulation, and File Share auditing.
Is Event ID 4963 always a security concern, or are there legitimate reasons for disabling object access auditing?+
Event ID 4963 is not always a security concern. There are legitimate reasons to disable object access auditing, including performance optimization in high-activity environments, temporary disabling during system maintenance, compliance with specific security configurations that don't require certain types of auditing, or resource management when audit logs are consuming excessive disk space. However, any disabling should be documented, justified, and temporary when possible.
How can I prevent unauthorized changes to audit policies that would trigger Event ID 4963?+
To prevent unauthorized audit policy changes, implement several controls: Use Group Policy to enforce audit policy settings from a central location, restrict administrative privileges to limit who can modify audit policies, enable auditing of audit policy changes themselves (Event IDs 4719, 4902, 4963), implement change management processes that require approval for security configuration changes, use security monitoring tools that alert on audit policy modifications, and regularly review audit policy settings against your security baseline.
What should I do immediately after discovering Event ID 4963 in my environment?+
Upon discovering Event ID 4963, take these immediate actions: First, determine the current state of all audit policies using 'auditpol /get /category:*' to understand the scope of changes. Second, investigate the event details to identify who made the change and when. Third, verify whether the change was authorized by checking with your change management system and the responsible administrator. Fourth, assess the security impact by determining what monitoring capabilities were lost. Finally, if unauthorized, immediately re-enable the appropriate audit policies and investigate potential security incidents that may have occurred during the monitoring gap.
Documentation

References (2)

1
Microsoft Learn - Advanced Security Audit PoliciesComprehensive guide to Windows advanced audit policies including object access auditing configuration and management.https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/advanced-security-audit-policies
2
Microsoft Documentation - Audit Object AccessOfficial documentation covering object access auditing policies, configuration, and security event details.https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/audit-object-access
Emanuel DE ALMEIDA
Written by

Emanuel DE ALMEIDA

Senior IT Journalist & Cloud Architect

Microsoft MCSA-certified Cloud Architect | Fortinet-focused. I modernize cloud, hybrid & on-prem infrastructure for reliability, security, performance and cost control - sharing field-tested ops & troubleshooting.

Tags
#event-id-4963#security-auditing#object-access

Related Windows Events

Windows security monitoring dashboard displaying audit events and privilege tracking logs
Event 6276
Microsoft-Windows-Security-Auditing
Windows EventInformation

Windows Event ID 6276 – Microsoft-Windows-Security-Auditing: Special Privileges Assigned to New Logon

Event ID 6276 records when special privileges are assigned to a user account during logon, indicating elevated access rights have been granted for the session.

March 189 min
Windows security monitoring dashboard displaying privilege assignment events in a professional SOC environment
Event 6274
Microsoft-Windows-Security-Auditing
Windows EventInformation

Windows Event ID 6274 – Microsoft-Windows-Security-Auditing: Special Privileges Assigned to New Logon

Event ID 6274 records when special privileges are assigned to a new user logon session, indicating elevated access rights have been granted for security-sensitive operations.

March 189 min
Network Policy Server monitoring dashboard showing authentication events and security logs
Event 6273
Microsoft-Windows-Security-Auditing
Windows EventInformation

Windows Event ID 6273 – Microsoft-Windows-Security-Auditing: Network Policy Server Granted Access

Event ID 6273 indicates that Network Policy Server (NPS) has granted network access to a user or device after successful authentication and authorization through RADIUS protocols.

March 189 min
Network operations center displaying Windows NPS authentication monitoring dashboards and security event logs
Event 6272
Microsoft-Windows-Security-Auditing
Windows EventInformation

Windows Event ID 6272 – Microsoft-Windows-Security-Auditing: Network Policy Server Granted Access

Event ID 6272 indicates that Network Policy Server (NPS) has granted network access to a user or device after successful authentication and authorization through RADIUS protocols.

March 1812 min

Discussion

Share your thoughts and insights

You must be logged in to comment.

Log in
Loading comments...