ANAVEM
Languagefr
Windows security monitoring dashboard displaying authentication package loading events in Event Viewer
Event ID 4610InformationMicrosoft-Windows-Security-AuditingWindows

Windows Event ID 4610 – LSA: Authentication Package Loaded

Event ID 4610 records when the Local Security Authority (LSA) loads an authentication package during system startup, indicating security subsystem initialization.

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

What This Event Means

Event ID 4610 represents a critical security audit event generated by the Windows Local Security Authority (LSA) subsystem. When Windows boots, the LSA must load various authentication packages to handle different authentication protocols and mechanisms. Each time an authentication package successfully loads, the system generates this event to provide an audit trail of security subsystem initialization.

The authentication packages loaded typically include standard Windows components like Kerberos (for domain authentication), NTLM (for legacy authentication), Negotiate (for protocol negotiation), and potentially custom authentication packages installed by third-party security software. The event provides transparency into which authentication mechanisms are available on the system.

From a security perspective, this event serves multiple purposes. It confirms that expected authentication packages are loading correctly during startup, helps identify when new authentication packages are installed, and provides forensic evidence of security subsystem state changes. Security teams monitor these events to detect unauthorized modifications to authentication infrastructure and ensure compliance with security policies.

The event data includes the authentication package name and relevant details about the loading process. This information proves valuable when troubleshooting authentication issues, conducting security audits, or investigating potential security incidents involving authentication subsystem modifications.

Applies to

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

Possible Causes

  • Normal system startup loading standard Windows authentication packages (Kerberos, NTLM, Negotiate)
  • Installation of third-party security software that registers custom authentication packages
  • Group Policy changes that modify authentication package configuration
  • Security updates that install new or updated authentication components
  • Domain controller role installation adding additional authentication packages
  • Smart card authentication software installation registering new authentication providers
  • Single Sign-On (SSO) solutions installing custom authentication modules
Resolution Methods

Troubleshooting Steps

01

Review Event Details in Event Viewer

Start by examining the specific authentication package details in Event Viewer to understand what loaded.

  1. Open Event Viewer by pressing Win + R, typing eventvwr.msc, and pressing Enter
  2. Navigate to Windows LogsSecurity
  3. Filter for Event ID 4610 by right-clicking the Security log and selecting Filter Current Log
  4. Enter 4610 in the Event IDs field and click OK
  5. Double-click on a 4610 event to view details
  6. Review the Authentication Package Name field to identify which package loaded
  7. Check the timestamp to correlate with system startup times
  8. Note any unusual or unexpected authentication package names
Pro tip: Standard packages include kerberos, ntlm, negotiate, and schannel. Any others may indicate third-party software installations.
02

Query Events with PowerShell

Use PowerShell to efficiently query and analyze authentication package loading events across multiple systems.

  1. Open PowerShell as Administrator
  2. Query recent 4610 events with this command:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4610} -MaxEvents 50 | Select-Object TimeCreated, Id, @{Name='AuthPackage';Expression={($_.Message -split '\n' | Where-Object {$_ -like '*Authentication Package Name:*'}) -replace '.*Authentication Package Name:\s*',''}}
  1. For detailed analysis of authentication packages loaded during last boot:
$LastBoot = (Get-CimInstance -ClassName Win32_OperatingSystem).LastBootUpTime
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4610; StartTime=$LastBoot} | ForEach-Object {
    $AuthPackage = ($_.Message -split '\n' | Where-Object {$_ -like '*Authentication Package Name:*'}) -replace '.*Authentication Package Name:\s*',''
    [PSCustomObject]@{
        TimeCreated = $_.TimeCreated
        AuthenticationPackage = $AuthPackage
        ProcessId = $_.ProcessId
    }
} | Sort-Object TimeCreated
  1. Export results to CSV for further analysis:
$Results | Export-Csv -Path "C:\Temp\AuthPackages_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation
03

Verify Authentication Package Registry Configuration

Examine the registry to understand which authentication packages are configured to load and identify any unauthorized additions.

  1. Open Registry Editor by pressing Win + R, typing regedit, and pressing Enter
  2. Navigate to the authentication packages registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
  1. Examine the Authentication Packages REG_MULTI_SZ value
  2. Check the Security Packages REG_MULTI_SZ value
  3. Document all listed packages and research any unfamiliar entries
  4. Use PowerShell to query registry values programmatically:
$LSAKey = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
$AuthPackages = Get-ItemProperty -Path $LSAKey -Name "Authentication Packages" -ErrorAction SilentlyContinue
$SecurityPackages = Get-ItemProperty -Path $LSAKey -Name "Security Packages" -ErrorAction SilentlyContinue

Write-Host "Authentication Packages:" -ForegroundColor Green
$AuthPackages."Authentication Packages" | ForEach-Object { Write-Host "  $_" }

Write-Host "\nSecurity Packages:" -ForegroundColor Green
$SecurityPackages."Security Packages" | ForEach-Object { Write-Host "  $_" }
Warning: Do not modify these registry values unless you understand the security implications. Incorrect changes can break authentication.
04

Monitor Authentication Package Changes

Set up monitoring to track when new authentication packages are installed or existing ones are modified.

  1. Create a PowerShell script to baseline current authentication packages:
# Create baseline of authentication packages
$BaselinePath = "C:\Scripts\AuthPackageBaseline.xml"
$LSAKey = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"

$Baseline = @{
    Timestamp = Get-Date
    AuthenticationPackages = (Get-ItemProperty -Path $LSAKey -Name "Authentication Packages")."Authentication Packages"
    SecurityPackages = (Get-ItemProperty -Path $LSAKey -Name "Security Packages")."Security Packages"
}

$Baseline | Export-Clixml -Path $BaselinePath
Write-Host "Baseline created at $BaselinePath" -ForegroundColor Green
  1. Create a monitoring script to detect changes:
# Compare current state to baseline
$BaselinePath = "C:\Scripts\AuthPackageBaseline.xml"
$Baseline = Import-Clixml -Path $BaselinePath
$LSAKey = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"

$Current = @{
    AuthenticationPackages = (Get-ItemProperty -Path $LSAKey -Name "Authentication Packages")."Authentication Packages"
    SecurityPackages = (Get-ItemProperty -Path $LSAKey -Name "Security Packages")."Security Packages"
}

$AuthDiff = Compare-Object $Baseline.AuthenticationPackages $Current.AuthenticationPackages
$SecDiff = Compare-Object $Baseline.SecurityPackages $Current.SecurityPackages

if ($AuthDiff -or $SecDiff) {
    Write-Host "Authentication package changes detected!" -ForegroundColor Red
    $AuthDiff | ForEach-Object { Write-Host "Auth Package: $($_.InputObject) ($($_.SideIndicator))" }
    $SecDiff | ForEach-Object { Write-Host "Security Package: $($_.InputObject) ($($_.SideIndicator))" }
} else {
    Write-Host "No changes detected" -ForegroundColor Green
}
  1. Schedule the monitoring script using Task Scheduler for regular checks
05

Advanced Security Analysis and Threat Hunting

Perform comprehensive analysis to identify potential security threats related to authentication package modifications.

  1. Create an advanced PowerShell analysis script:
# Advanced authentication package analysis
$StartDate = (Get-Date).AddDays(-30)
$Events = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4610; StartTime=$StartDate}

# Group by authentication package and analyze frequency
$PackageStats = $Events | ForEach-Object {
    $AuthPackage = ($_.Message -split '\n' | Where-Object {$_ -like '*Authentication Package Name:*'}) -replace '.*Authentication Package Name:\s*',''
    [PSCustomObject]@{
        Date = $_.TimeCreated.Date
        AuthPackage = $AuthPackage
        ProcessId = $_.ProcessId
    }
} | Group-Object AuthPackage | Select-Object Name, Count, @{Name='FirstSeen';Expression={($_.Group | Sort-Object Date)[0].Date}}, @{Name='LastSeen';Expression={($_.Group | Sort-Object Date)[-1].Date}}

$PackageStats | Format-Table -AutoSize
  1. Check for suspicious authentication package installations:
# Look for recently installed authentication packages
$RecentInstalls = Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045; StartTime=(Get-Date).AddDays(-7)} | Where-Object {$_.Message -like '*authentication*' -or $_.Message -like '*security*'}

$RecentInstalls | ForEach-Object {
    Write-Host "Service Installation: $($_.TimeCreated)" -ForegroundColor Yellow
    Write-Host $_.Message
    Write-Host "---"
}
  1. Correlate with software installation events:
# Check Windows Installer logs for security-related installations
$InstallerEvents = Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='MsiInstaller'; StartTime=(Get-Date).AddDays(-7)} | Where-Object {$_.Message -like '*security*' -or $_.Message -like '*authentication*'}

$InstallerEvents | Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List
  1. Generate a comprehensive security report:
# Generate security report
$Report = @{
    GeneratedDate = Get-Date
    AuthenticationPackages = $PackageStats
    RecentServiceInstalls = $RecentInstalls.Count
    RecentSoftwareInstalls = $InstallerEvents.Count
    SystemUptime = (Get-Date) - (Get-CimInstance -ClassName Win32_OperatingSystem).LastBootUpTime
}

$Report | ConvertTo-Json -Depth 3 | Out-File "C:\Temp\AuthPackageSecurityReport_$(Get-Date -Format 'yyyyMMdd_HHmm').json"
Pro tip: Correlate authentication package loading events with system changes, software installations, and security policy modifications for comprehensive threat analysis.

Overview

Event ID 4610 fires during Windows system startup when the Local Security Authority (LSA) loads authentication packages. This event appears in the Security log and indicates normal security subsystem initialization. The LSA manages authentication policies and processes, loading various authentication packages like Kerberos, NTLM, and custom authentication modules.

This event typically occurs once per boot cycle for each authentication package loaded by the system. On domain-joined machines, you'll see multiple 4610 events as different authentication packages initialize. The event contains details about which specific authentication package was loaded, providing visibility into the security subsystem's startup process.

While generally informational, monitoring these events helps track security subsystem health and detect unauthorized authentication package installations. Security administrators use this event to verify expected authentication mechanisms are loading correctly and identify potential security policy violations or malicious authentication package installations.

Frequently Asked Questions

What does Event ID 4610 mean and when does it occur?+
Event ID 4610 indicates that the Local Security Authority (LSA) has successfully loaded an authentication package during system startup. This event occurs once for each authentication package that loads, typically including standard Windows packages like Kerberos, NTLM, Negotiate, and any third-party authentication modules. The event fires during the boot process as the security subsystem initializes and is considered normal system behavior.
Should I be concerned about multiple Event ID 4610 entries?+
Multiple 4610 events are completely normal and expected. Windows loads several authentication packages by default, so you'll typically see 3-6 events per boot cycle. Each authentication package (Kerberos, NTLM, Negotiate, Schannel, etc.) generates its own 4610 event. Only be concerned if you see authentication packages you don't recognize or if the number of packages suddenly increases without explanation, which could indicate unauthorized software installation.
How can I identify which authentication packages are legitimate?+
Standard Windows authentication packages include: kerberos (domain authentication), ntlm (legacy authentication), negotiate (protocol negotiation), schannel (SSL/TLS), wdigest (digest authentication), tspkg (Terminal Services), pku2u (peer-to-peer authentication), and cloudap (Azure AD authentication). Any packages outside this list should be researched. Check the software manufacturer, installation date, and whether they correspond to legitimate security software you've installed.
Can Event ID 4610 help with troubleshooting authentication issues?+
Yes, Event ID 4610 is valuable for authentication troubleshooting. If users experience authentication problems, check if the expected authentication packages loaded successfully during startup. Missing 4610 events for required packages (like Kerberos on domain-joined machines) can indicate configuration problems. The event timestamps also help correlate authentication subsystem initialization with other system events that might affect authentication functionality.
How do I monitor for unauthorized authentication package installations?+
Create a baseline of your standard authentication packages using PowerShell to query the registry and Event ID 4610 events. Set up scheduled monitoring scripts that compare current authentication packages against your baseline and alert on changes. Monitor Event ID 7045 (service installations) for security-related services and correlate with 4610 events. Use Windows Event Forwarding to centrally collect these events from multiple systems for comprehensive monitoring across your environment.
Documentation

References (2)

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.

Discussion

Share your thoughts and insights

You must be logged in to comment.

Loading comments...