Security - Auditing & Logging
Privileged
PSM Security Setting - Process Creation Events Policy
Description: This policy setting determines what information is logged in security audit events when a new process has been created. This setting only applies when the Audit Process Creation policy is enabled. If you enable this policy setting the command line information for every process will be logged in plain text in the security event log as part of the Audit Process Creation event 4688, "a new process has been created," on the workstations and servers on which this policy setting is applied. If you disable or do not configure this policy setting, the process's command line information will not be included in Audit Process Creation events. Default: Not configured Note: When this policy setting is enabled, any user with access to read the security events will be able to read the command line arguments for any successfully created process. Command line arguments can contain sensitive or private information such as passwords or user data.
Why It's Important: This policy is like keeping a detailed log of every tool used and how it was used. By capturing command-line arguments, SHIELD provides deeper visibility into system activity, helping security teams detect suspicious behavior, investigate incidents, and trace malicious commands. While it may expose sensitive data in logs, the benefit of enhanced forensic capability and threat detection outweighs the risk in tightly controlled environments.
Learn More
PSM Security Setting - Credential Validation Policy
Description: This policy setting allows you to audit events generated by validation tests on user account logon credentials. Events in this subcategory occur only on the computer that is authoritative for those credentials. For domain accounts, the domain controller is authoritative. For local accounts, the local computer is authoritative.
Why It's Important: This policy is like keeping a log of every time someone tries to unlock a door—whether they succeed or not. By auditing both successful and failed credential validations, SHIELD helps detect unauthorized access attempts, monitor authentication activity, and support forensic investigations. It provides visibility into account usage and potential threats, making it a critical component of a secure and accountable authentication system.
Learn More
PSM Security Setting - Kerberos Auth Service Policy
Description: This policy setting allows you to audit events generated by Kerberos authentication ticket-granting ticket (TGT) requests. If you configure this policy setting, an audit event is generated after a Kerberos authentication TGT request. Success audits record successful requests and Failure audits record unsuccessful requests. If you do not configure this policy setting, no audit event is generated after a Kerberos authentication TGT request.
Why It's Important: This policy is like keeping a record of every time someone tries to get a key to access a secure area. By auditing Kerberos TGT requests, SHIELD provides visibility into authentication attempts, helping detect suspicious behavior, failed logons, or brute-force attacks. It supports forensic investigations, strengthens identity monitoring, and ensures accountability in environments that rely on Kerberos for secure access.
Learn More
PSM Security Setting - Service Ticket Operations Policy
Description: This policy setting allows you to audit events generated by Kerberos authentication ticket-granting ticket (TGT) requests submitted for user accounts. If you configure this policy setting, an audit event is generated after a Kerberos authentication TGT is requested for a user account. Success audits record successful requests and Failure audits record unsuccessful requests. If you do not configure this policy setting, no audit event is generated after a Kerberos authentication TGT is request for a user account.
Why It's Important: This policy is like tracking every time someone uses a key to access a specific room in a secure building. By auditing Kerberos service ticket operations, SHIELD provides visibility into how users are accessing network resources. It helps detect unauthorized access attempts, monitor service usage, and support investigations into suspicious activity. This is essential for maintaining accountability and strengthening identity-based security controls.
Learn More
PSM Security Setting - Logon Events Policy
Description: This policy setting allows you to audit events generated by responses to credential requests submitted for a user account logon that are not credential validation or Kerberos tickets. Currently, there are no events in this subcategory.
Why It's Important: This policy is like turning on a security camera in a hallway that’s rarely used—just in case something happens. By enabling auditing for other account logon events, SHIELD ensures that even lesser-known or future authentication-related activities are logged. It supports comprehensive visibility and readiness for evolving security needs, helping organizations stay ahead of potential threats and maintain a complete audit trail.
Learn More
PSM Security Setting - Account Logon Logoff Lockout Policy
Description: This policy setting allows you to audit events generated by a failed attempt to log on to an account that is locked out. If you configure this policy setting, an audit event is generated when an account cannot log on to a computer because the account is locked out. Success audits record successful attempts and Failure audits record unsuccessful attempts. Logon events are essential for understanding user activity and to detect potential attacks.
Why It's Important: This policy is like keeping a record every time someone tries to open a door that’s been locked due to too many failed attempts. By auditing account lockouts, SHIELD helps detect brute-force attacks, monitor user behavior, and troubleshoot authentication issues. It provides visibility into access failures and supports proactive security measures to protect user accounts and organizational resources.
Learn More
PSM Security Setting - Account Logon Group Membership Policy
Description: This policy setting allows you to audit events generated by a failed attempt to log on to an account that is locked out. If you configure this policy setting, an audit event is generated when an account cannot log on to a computer because the account is locked out. Success audits record successful attempts and Failure audits record unsuccessful attempts. Logon events are essential for understanding user activity and to detect potential attacks.
Why It's Important: This policy is like keeping a record every time someone tries to open a door that’s been locked due to too many failed attempts. By auditing account lockouts, SHIELD helps detect brute-force attacks, monitor user behavior, and troubleshoot authentication issues. It provides visibility into access failures and supports proactive security measures to protect user accounts and organizational resources.
Learn More
PSM Security Setting - IP Sec Extended Mode Policy
Description: This policy setting allows you to audit events generated by Internet Key Exchange protocol (IKE) and Authenticated Internet Protocol (AuthIP) during Extended Mode negotiations. If you configure this policy setting, an audit event is generated during an IPsec Extended Mode negotiation. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated during an IPsec Extended Mode negotiation.
Why It's Important: This policy is like logging every time two devices try to agree on a secure handshake. By auditing IPsec Extended Mode negotiations, SHIELD helps detect potential issues in secure communications, monitor for unauthorized connection attempts, and ensure that encrypted channels are being established properly. It supports network security visibility and helps identify misconfigurations or malicious activity targeting secure transport protocols.
Learn More
PSM Security Setting - IP Sec Main Mode Policy
Description: This policy setting allows you to audit events generated by Internet Key Exchange protocol (IKE) and Authenticated Internet Protocol (AuthIP) during Extended Mode negotiations. If you configure this policy setting, an audit event is generated during an IPsec Extended Mode negotiation. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated during an IPsec Extended Mode negotiation.
Why It's Important: This policy is like logging every time two devices try to agree on a secure handshake. By auditing IPsec Extended Mode negotiations, SHIELD helps detect potential issues in secure communications, monitor for unauthorized connection attempts, and ensure that encrypted channels are being established properly. It supports network security visibility and helps identify misconfigurations or malicious activity targeting secure transport protocols.
Learn More
PSM Security Setting - IP Sec Quick Mode Policy
Description: This policy setting allows you to audit events generated by Internet Key Exchange protocol (IKE) and Authenticated Internet Protocol (AuthIP) during Quick Mode negotiations. If you configure this policy setting, an audit event is generated during an IPsec Quick Mode negotiation. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated during an IPsec Quick Mode negotiation.
Why It's Important: This policy is like recording the final handshake between two parties before they start a secure conversation. By auditing IPsec Quick Mode negotiations, SHIELD ensures visibility into the establishment of encrypted sessions, helping detect failed or suspicious connection attempts. It supports network security monitoring and helps verify that secure channels are being properly negotiated and maintained across the tenant.
Learn More
PSM Security Setting - Audit Logoff Policy
Description: This policy setting allows you to audit events generated by the closing of a logon session. These events occur on the computer that was accessed. For an interactive logoff the security audit event is generated on the computer that the user account logged on to. If you configure this policy setting, an audit event is generated when a logon session is closed. Success audits record successful attempts to close sessions and Failure audits record unsuccessful attempts to close sessions. If you do not configure this policy setting, no audit event is generated when a logon session is closed.
Why It's Important: This policy is like noting when someone leaves a secure area. By auditing logoff events, SHIELD helps track the full lifecycle of user sessions, ensuring visibility into when access ends. It supports accountability, helps detect abnormal session behavior, and strengthens forensic capabilities by providing a complete picture of user activity across systems.
Learn More
PSM Security Setting - Audit Logon Policy
Description: This policy setting allows you to audit events generated by user account logon attempts on the computer. Events in this subcategory are related to the creation of logon sessions and occur on the computer which was accessed. For an interactive logon, the security audit event is generated on the computer that the user account logged on to. For a network logon, such as accessing a shared folder on the network, the security audit event is generated on the computer hosting the resource. The following events are included: Successful logon attempts. Failed logon attempts. Logon attempts using explicit credentials. This event is generated when a process attempts to log on an account by explicitly specifying that account’s credentials. This most commonly occurs in batch logon configurations, such as scheduled tasks or when using the RUNAS command. Security identifiers (SIDs) were filtered and not allowed to log on.
Why It's Important: This policy is like keeping a detailed guestbook of everyone who tries to enter a secure facility. By auditing logon events, SHIELD provides visibility into who is accessing systems, when, and how. It helps detect unauthorized access attempts, supports forensic investigations, and ensures accountability for user activity across the tenant. Capturing both successful and failed logons is essential for identifying potential threats and validating legitimate access.
Learn More
PSM Security Setting - Network Policy Server Policy
Description: This policy setting allows you to audit events generated by RADIUS (IAS) and Network Access Protection (NAP) user access requests. These requests can be Grant, Deny, Discard, Quarantine, Lock, and Unlock. If you configure this policy setting, an audit event is generated for each IAS and NAP user access request. Success audits record successful user access requests and Failure audits record unsuccessful attempts. If you do not configure this policy settings, IAS and NAP user access requests are not audited.
Why It's Important: This policy is like keeping a log of every time someone tries to enter a building and whether they were allowed in or turned away. By auditing access requests through the Network Policy Server, SHIELD helps monitor authentication and authorization decisions across the network. It supports detection of unauthorized access attempts, policy enforcement, and troubleshooting of access control issues—ensuring that network entry points are secure and accountable.
Learn More
PSM Security Setting - User Device Claims Policy
Description: This policy allows you to audit user and device claims information in the user's logon token. Events in this subcategory are generated on the computer on which a logon session is created. For an interactive logon, the security audit event is generated on the computer that the user logged on to. For a network logon, such as accessing a shared folder on the network, the security audit event is generated on the computer hosting the resource. User claims are added to a logon token when claims are included with a user's account attributes in Active Directory. Device claims are added to the logon token when claims are included with a device's computer account attributes in Active Directory. In addition, compound identity must be enabled for the domain and on the computer where the user logged on. When this setting is configured, one or more security audit events are generated for each successful logon. You must also enable the Audit Logon setting under Advanced Audit Policy Configuration\System Audit Policies\Logon/Logoff. Multiple events are generated if the user and device claims information cannot fit in a single security audit event.
Why It's Important: This policy is like recording not just who entered a secure area, but also what roles and permissions they carried with them. By auditing user and device claims, SHIELD provides deep visibility into the attributes used for access decisions. It helps validate that users and devices are being granted access based on correct identity data, supports troubleshooting of claims-based authorization issues, and strengthens compliance with role-based access policies.
Learn More
PSM Security Setting - Audit Application Group Management Policy
Description: This policy setting allows you to audit events generated by changes to application groups such as the following: Application group is created, changed, or deleted. Member is added or removed from an application group. If you configure this policy setting, an audit event is generated when an attempt to change an application group is made. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated when an application group changes.
Why It's Important: This policy is like keeping a record every time someone changes the guest list for a secure event. By auditing application group management, SHIELD ensures visibility into who is modifying access controls tied to applications. It helps detect unauthorized changes, supports compliance with access governance policies, and strengthens accountability by logging both successful and failed attempts to alter group memberships.
Learn More
PSM Security Setting - Computer Account Management Policy
Description: This policy setting allows you to audit events generated by changes to computer accounts such as when a computer account is created, changed, or deleted. If you configure this policy setting, an audit event is generated when an attempt to change a computer account is made. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated when a computer account changes.
Why It's Important: This policy is like keeping a log of every time a new device is added to a secure network or an existing one is modified. By auditing computer account management, SHIELD helps detect unauthorized changes, supports investigations into configuration issues, and ensures accountability for administrative actions. It’s essential for maintaining the integrity of device identities and enforcing change control across the tenant.
Learn More
PSM Security Setting - Distribution Group Management Policy
Description: This policy setting allows you to audit events generated by changes to distribution groups such as the following: Distribution group is created, changed, or deleted. Member is added or removed from a distribution group. Distribution group type is changed. If you configure this policy setting, an audit event is generated when an attempt to change a distribution group is made. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated when a distribution group changes. Note: Events in this subcategory are logged only on domain controllers.
Why It's Important: This policy is like keeping a record of every time someone updates a mailing list that controls who receives sensitive information. By auditing distribution group management, SHIELD ensures that changes to communication channels are tracked and verified. It helps detect unauthorized modifications, supports compliance with access control policies, and ensures accountability for group membership and structure changes.
Learn More
PSM Security Setting - Audit Other Account Management Events
Description: This policy setting allows you to audit events generated by other user account changes that are not covered in this category, such as the following: The password hash of a user account was accessed. This typically happens during an Active Directory Management Tool password migration. The Password Policy Checking API was called. Calls to this function can be part of an attack when a malicious application tests the policy to reduce the number of attempts during a password dictionary attack. Changes to the Default Domain Group Policy under the following Group Policy paths: Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy.
Why It's Important: This policy is like keeping a log of every time someone inspects or modifies the rules for how locks and keys work in a secure facility. By auditing these subtle but impactful account management actions, SHIELD ensures visibility into operations that could affect password strength, lockout behavior, or be exploited during attacks. It helps detect misuse of administrative tools, supports compliance, and strengthens the overall security posture of the tenant.
Learn More
PSM Security Setting - Authentication Policy Change Policy
Description: This policy setting allows you to audit events generated by changes to the authentication policy such as the following: Creation of forest and domain trusts. Modification of forest and domain trusts. Removal of forest and domain trusts. Changes to Kerberos policy under Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy. Granting of any of the following user rights to a user or group: Access This Computer From the Network. Allow Logon Locally. Allow Logon Through Terminal Services. Logon as a Batch Job. Logon a Service. Namespace collision. For example, when a new trust has the same name as an existing namespace name. If you configure this policy setting, an audit event is generated when an attempt to change the authentication policy is made. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated when the authentication policy is changed. Note: The security audit event is logged when the group policy is applied. It does not occur at the time when the settings are modified.
Why It's Important: This policy is like tracking every time someone changes the rules for who can enter a secure facility and how they prove their identity. By auditing authentication policy changes, SHIELD ensures that modifications to trust relationships, logon permissions, and Kerberos configurations are recorded. It helps detect unauthorized or risky changes, supports compliance with identity governance standards, and strengthens the integrity of access control across the tenant.
Learn More
PSM Security Setting - Authorization Policy Change Policy
Description: This policy setting allows you to audit events generated by changes to the authorization policy such as the following: Assignment of user rights (privileges), such as SeCreateTokenPrivilege, that are not audited through the “Authentication Policy Change” subcategory. Removal of user rights (privileges), such as SeCreateTokenPrivilege, that are not audited through the “Authentication Policy Change” subcategory. Changes in the Encrypted File System (EFS) policy. Changes to the Resource attributes of an object. Changes to the Central Access Policy (CAP) applied to an object. If you configure this policy setting, an audit event is generated when an attempt to change the authorization policy is made. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated when the authorization policy changes.
Why It's Important: This policy is like tracking every time someone changes the rules for who can access what inside a secure facility. By auditing authorization policy changes, SHIELD ensures visibility into modifications that affect access control, encryption policies, and resource permissions. It helps detect unauthorized privilege assignments, supports compliance with access governance standards, and reinforces the integrity of security configurations across the tenant.
Learn More
PSM Security Setting - Changes to Audit Policy
Description: This policy setting allows you to audit changes in the security audit policy settings such as the following: Settings permissions and audit settings on the Audit Policy object. Changes to the system audit policy. Registration of security event sources. De-registration of security event sources. Changes to the per-user audit settings. Changes to the value of CrashOnAuditFail. Changes to the system access control list on a file system or registry object. Changes to the Special Groups list. Note: System access control list (SACL) change auditing is done when a SACL for an object changes and the policy change category is enabled. Discretionary access control list (DACL) and ownership changes are audited when object access auditing is enabled and the object's SACL is configured for auditing of DACL/Owner change.
Why It's Important: This policy is like keeping a record of every time someone changes the rules for what gets recorded in your security logs. By auditing changes to the audit policy itself, SHIELD ensures that any attempts to weaken or bypass logging mechanisms are detected. It helps maintain the integrity of the audit trail, supports compliance with regulatory requirements, and protects against insider threats or misconfigurations that could obscure malicious activity.
Learn More
PSM Security Setting - Directory Service Changes Policy
Description: This policy setting allows you to audit events generated by changes to objects in Active Directory Domain Services (AD DS). Events are logged when an object is created, deleted, modified, moved, or undeleted. When possible, events logged in this subcategory indicate the old and new values of the object’s properties. Events in this subcategory are logged only on domain controllers, and only objects in AD DS with a matching system access control list (SACL) are logged. Note: Actions on some objects and properties do not cause audit events to be generated due to settings on the object class in the schema. If you configure this policy setting, an audit event is generated when an attempt to change an object in AD DS is made. Success audits record successful attempts, however unsuccessful attempts are NOT recorded. If you do not configure this policy setting, no audit event is generated when an attempt to change an object in AD DS object is made.
Why It's Important: This policy is like keeping a detailed log of every time someone adds, removes, or changes a file in a secure archive. By auditing directory service changes, SHIELD ensures visibility into critical modifications within Active Directory, which is the backbone of identity and access management in most enterprise environments. It helps detect unauthorized changes, supports forensic investigations, and reinforces the integrity of the directory structure across the tenant.
Learn More
PSM Security Setting - File Share Access Policy
Description: This policy setting allows you to audit attempts to access a shared folder. If you configure this policy setting, an audit event is generated when an attempt is made to access a shared folder. If this policy setting is defined, the administrator can specify whether to audit only successes, only failures, or both successes and failures. Note: There are no system access control lists (SACLs) for shared folders. If this policy setting is enabled, access to all shared folders on the system is audited.
Why It's Important: This policy is like monitoring every time someone tries to open a shared cabinet in a secure office. By auditing file share access, SHIELD ensures visibility into how shared resources are being used, helping detect unauthorized access, data exfiltration attempts, or misconfigured permissions. It supports incident response, compliance, and proactive monitoring of sensitive data access across the tenant.
Learn More
PSM Security Setting - Other Logon Logoff Events Policy
Description: This policy setting allows you to audit other logon/logoff-related events that are not covered in the “Logon/Logoff” policy setting such as the following: Terminal Services session disconnections. New Terminal Services sessions. Locking and unlocking a workstation. Invoking a screen saver. Dismissal of a screen saver. Detection of a Kerberos replay attack, in which a Kerberos request was received twice with identical information. This condition could be caused by network misconfiguration. Access to a wireless network granted to a user or computer account. Access to a wired 802.1x network granted to a user or computer account.
Why It's Important: This policy is like monitoring the side entrances and internal movements within a secure facility—not just the main door. By auditing these additional logon/logoff events, SHIELD ensures visibility into user interactions that could signal suspicious behavior, such as repeated session disconnections, unexpected network access, or replay attacks. It strengthens situational awareness, supports forensic investigations, and helps maintain a secure and well-monitored tenant environment.
Learn More
PSM Security Setting - Security Group Management Policy
Description: This policy setting allows you to audit events generated by changes to security groups such as the following: Security group is created, changed, or deleted. Member is added or removed from a security group. Group type is changed. If you configure this policy setting, an audit event is generated when an attempt to change a security group is made. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated when a security group changes.
Why It's Important: This policy is like keeping a log of every time someone updates the list of people allowed into a secure area. By auditing security group management, SHIELD ensures that changes to group memberships and permissions are tracked and verified. It helps detect unauthorized modifications, supports compliance with access governance policies, and reinforces accountability for administrative actions that impact user access across the tenant.
Learn More
PSM Security Setting - Security System Extension
Description: This policy setting allows you to audit events related to security system extensions or services such as the following: A security system extension, such as an authentication, notification, or security package is loaded and is registered with the Local Security Authority (LSA). It is used to authenticate logon attempts, submit logon requests, and any account or password changes. Examples of security system extensions are Kerberos and NTLM. A service is installed and registered with the Service Control Manager. The audit log contains information about the service name, binary, type, start type, and service account. If you configure this policy setting, an audit event is generated when an attempt is made to load a security system extension. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated when an attempt is made to load a security system extension.
Why It's Important: This policy is like logging every time a new security checkpoint is added to a facility. By auditing the loading of security system extensions, SHIELD ensures visibility into critical components that handle authentication and security operations. It helps detect unauthorized or suspicious changes to the system’s security infrastructure, supports compliance, and strengthens the integrity of the authentication framework across the tenant.
Learn More
PSM Security Setting - Special Logon Policy
Description: This policy setting allows you to audit events generated by special logons such as the following: The use of a special logon, which is a logon that has administrator-equivalent privileges and can be used to elevate a process to a higher level. A logon by a member of a Special Group. Special Groups enable you to audit events generated when a member of a certain group has logged on to your network. You can configure a list of group security identifiers (SIDs) in the registry. If any of those SIDs are added to a token during logon and the subcategory is enabled, an event is logged.
Why It's Important: This policy is like flagging every time someone with master keys enters a secure facility. By auditing special logons, SHIELD ensures that privileged access is closely monitored. It helps detect misuse of elevated permissions, supports compliance with least privilege principles, and strengthens accountability for high-risk user activity across the tenant.
Learn More
PSM Security Setting - User Account Management Policy
Description: This policy setting allows you to audit changes to user accounts. Events include the following: A user account is created, changed, deleted; renamed, disabled, enabled, locked out, or unlocked. A user account’s password is set or changed. A security identifier (SID) is added to the SID History of a user account. The Directory Services Restore Mode password is configured. Permissions on administrative user accounts are changed. Credential Manager credentials are backed up or restored. If you configure this policy setting, an audit event is generated when an attempt to change a user account is made. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated when a user account changes.
Why It's Important: This policy is like keeping a detailed log of every time someone updates a user’s access badge or credentials. By auditing user account management, SHIELD ensures visibility into all changes that affect identity and access. It helps detect unauthorized modifications, supports compliance with identity governance policies, and reinforces accountability for administrative actions across the tenant.
Learn More
PSM Security Setting - Audit DPAPI Activity Policy
Description: This policy setting allows you to audit events generated when encryption or decryption requests are made to the Data Protection application interface (DPAPI). DPAPI is used to protect secret information such as stored password and key information. If you configure this policy setting, an audit event is generated when an encryption or decryption request is made to DPAPI. Success audits record successful requests and Failure audits record unsuccessful requests. If you do not configure this policy setting, no audit event is generated when an encryption or decryption request is made to DPAPI.
Why It's Important: This policy is like logging every time someone tries to lock or unlock a secure vault. By auditing DPAPI activity, SHIELD ensures visibility into how sensitive data is being protected or accessed. It helps detect unauthorized attempts to decrypt protected information, supports forensic investigations, and reinforces the integrity of data protection mechanisms across the tenant.
Learn More
PSM Security Setting - Audit PNP Activity
Description: This policy setting allows you to audit when plug and play detects an external device. If you configure this policy setting, an audit event is generated whenever plug and play detects an external device. Only Success audits are recorded for this category. If you do not configure this policy setting, no audit event is generated when an external device is detected by plug and play.
Why It's Important: This policy is like logging every time someone plugs a new device into a secure workstation. By auditing PnP activity, SHIELD helps detect unauthorized or unexpected hardware connections, such as USB drives or external peripherals. It supports data loss prevention, insider threat detection, and compliance with device control policies—especially in environments where physical access is tightly regulated.
Learn More
PSM Security Setting - Audit Process Creation Policy
Description: This policy setting allows you to audit events generated when a process is created or starts. The name of the application or user that created the process is also audited. If you configure this policy setting, an audit event is generated when a process is created. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated when a process is created.
Why It's Important: This policy is like logging every time a new tool is picked up and used in a secure workspace. By auditing process creation, SHIELD helps detect potentially malicious activity, such as the execution of unauthorized scripts, malware, or suspicious applications. It supports threat detection, forensic investigations, and behavioral analysis, helping security teams understand what’s running on systems and who initiated it.
Learn More
PSM Security Setting - Audit Process Termination
Description: This policy setting allows you to audit events generated when a process ends. If you configure this policy setting, an audit event is generated when a process ends. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated when a process ends.
Why It's Important: This policy is like logging every time someone finishes using a tool in a secure environment. By auditing process termination, SHIELD helps track when and how applications or scripts stop running. It supports forensic investigations, helps detect abnormal or suspicious behavior (such as unexpected process crashes or forced terminations), and contributes to a complete picture of system activity for security monitoring.
Learn More
PSM Security Setting - Audit RPC Events
Description: This policy setting allows you to audit inbound remote procedure call (RPC) connections. If you configure this policy setting, an audit event is generated when a remote RPC connection is attempted. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated when a remote RPC connection is attempted.
Why It's Important: This policy is like logging every time someone tries to remotely control or communicate with a system. By auditing RPC events, SHIELD helps detect unauthorized or suspicious remote access attempts, supports investigation of service interactions, and strengthens monitoring of distributed systems. It’s especially important in environments where remote management and inter-process communication are common and need to be tightly controlled.
Learn More
PSM Security Setting - Audit Token Right Adjusted Policy
Description: This policy setting allows you to audit events generated by adjusting the privileges of a token. A token represents a user's identity and permissions during a session, and adjusting its rights can affect what actions the user or process is allowed to perform.
Why It's Important: This policy is like logging every time someone changes the level of access a person has inside a secure facility. By auditing token right adjustments, SHIELD helps detect privilege escalation attempts, monitor sensitive changes to user or process permissions, and ensure that access rights are being modified only through authorized channels. It’s a key control for maintaining least privilege and preventing abuse of elevated permissions.
Learn More
PSM Security Setting - Audit Detailed Directory Service Replication
Description: This policy setting allows you to audit events generated by detailed Active Directory Domain Services (AD DS) replication between domain controllers.
Why It's Important: This policy is like tracking every time a copy of a secure document is sent between offices. By auditing AD DS replication, SHIELD ensures that changes to directory data are properly monitored as they propagate across domain controllers. It helps detect replication issues, supports troubleshooting and forensic investigations, and ensures the integrity of identity and access data throughout the tenant.
Learn More
PSM Security Setting - Audit Directory Service Access Policy
Description: This policy setting allows you to audit events generated when an Active Directory Domain Services (AD DS) object is accessed. Only AD DS objects with a matching system access control list (SACL) are logged. Events in this subcategory are similar to the Directory Service Access events available in previous versions of Windows.
Why It's Important: This policy is like logging every time someone opens a file cabinet in a secure archive. By auditing access to AD DS objects, SHIELD helps detect unauthorized access to sensitive directory data, supports investigations into privilege misuse, and ensures accountability for changes or reads within the directory. It’s essential for maintaining the integrity and security of identity and access management across the tenant.
Learn More
PSM Security Setting - Audit Directory Service Replication Policy
Description: This policy setting allows you to audit replication between two Active Directory Domain Services (AD DS) domain controllers. If you configure this policy setting, an audit event is generated during AD DS replication. Success audits record successful replication and Failure audits record unsuccessful replication. If you do not configure this policy setting, no audit event is generated during AD DS replication.
Why It's Important: This policy is like tracking every time a secure document is copied and sent between trusted offices. By auditing AD DS replication, SHIELD ensures that changes to identity and access data are properly monitored as they propagate across domain controllers. It helps detect replication failures, misconfigurations, or unauthorized replication attempts, supporting both operational integrity and security compliance across the tenant.
Learn More
PSM Security Setting - Audit Application Generated Policy
Description: This policy setting allows you to audit applications that generate events using the Windows Auditing application programming interfaces (APIs). Applications designed to use the Windows Auditing API use this subcategory to log auditing events related to their function. Events in this subcategory include: Creation of an application client context. Deletion of an application client context. Initialization of an application client context. Other application operations using the Windows Auditing APIs.
Why It's Important: This policy is like allowing trusted apps to write entries in the security logbook. By auditing application-generated events, SHIELD ensures that custom or third-party software actions are visible and traceable. It helps detect misuse, supports compliance with audit requirements, and provides a more complete picture of system activity—especially in environments where applications play a key role in business or security operations.
Learn More
PSM Security Setting - Audit Central Access Policy Staging
Description: This policy is like running a simulation to see how new security rules would affect access before officially applying them. By auditing Central Access Policy staging, SHIELD helps organizations safely evaluate the impact of proposed changes to access controls. It ensures that new policies won’t unintentionally block legitimate access or open up sensitive resources. This proactive approach supports secure policy development and minimizes disruptions during policy transitions.
Why It's Important: This policy setting allows you to audit access requests where the permission granted or denied by a proposed policy differs from the current central access policy on an object. If you configure this policy setting, an audit event is generated each time a user accesses an object and the permission granted by the current central access policy on the object differs from that granted by the proposed policy. The resulting audit event will be generated as follows: 1) Success audits, when configured, records access attempts when the current central access policy grants access but the proposed policy denies access. 2) Failure audits when configured records access attempts when: a) The current central access policy does not grant access but the proposed policy grants access. b) A principal requests the maximum access rights they are allowed and the access rights granted by the current central access policy are different than the access rights granted by the proposed policy. Volume: Potentially high on a file server when the proposed policy differs significantly from the current central access policy.
Learn More
PSM Security Setting - Audit Certification Services Policy
Description: This policy setting allows you to audit Active Directory Certificate Services (AD CS) operations. AD CS operations include the following: AD CS startup/shutdown/backup/restore. Changes to the certificate revocation list (CRL). New certificate requests. Issuing of a certificate. Revocation of a certificate. Changes to the Certificate Manager settings for AD CS. Changes in the configuration of AD CS. Changes to a Certificate Services template. Importing of a certificate. Publishing of a certification authority certificate is to Active Directory Domain Services. Changes to the security permissions for AD CS. Archival of a key. Importing of a key. Retrieval of a key. Starting of Online Certificate Status Protocol (OCSP) Responder Service. Stopping of Online Certificate Status Protocol (OCSP) Responder Service.
Why It's Important: This policy is like logging every time someone issues, revokes, or modifies a digital ID in a secure system. By auditing AD CS activity, SHIELD ensures visibility into the lifecycle of certificates and key management operations. It helps detect unauthorized certificate issuance, supports compliance with PKI governance, and strengthens trust in identity and encryption services across the tenant.
Learn More
PSM Security Setting - Audit Detailed File Share Policy
Description: This policy setting allows you to audit attempts to access files and folders on a shared folder. The Detailed File Share setting logs an event every time a file or folder is accessed, whereas the File Share setting only records one event for any connection established between a client and file share. Detailed File Share audit events include detailed information about the permissions or other criteria used to grant or deny access. If you configure this policy setting, an audit event is generated when an attempt is made to access a file or folder on a share. The administrator can specify whether to audit only successes, only failures, or both successes and failures. Note: There are no system access control lists (SACLs) for shared folders. If this policy setting is enabled, access to all shared files and folders on the system is audited.
Why It's Important: This policy is like recording every time someone opens a drawer in a shared filing cabinet—not just when they enter the room. By auditing detailed file share access, SHIELD provides granular visibility into how shared resources are used. It helps detect unauthorized access, supports forensic investigations, and ensures compliance with data protection policies—especially in environments where sensitive files are frequently accessed over the network.
Learn More
PSM Security Setting - Audit File System Policy
Description: This policy setting allows you to audit user attempts to access file system objects. A security audit event is generated only for objects that have system access control lists (SACL) specified, and only if the type of access requested, such as Write, Read, or Modify and the account making the request match the settings in the SACL. If you configure this policy setting, an audit event is generated each time an account accesses a file system object with a matching SACL. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated when an account accesses a file system object with a matching SACL. Note: You can set a SACL on a file system object using the Security tab in that object's Properties dialog box.
Why It's Important: This policy is like logging every time someone tries to open, edit, or delete a file in a secure archive. By auditing file system access, SHIELD ensures visibility into how sensitive data is being used or targeted. It helps detect unauthorized access, supports forensic investigations, and enforces compliance with data protection policies—especially in environments where file-level security is critical.
Learn More
PSM Security Setting - Audit Filtering Platform Connection Policy
Description: This policy setting allows you to audit connections that are allowed or blocked by the Windows Filtering Platform (WFP). The following events are included: The Windows Firewall Service blocks an application from accepting incoming connections on the network. The WFP allows a connection. The WFP blocks a connection. The WFP permits a bind to a local port. The WFP blocks a bind to a local port. The WFP allows a connection. The WFP blocks a connection. The WFP permits an application or service to listen on a port for incoming connections. The WFP blocks an application or service to listen on a port for incoming connections. If you configure this policy setting, an audit event is generated when connections are allowed or blocked by the WFP. Success audits record events generated when connections are allowed and Failure audits record events generated when connections are blocked. If you do not configure this policy setting, no audit event is generated when connected are allowed or blocked by the WFP.
Why It's Important: This policy is like monitoring every time someone tries to open or close a gate in a secure network. By auditing WFP connection events, SHIELD ensures visibility into how applications and services interact with the network. It helps detect unauthorized access attempts, supports firewall policy enforcement, and strengthens network security posture across the tenant by capturing detailed connection behavior.
Learn More
PSM Security Setting - Audit Filtering Platform Packet Drop Policy
Description: This policy setting allows you to audit packets that are dropped by Windows Filtering Platform (WFP).
Why It's Important: This policy is like logging every time a security checkpoint rejects a suspicious package. By auditing dropped packets, SHIELD helps detect and investigate potential threats, misconfigurations, or policy violations at the network level. It provides visibility into blocked traffic, supports troubleshooting of connectivity issues, and strengthens network defense by ensuring that packet filtering actions are monitored and accountable.
Learn More
PSM Security Setting - Audit Handle Manipulation Policy
Description: This policy setting allows you to audit events generated when a handle to an object is opened or closed. Only objects with a matching system access control list (SACL) generate security audit events. If you configure this policy setting, an audit event is generated when a handle is manipulated. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated when a handle is manipulated. Note: Events in this subcategory generate events only for object types where the corresponding Object Access subcategory is enabled. For example, if File system object access is enabled, handle manipulation security audit events are generated. If Registry object access is not enabled, handle manipulation security audit events will not be generated.
Why It's Important: This policy is like logging every time someone picks up or puts down a key to access a secure area. By auditing handle manipulation, SHIELD helps track how system resources are being accessed and used. It supports detailed forensic analysis, helps detect suspicious behavior (like unauthorized access attempts), and ensures that sensitive objects are monitored throughout their lifecycle.
Learn More
PSM Security Setting - Audit Kernel Object Policy
Description: This policy setting allows you to audit attempts to access the kernel, which include mutexes and semaphores. Only kernel objects with a matching system access control list (SACL) generate security audit events. Note: The Audit: Audit the access of global system objects policy setting controls the default SACL of kernel objects.
Why It's Important: This policy is like logging every time someone tries to interact with the core machinery of a secure system. By auditing kernel object access, SHIELD helps detect and investigate attempts to manipulate low-level system resources that could affect system stability or security. It supports early detection of advanced threats, such as privilege escalation or process injection, and reinforces the integrity of the operating environment.
Learn More
PSM Security Setting - Audit Other Object Access Events Policy
Description: This policy setting allows you to audit events generated by the management of task scheduler jobs or COM+ objects. For scheduler jobs, the following are audited: Job created. Job deleted. Job enabled. Job disabled. Job updated. For COM+ objects, the following are audited: Catalog object added. Catalog object updated. Catalog object deleted.
Why It's Important: This policy is like logging every time someone sets or changes an automated task or system component behind the scenes. By auditing these lesser-known but impactful object access events, SHIELD ensures visibility into system automation and component-level changes. It helps detect unauthorized modifications, supports operational integrity, and strengthens accountability for background system activities that could affect performance or security.
Learn More
PSM Security Setting - Audit Registry Policy
Description: This policy setting allows you to audit attempts to access registry objects. A security audit event is generated only for objects that have system access control lists (SACLs) specified, and only if the type of access requested, such as Read, Write, or Modify, and the account making the request match the settings in the SACL. If you configure this policy setting, an audit event is generated each time an account accesses a registry object with a matching SACL. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated when an account accesses a registry object with a matching SACL. Note: You can set a SACL on a registry object using the Permissions dialog box.
Why It's Important: This policy is like logging every time someone tries to open or change a secure settings file in the operating system. By auditing registry access, SHIELD ensures visibility into how critical system configurations are being accessed or modified. It helps detect unauthorized changes, supports forensic investigations, and reinforces the integrity of system settings—especially in environments where registry tampering could lead to security breaches or system instability.
Learn More
PSM Security Setting - Audit Removable Storage Policy
Description: This policy setting allows you to audit user attempts to access file system objects on a removable storage device. A security audit event is generated only for all objects for all types of access requested. If you configure this policy setting, an audit event is generated each time an account accesses a file system object on a removable storage. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated when an account accesses a file system object on a removable storage.
Why It's Important: This policy is like logging every time someone tries to open, copy, or change a file on a portable device. By auditing removable storage access, SHIELD helps detect unauthorized data transfers, supports data loss prevention strategies, and strengthens protection against insider threats. It ensures that all interactions with removable media are monitored, which is critical in environments where sensitive data must be tightly controlled.
Learn More
PSM Security Setting - Audit SAM Policy
Description: This policy setting allows you to audit events generated by attempts to access to Security Accounts Manager (SAM) objects. SAM objects include the following: SAM_ALIAS -- A local group. SAM_GROUP -- A group that is not a local group. SAM_USER – A user account. SAM_DOMAIN – A domain. SAM_SERVER – A computer account. If you configure this policy setting, an audit event is generated when an attempt to access a kernel object is made. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated when an attempt to access a kernel object is made. Note: Only the System Access Control List (SACL) for SAM_SERVER can be modified. Volume: High on domain controllers.
Why It's Important: This policy is like monitoring every time someone tries to view or change the master list of users and groups in a secure system. By auditing access to SAM objects, SHIELD ensures visibility into attempts to interact with core identity data. It helps detect unauthorized access, supports investigations into privilege misuse, and reinforces the integrity of account management across the tenant—especially in high-security environments where domain controllers are critical.
Learn More
PSM Security Setting - Audit Filtering Platform Policy Change
Description: This policy setting allows you to audit events generated by changes to the Windows Filtering Platform (WFP) such as the following: IPsec services status. Changes to IPsec policy settings. Changes to Windows Firewall policy settings. Changes to WFP providers and engine. If you configure this policy setting, an audit event is generated when a change to the WFP is attempted. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated when a change occurs to the WFP.
Why It's Important: This policy is like logging every time someone changes the rules that control which doors are locked or unlocked in a secure facility. By auditing WFP policy changes, SHIELD ensures visibility into modifications that affect network traffic filtering and security enforcement. It helps detect unauthorized or risky changes to firewall and IPsec configurations, supports compliance with network security policies, and reinforces the integrity of traffic control mechanisms across the tenant
Learn More
PSM Security Setting - Audit MPSSVC Rule Level Policy Change Policy
Description: This policy setting allows you to audit events generated by changes in policy rules used by the Microsoft Protection Service (MPSSVC). This service is used by Windows Firewall. Events include the following: Reporting of active policies when Windows Firewall service starts. Changes to Windows Firewall rules. Changes to Windows Firewall exception list. Changes to Windows Firewall settings. Rules ignored or not applied by Windows Firewall Service. Changes to Windows Firewall Group Policy settings. If you configure this policy setting, an audit event is generated by attempts to change policy rules used by the MPSSVC. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated by changes in policy rules used by the MPSSVC.
Why It's Important: This policy is like logging every time someone updates the rules that determine what traffic is allowed through the gates of a secure network. By auditing MPSSVC rule-level changes, SHIELD ensures visibility into modifications that directly affect host-based firewall behavior. It helps detect unauthorized changes, supports compliance with network security policies, and reinforces the integrity of endpoint protection across the tenant.
Learn More
PSM Security Setting - Audit Other Policy Change Events
Description: This policy setting allows you to audit events generated by other security policy changes that are not audited in the policy change category, such as the following: Trusted Platform Module (TPM) configuration changes. Kernel-mode cryptographic self tests. Cryptographic provider operations. Cryptographic context operations or modifications. Applied Central Access Policies (CAPs) changes. Boot Configuration Data (BCD) modifications.
Why It's Important: This policy is like logging every time someone tweaks the underlying security framework of a system. By auditing these specialized policy changes, SHIELD ensures visibility into critical operations that could affect encryption, boot integrity, or access control. It helps detect tampering, supports compliance with security standards, and reinforces trust in the system’s foundational security mechanisms across the tenant.
Learn More
PSM Security Setting - Audit Non Sensitive Privilege Use Policy
Description: This policy setting allows you to audit events generated by the use of non-sensitive privileges (user rights). The following privileges are non-sensitive: Access Credential Manager as a trusted caller. Access this computer from the network. Add workstations to domain. Adjust memory quotas for a process. Allow log on locally. Allow log on through Terminal Services. Bypass traverse checking. Change the system time. Create a pagefile. Create global objects. Create permanent shared objects. Create symbolic links. Deny access this computer from the network. Deny log on as a batch job. Deny log on as a service. Deny log on locally. Deny log on through Terminal Services. Force shutdown from a remote system. Increase a process working set. Increase scheduling priority. Lock pages in memory. Log on as a batch job. Log on as a service. Modify an object label. Perform volume maintenance tasks. Profile single process. Profile system performance. Remove computer from docking station. Shut down the system. Synchronize directory service data. If you configure this policy setting, an audit event is generated when a non-sensitive privilege is called. Success audits record successful calls and Failure audits record unsuccessful calls. If you do not configure this policy setting, no audit event is generated when a non-sensitive privilege is called.
Why It's Important: This policy is like tracking every time someone uses basic tools in a secure environment. By auditing non-sensitive privilege use, SHIELD ensures visibility into routine but potentially impactful actions. It helps detect misuse of everyday privileges, supports investigations into suspicious behavior, and reinforces accountability for system-level operations that could affect performance, availability, or security.
Learn More
PSM Security Setting - Audit Other Privilege Use Events Policy
Description: Not used. Even though this policy is not currently used, SHIELD enables it to ensure readiness for future Windows updates or feature expansions that may begin logging events under this category. It’s like installing a surveillance camera in a hallway that’s not yet in use—ready to capture activity the moment it becomes relevant. This proactive approach supports forward compatibility and ensures comprehensive audit coverage as the platform evolves. This policy setting is reserved for future use and currently does not generate any audit events. It is not actively used to track any specific privilege-related actions.
Why It's Important: [coming soon]
Learn More
PSM Security Setting - Audit Sensitive Privilege Use Policy
Description: This policy setting allows you to audit events generated when sensitive privileges (user rights) are used such as the following: A privileged service is called. One of the following privileges are called: Act as part of the operating system. Back up files and directories. Create a token object. Debug programs. Enable computer and user accounts to be trusted for delegation. Generate security audits. Impersonate a client after authentication. Load and unload device drivers. Manage auditing and security log. Modify firmware environment values. Replace a process-level token. Restore files and directories. Take ownership of files or other objects. If you configure this policy setting, an audit event is generated when sensitive privilege requests are made. Success audits record successful requests and Failure audits record unsuccessful requests. If you do not configure this policy setting, no audit event is generated when sensitive privilege requests are made.
Why It's Important: This policy is like logging every time someone uses master-level tools that can override or bypass normal security controls. By auditing sensitive privilege use, SHIELD ensures visibility into powerful actions that could be exploited for privilege escalation, system compromise, or unauthorized access. It helps detect abuse of elevated permissions, supports forensic investigations, and reinforces the principle of least privilege across the tenant.
Learn More
PSM Security Setting - Audit IPsec Driver Policy
Description: This policy setting allows you to audit events generated by the IPsec filter driver such as the following: Startup and shutdown of the IPsec services. Network packets dropped due to integrity check failure. Network packets dropped due to replay check failure. Network packets dropped due to being in plaintext. Network packets received with incorrect Security Parameter Index (SPI). This may indicate that either the network card is not working correctly or the driver needs to be updated. Inability to process IPsec filters. If you configure this policy setting, an audit event is generated on an IPsec filter driver operation. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated on an IPSec filter driver operation.
Why It's Important: This policy is like monitoring every time a security checkpoint allows or rejects a package based on its contents and integrity. By auditing IPsec driver activity, SHIELD ensures visibility into the enforcement of secure network communications. It helps detect misconfigurations, potential attacks, or hardware issues that could compromise encrypted traffic. This strengthens the tenant’s network security posture and supports troubleshooting and compliance efforts.
Learn More
PSM Audit Settings - System Audit Other System Events
Description: This policy setting allows you to audit any of the following events: Startup and shutdown of the Windows Firewall service and driver. Security policy processing by the Windows Firewall Service. Cryptography key file and migration operations.
Why It's Important: This policy is like monitoring every time a secure tunnel is opened or closed, and logging when something suspicious tries to pass through. By auditing IPsec driver activity, SHIELD ensures visibility into the enforcement of encrypted communications and network-level protections. It helps detect misconfigurations, potential attacks, or hardware issues that could compromise secure traffic. This strengthens the tenant’s network security posture and supports troubleshooting and compliance efforts.
Learn More
PSM Audit Settings - System Audit Security State Change
Description: This policy setting allows you to audit events generated by changes in the security state of the computer such as the following events: Startup and shutdown of the computer. Change of system time. Recovering the system from CrashOnAuditFail, which is logged after a system restarts when the security event log is full and the CrashOnAuditFail registry entry is configured.
Why It's Important: This policy is like logging every time the security system itself is turned on, off, or reset. By auditing security state changes, SHIELD ensures visibility into critical system-level transitions that could signal tampering, misconfiguration, or recovery from a failure. It helps detect suspicious restarts, unauthorized time changes, and ensures that audit failures are properly tracked—reinforcing the reliability and integrity of the tenant’s security monitoring.
Learn More
PSM Audit Settings - System Audit System Integrity
Description: This policy setting allows you to audit events that violate the integrity of the security subsystem, such as the following: Events that could not be written to the event log because of a problem with the auditing system. A process that uses a local procedure call (LPC) port that is not valid in an attempt to impersonate a client by replying, reading, or writing to or from a client address space. The detection of a Remote Procedure Call (RPC) that compromises system integrity. The detection of a hash value of an executable file that is not valid as determined by Code Integrity. Cryptographic operations that compromise system integrity.
Why It's Important: This policy is like monitoring the health of the security system itself. By auditing system integrity events, SHIELD ensures visibility into deep-level issues that could indicate tampering, malware activity, or misconfigurations. It helps detect attempts to bypass security controls, supports early threat detection, and reinforces trust in the system’s foundational protections across the tenant.
Learn More
PSM Security Setting - Settings Auditing Policy
Description: This policy setting controls whether Windows records attempts to connect with the OneSettings service to the EventLog. If you enable this policy, Windows will record attempts to connect with the OneSettings service to the Microsoft\Windows\Privacy-Auditing\Operational EventLog channel. If you disable or don't configure this policy setting, Windows will not record attempts to connect with the OneSettings service to the EventLog.
Why It's Important: This policy enables logging of all system attempts to connect to Microsoft’s OneSettings service. Turning on auditing helps administrators monitor, verify, and document telemetry-related connections for compliance, privacy control, and security oversight. It provides traceability for configuration and diagnostic data exchanges between Windows and Microsoft services.
Learn More
- [coming soon]