Core Infrastructure and Security Blog

24 MIN READ

Application Control for Business, Schema Definition

Microsoft

Mar 18, 2025

Watching my miniature schnauzer, Raven, explore my backyard, I’m reminded of the importance of having a clear set of rules and guidelines. Just like Raven has her own schema to navigate her environment—knowing where she can wander, where she shouldn't venture, and how to interact. Application Control for Business (ACfB) provides a robust schema to help organizations manage and secure their digital landscapes.

Note: ACfB has also been known as Windows Defender Application Control (WDAC), Application Control for Windows and Code Integrity.

Application Control for Windows | Microsoft Learn

In Raven's serene world, her schema might look something like this:

Safe Zones: The grassy lawn where she can leisurely sniff around and her favorite shady spot under the tree.
Restricted Zones: The delicate garden beds and the tempting koi pond, which are off-limits to her curious paws.
Behavior Rules: Guidelines for greeting other animals and people, ensuring she remains the friendly neighborhood pup.

Similarly, ACfB's schema defines the rules and guidelines for managing applications and code within an organization:

Approved Applications: Software that is allowed to run, ensuring it is safe and trusted.
Restricted Applications: Programs that are blocked from execution to prevent potential security threats.
Execution Rules: Policies that dictate how applications can interact with the system, ensuring a secure and controlled environment.

For Raven, following her schema with precision is key. It keeps her out of trouble and ensures she enjoys her outdoor time without any mishaps. The order of her schema is equally important. She needs to know the safe zones before understanding the restricted ones, and she must learn the behavior rules to interact safely with others.

Similarly, for organizations, adhering to ACfB's schema is crucial. It ensures that only approved applications run, restricted applications are blocked, and execution rules are followed, maintaining a secure and efficient digital landscape.

Similarly, ACfB's schema defines precise rules for applications, ensuring that only trusted software runs on your systems, protecting against malicious code and unauthorized access. The order in which these rules and policies are defined is critical. Just as Raven's schema order helps her navigate her environment effectively, the correct order of elements in the ACfB schema ensures that the policy is correctly interpreted and enforced.

Application Control for Business - Schema Overview

The ACfB schema provides a comprehensive framework for defining rules and policies that control which applications are allowed to run on your systems. It ensures that only trusted applications are executed, enhancing security and compliance.

XML Structure Overview

The XML structure used in the schema provides a high-level view of how the elements and attributes are organized. This structure ensures that the policy is correctly interpreted and enforced by Application Control for Business.

Policy Information

This section includes metadata about the policy, such as its name, ID, version, and description. It provides essential information for identifying and managing different policies.

SiPolicy Elements (Policy controls)

Detailed descriptions of the elements that control the policy, such as rules for allowing or blocking applications. These elements define the core functionality of the policy.

Rules

Definitions of the various rules that can be applied within the policy, specifying what is allowed or denied. These rules are crucial for controlling application behavior.

FileRules

Specific rules related to files, including how they are identified and controlled. This section ensures that only trusted files are allowed to execute.

Signers

Information about the entities that sign the applications, ensuring they are trusted. This section is crucial for maintaining the integrity and trustworthiness of applications.

SigningScenarios

Different scenarios in which signing is used, providing context for when and how applications should be signed. This section helps ensure that signing practices are consistently applied.

CiSigners

Information about code integrity signers, who are responsible for ensuring the integrity of the code. This section is crucial for maintaining code integrity.

Settings

General settings for the policy, including various configuration options. These settings control the overall behavior of the policy.

EKUs

Extended Key Usages, which specify the purposes for which a certificate can be used. This section ensures that certificates are used appropriately.

UpdatePolicySigners

Information about the signers who are authorized to update the policy. This section ensures that only trusted entities can modify the policy.

HVCIOptions

Detailed descriptions of the hypervisor-protected code integrity options. These details define the characteristics and configurations of each option.

Macros

Definitions of macros used within the policy, allowing for reusable configurations. This section provides flexibility and efficiency in policy management.

SupplementalPolicySigners

Information about additional signers who can supplement the main policy. This section ensures that the policy can be extended and updated as needed.

SupplementalPolicySigners Elements and Attributes

Application Control for Business Schema

The ACfB schema, as defined in the provided file (CiPolicy.xsd), is a comprehensive XML schema that outlines the structure and rules for creating and managing security policies within the Application Control for Business framework. This schema includes various elements and attributes that specify how policies are constructed, validated, and enforced. Key components of the schema include definitions for file rules, signers, signing scenarios, and policy settings, each with specific attributes and nested elements that provide detailed control over the security configurations.

The primary purpose of the ACfB schema is to enhance the security posture of Windows environments by ensuring that only trusted and verified code is allowed to execute. By defining rules for allowing or denying specific files, managing trusted signers, and specifying conditions under which certain policies apply, the ACfB schema helps administrators create granular and flexible security policies. These policies protect against unauthorized code execution, maintain system integrity, and ensure compliance with organizational security standards.

Application Control Bypass

ACfB provides the ability to lock down endpoints effectively, but there are some potential bypasses that need to be addressed. Certain legitimate applications, such as powershell.exe, msbuild.exe, and wscript.exe, can be exploited by attackers to circumvent these controls. Blocking these applications is recommended unless they are absolutely necessary for business operations.

Additionally, keeping software up to date is crucial to mitigate vulnerabilities. For instance, older versions of BGInfo are vulnerable and should be blocked, while the latest version has resolved these security issues. The security community has been instrumental in identifying these vulnerabilities and helping to protect users. Following these recommendations is vital to ensure our systems remain secure.

For complete details, please refer to the full article on Microsoft's website:

Applications that can bypass App Control and how to block them | Microsoft Learn

XML Structure Overview

An ACfB policy XML file consists of several key sections:

Policy Information: Metadata about the policy.
Rules: Definitions of what is allowed or denied.
File Rules: Specific rules for files and applications.
Signing Rules: Rules for signed applications and drivers.

Policy Information

The <SiPolicy> Root Element is used to define the overall security policy for the system. This element encompasses various configurations and settings that dictate how the security policy is enforced. It includes details such as policy type, policy rules, and other critical parameters that ensure the integrity and security of the system. By configuring <SiPolicy>, organizations can establish a comprehensive security framework that governs the behavior of applications and code execution on the system.

SiPolicy
\|-----	Attributes
\|	\|-----	FriendlyName
\|	\|-----	PolicyType
\|		\|------------------------	"Base Policy"
\|		\|------------------------	"Supplemental Policy"
\|		\|------------------------	"AppID Tagging Policy"
\|
\|-----	Elements
	\|-----	VersionEx 1, 2
	\|-----	PolicyTypeID *2
	\|-----	PlatformID 1, 2
	\|-----	PolicyID * 2
	\|-----	BasePolicyID *2
	\|-----	Rules
		\|----- Rule
	\|-----	EKUs
	\|-----	FileRules
	\|-----	Signers
	\|-----	SigningScenarios
	\|-----	UpdatePolicySigners
	\|-----	CiSigners
	\|-----	HvciOptions
	\|-----	Settings
	\|-----	Macros
	\|-----	SupplementalPolicySigners
	\|-----	AppSettings

	*1 - Required
	*2 - These elements are used for defining and managing the ACfB policies on an endpoint.

SiPolicy Elements (Policy controls)

Element Names	Description
VersionEx	Specifies the extended version of the policy.
PolicyTypeID	Used to uniquely identify and manage different types of polices
PolicyID	The unique identifier for the policy.
BasePolicyID	The GUID of the base policy, if applicable.
PlatformID	The identifier for the platform the policy applies to.

</SiPolicy>

There are a total of 17 sub-elements available under <SiPolicy> in a ACfB policy XML file.

Element Names	Description	Notes
<VersionEx>	Specifies the version of the System Integrity policy.	Required
<PolicyTypeID>	Unique identifier for the policy type.
<PlatformID>	Unique identifier for the platform.	Required
<PolicyID>	Unique identifier for the policy.
<BasePolicyID>	Unique identifier for the base policy.
<Rules>	The <Rules> sub-element is used to define various options and settings related to the rules enforced by the policy. These options can include configurations such as enabling or disabling specific rule types, setting enforcement levels, and other parameters that control how the rules are applied. By configuring <RulesOptions>, organizations can fine-tune the behavior of their security policies to meet specific requirements and ensure that the rules are enforced in a manner that aligns with their security objectives.	Contains a sequence of <Rule> elements defining various policy rules.
<EKUs>	The <EKUs> element defines Extended Key Usage (EKU) settings for the ACfB policy. EKUs specify the purposes for which a certificate can be used, such as code signing or server authentication. This element can include multiple EKU definitions, each specified within an <EKU> element. By defining EKUs, administrators can ensure that only certificates with the appropriate usage attributes are trusted, providing an additional layer of security for the system.	Collection of Extended Key Usage (EKU) elements.
FileRules	The <FileRules> element specifies how applications and drivers are identified and allowed or denied. This element can include rules based on file attributes, hashes, paths, publishers, and certificates. For example, you can allow a specific file by its hash or allow all files in a particular directory. The flexibility of <FileRules> allows administrators to create granular policies that precisely control which files are permitted to execute, enhancing the security posture of the system.	Collection of file rules.
Signers	The <Signers> element defines trusted signers for applications and drivers. This element can include various types of signers, such as FilePublisher, LeafCertificate, PcaCertificate, and RootCertificate. Each signer type specifies different levels of trust, from individual files to entire certificate chains. By defining trusted signers, administrators can ensure that only applications and drivers signed by recognized entities are allowed to run, reducing the risk of malware and unauthorized software.	Collection of signers.
SigningScenarios	The <SigningScenarios> element specifies different scenarios under which signing rules apply. This element can include scenarios for drivers, Windows components, and other specific use cases. Each scenario is defined within a <SigningScenario> element, which includes details such as the scenario value, ID, and friendly name. By defining signing scenarios, administrators can create policies that apply different rules based on the context in which an application or driver is executed, providing more nuanced control over software execution.	Collection of signing scenarios.
UpdatePolicySigners	The <UpdatePolicySigners> element defines signers that are trusted to update the ACfB policy. This element can include various types of signers, such as FilePublisher, LeafCertificate, PcaCertificate, and RootCertificate. By specifying trusted update policy signers, administrators can ensure that only authorized entities can modify the ACfB policy, preventing unauthorized changes that could compromise the security of the system.	Collection of signers for system integrity policy updating.
CiSigners	The <CiSigners> element defines Code Integrity signers that are trusted for all builds, including retail builds. This element is typically used to include enterprise signers or production signers that are trusted across the organization. By specifying trusted Code Integrity signers, administrators can ensure that only code signed by recognized entities is allowed to run, enhancing the overall security of the system.	Collection of signers trusted for CI signing levels.
HvciOptions	Hypervisor-Protected Code Integrity (HVCI) leverages virtualization-based security (VBS) to ensure that only trusted code runs in kernel mode	Specifies (HVCI) settings.
Settings	The <Settings> element includes additional settings for the ACfB policy. This element can define various configuration options, such as policy information, enterprise-defined settings, and other custom settings. Each setting is specified within a <Setting> element, which includes details such as the provider, key, value name, and value. By configuring these settings, administrators can customize the behavior of the ACfB policy to meet the specific needs of their organization.	Collection of setting elements.
Macros	The <Macros> element defines a collection of macro definitions that can be used throughout the policy. Macros allow for text substitution, making it easier to manage and update policy configurations. Each macro is defined within a <Macro> element, which includes an ID and a value. By using macros, administrators can simplify the policy management process and ensure consistency across different policy elements.	Collection of macro definitions.
SupplementalPolicySigners	The <SupplementalPolicySigners> element defines a collection of signers for supplemental policies. These signers are trusted to sign additional policies that extend or modify the base policy. By specifying supplemental policy signers, administrators can ensure that only authorized entities can create or update supplemental policies, maintaining the integrity and security of the overall policy framework.	Collection of signers for supplemental policies.
AppSettings	The <AppSettings> element defines a collection of application settings. These settings can include various configuration options specific to applications, such as manifest paths and custom settings. Each application setting is defined within an <App> element, which includes details such as the manifest path and individual settings. By configuring application settings, administrators can tailor the behavior of specific applications to meet organizational requirements.	Collection of application settings.

Rules

The <Rules> sub-element is used to organize and manage various rules within the policy. It contains a sequence of <Rule> elements, each defined by the Rules complex type. These rules specify configurations such as enabling or disabling specific options, setting enforcement levels, and other parameters that control how the rules are applied. By configuring the <Rules> sub-element, organizations can fine-tune the behavior of their security policies to meet specific requirements and ensure that the rules are enforced in a manner that aligns with their security objectives.

Rules
\|------	Rule
	\|------	RuleType
		\|------	Option
			\|------	Enabled:UMCI
			\|------	Enabled:Boot Menu Protection
			\|------	Enabled:Intelligent Security Graph Authorization
			\|------	Enabled:Invalidate EAs on Reboot
			\|------	Required:WHQL
			\|------	Enabled:Developer Mode Dynamic Code Trust
			\|------	Enabled:Allow Supplemental Policies
			\|------	Disabled:Runtime FilePath Rule Protection
			\|------	Enabled:Revoked Expired As Unsigned
			\|------	Enabled:Audit Mode
			\|------	Disabled:Flight Signing
			\|------	Enabled:Inherit Default Policy
			\|------	Enabled:Unsigned System Integrity Policy
			\|------	Enabled:Dynamic Code Security
			\|------	Required:EV Signers
			\|------	Enabled:Boot Audit On Failure
			\|------	Enabled:Advanced Boot Options Menu
			\|------	Disabled:Script Enforcement
			\|------	Required:Enforce Store Applications
			\|------	Enabled:Secure Setting Policy
			\|------	Enabled:Managed Installer
			\|------	Enabled:Update Policy No Reboot
			\|------	Enabled:Conditional Windows Lockdown Policy

Rules Options

Option Types	Description
Enabled:UMCI	Enables User Mode Code Integrity (UMCI), ensuring that only trusted code runs in user mode.
Enabled:Boot Menu Protection	Enables protection for the boot menu, preventing unauthorized changes to boot configurations.
Enabled:Intelligent Security Graph Authorization	Utilizes the Intelligent Security Graph to authorize applications, enhancing security by leveraging Microsoft's threat intelligence.
Enabled:Invalidate EAs on Reboot	Invalidates Extended Attributes (EAs) on reboot, ensuring that any changes to EAs are not persistent across reboots.
Required:WHQL	Requires that drivers are Windows Hardware Quality Labs (WHQL) certified, ensuring they meet Microsoft's quality standards.
Enabled:Developer Mode Dynamic Code Trust	Enables dynamic code trust for developer mode, allowing developers to run and test code that may not be signed.
Enabled:Allow Supplemental Policies	Allows the use of supplemental policies, which can extend or modify the base policy.
Disabled:Runtime FilePath Rule Protection	Disables runtime protection for file path rules, potentially reducing security but allowing more flexibility.
Enabled:Revoked Expired As Unsigned	Treats revoked or expired certificates as unsigned, preventing code signed with such certificates from running.
Enabled:Audit Mode	Enables audit mode, which logs policy violations without enforcing them, useful for testing and monitoring.
Disabled:Flight Signing	Disables flight signing, which is used for pre-release software testing.
Enabled:Inherit Default Policy	Allows the policy to inherit settings from the default policy, ensuring consistency and reducing configuration effort.
Enabled:Unsigned System Integrity Policy	Enables the use of unsigned system integrity policies, which can be useful in certain testing or development scenarios.
Enabled:Dynamic Code Security	Enhances security by enabling dynamic code security measures, which help protect against runtime code modifications.
Required:EV Signers	Requires Extended Validation (EV) certificates for code signing, providing a higher level of trust.
Enabled:Boot Audit On Failure	Enables auditing of boot failures, helping to diagnose and troubleshoot boot issues.
Enabled:Advanced Boot Options Menu	Enables the advanced boot options menu, providing additional boot options for troubleshooting and recovery.
Disabled:Script Enforcement	Disables enforcement of script policies, allowing scripts to run without being subject to policy restrictions.
Required:Enforce Store Applications	Requires that only applications from the Microsoft Store are allowed to run, enhancing security by restricting software sources.
Enabled:Secure Setting Policy	Enables secure setting policies, which enforce additional security settings.
Enabled:Managed Installer	Allows the use of a managed installer, which can install and manage applications according to policy.
Enabled:Update Policy No Reboot	Enables policy updates without requiring a reboot, reducing downtime and improving user experience.
Enabled:Conditional Windows Lockdown Policy	Enables conditional lockdown policies, which can enforce stricter security measures based on certain conditions.

<Rules>

<Rule>

<Option>Enabled:Unsigned System Integrity Policy</Option>

</Rule>

<Rule>

<Option>Enabled:Advanced Boot Options Menu</Option>

</Rule>

Rule>

<Option>Disabled:Script Enforcement</Option>

</Rule>

</Rules>

FileRules

The <FileRules> sub-element is used to define various options and settings related to file rules enforced by the policy. These options can include configurations such as specifying file types to be monitored, setting enforcement levels for different file operations, and other parameters that control how file rules are applied. By configuring <FileRules>, organizations can customize the behavior of their file security policies to meet specific requirements and ensure that file operations are monitored and controlled in a manner that aligns with their security objectives.

FileRules
\|------	Allow
\|	\|--------	ID *1
\|	\|--------	FriendlyName
\|	\|--------	FileName
\|	\|--------	InternalName
\|	\|--------	FileDescription
\|	\|--------	ProductName
\|	\|--------	PackageFamilyName
\|	\|--------	PackageVersion
\|	\|--------	MinimumFileVersion
\|	\|--------	MaximumFileVersion
\|	\|--------	Hash
\|	\|--------	AppIDs
\|	\|--------	FilePath
\|
\|------	Deny
\|	\|--------	ID *1
\|	\|--------	FriendlyName
\|	\|--------	FileName
\|	\|--------	InternalName
\|	\|--------	FileDescription
\|	\|--------	ProductName
\|	\|--------	PackageFamilyName
\|	\|--------	PackageVersion
\|	\|--------	MinimumFileVersion
\|	\|--------	MaximumFileVersion
\|	\|--------	Hash
\|	\|--------	AppIDs
\|	\|--------	FilePath
\|
\|------	FileAttrib
\|	\|--------	ID *1
\|	\|--------	FriendlyName
\|	\|--------	FileName
\|	\|--------	InternalName
\|	\|--------	FileDescription
\|	\|--------	ProductName
\|	\|--------	PackageFamilyName
\|	\|--------	PackageVersion
\|	\|--------	MinimumFileVersion
\|	\|--------	MaximumFileVersion
\|	\|--------	Hash
\|	\|--------	AppIDs
\|	\|--------	FilePath
\|
\|------	FileRule
	\|--------	ID *1
	\|--------	FriendlyName
	\|--------	FileName
	\|--------	InternalName
	\|--------	FileDescription
	\|--------	ProductName
	\|--------	PackageFamilyName
	\|--------	PackageVersion
	\|--------	MinimumFileVersion
	\|--------	MaximumFileVersion
	\|--------	Hash
	\|--------	AppIDs
	\|--------	FilePath
	\|--------	Type *1
		\|-------------------	"Match"
		\|-------------------	"Exclude"
		\|-------------------	"Attribute"

	*1 = Required

FileRules Elements and Attributes

There are 4 elements and 13 attributes available for FileRules. The elements specify how applications and drivers are identified and allowed or denied based on various attributes within the ACfB policy. The attributes allow administrators to specify criteria based on various properties of files, such as their cryptographic hash, file name, file path, publisher's certificate, and more. This ensures that only trusted and verified files are permitted to execute

Element Names	Attribute Names	Description
Allow Deny FileAttrib FileRule	AppIDs	Application IDs associated with the file, used for additional identification and management.
	FileDescription	A description of the file, providing more context about its purpose and usage.
	FileName	Specifies the name of the file to allow. Ensures that only files with this exact name are permitted to run.
	FilePath	Specifies the path of the file to allow. Ensures that only files located in this specific path are permitted to run.
	FriendlyName	A user-friendly name for the rule, making it easier to identify and manage.
	Hash	Specifies the cryptographic hash of the file to allow. Provides a high level of security by ensuring that only the exact file with this hash is permitted to run.
	ID	Unique identifier for the rule. (Required)
	InternalName	The internal name of the file, often used for additional verification.
	MaximumFileVersion	Specifies the maximum version of the file to allow. Prevents the execution of potentially outdated or insecure versions.
	MinimumFileVersion	Specifies the minimum version of the file to allow. Ensures that only updated and secure versions are permitted.
	PackageFamilyName	The package family name for the file, used to group related files together.
	PackageVersion	The version of the package that the file belongs to, ensuring compatibility and version control.
	ProductName	The name of the product associated with the file, helping to identify the software it belongs to.
FileRule (only)	Type	Specifies the type of rule being applied, such as Match, Exclude, or Attribute. This attribute defines the condition under which the rule applies, allowing for precise control over how files are identified and managed. (Required)

</FileRules>

Signers

The <Signers> sub-element is a collection of <Signer> elements that are trusted to sign applications and drivers. It includes various sub-elements that define the details of each signer. These options can include configurations such as specifying the criteria for trusted signers, setting validation levels for signer certificates, and other parameters that control how signers are managed and verified. By configuring <Signers>, organizations can ensure that only authorized and trusted signers are allowed, enhancing the security and integrity of the system by preventing unauthorized code from being executed.

Sub-element:<Signer> of <Signers>

The <Signer> sub-element defines an individual signer and includes several attributes and nested elements that specify the details of the signer's certificate and other relevant information.

Signers
\|------	Signer
	\|------	Attributes
	\|	\|------	Name
	\|	\|------	ID
	\|	\|------	SignTimeAfter
	\|
	\|------	Certroot *1
	\|	\|------	Attribute
	\|		\|------	Type *1
			\|	\|-----	"TBS"
			\|	\|-----	"WellKnown"
			\|
	\|		\|------	Value *1
	\|------	CertEKU
	\|	\|------	Attribute
	\|		\|------	ID *1
	\|------	CertIssuer
	\|	\|------	Attribute
	\|		\|------	Value *1
	\|------	CertPublisher
	\|	\|------	Attribute
	\|		\|------	Value *1
	\|------	CertOemID
	\|	\|------	Attribute
	\|		\|------	Value *1
	\|------	FileAttribRef
		\|------	Attribute
			\|------	RuleID *1

	*1 = Required

Signers Elements and Attributes

Element Names	Attribute Names	Description
Signers		A collection of Signer elements that define individual signers trusted to sign applications and drivers.
Signer	Name	Specifies the name of the signer.
	ID	Unique identifier for the signer.
	SignTimeAfter	Specifying the time after which the signer's certificate is valid.
CertRoot	Type	Specifies the root certificate for a signer. (Required)
	Value	Specifies the value of the root certificate in hexBinary form.
CertEKU	ID	Specifies the EKU ID.
CertIssuer	Value	Specifies the value of the issuer certificate.
CertPublisher	Value	Specifies the value of the publisher certificate.
CertOemID	Value	Specifies the value of the OEM ID.
FileAttribRef	RuleID	References a file attribute rule through its ID.

</FileRules>

</Signer>

</Signer>

</Signers>

SigningScenarios

The <SigningScenarios> element is used to define the different scenarios in which code signing is required or trusted. These scenarios specify the conditions under which code must be signed to be considered valid and executable. By configuring <SigningScenarios>, organizations can enforce code signing policies that ensure only authorized and trusted code is allowed to run. This helps in maintaining the integrity and security of the system by preventing the execution of unauthorized or malicious code.

SigningScenarios
	\|
	SigningScenario
	\|----------	Attributes
	\|	\|----------	ID *1
	\|	\|----------	FriendlyName
	\|	\|----------	Value *1
	\|	\|----------	InheritedScenarios
	\|	\|----------	MinimumHashAlgorithm
	\|
	\|----------	ProductSigners *1
	\|	\|----------	AllowedSigners
	\|	\|	\|---------------	Attributes
	\|	\|	\|	\|---------	Workaround
	\|	\|	\|
	\|	\|	\|---------------	AllowedSigner
	\|	\|		\|---------	Attributes
	\|	\|		\|	\|-------	SignerId
	\|	\|		\|
	\|	\|		\|---------	ExceptDenyRule
	\|	\|			\|-------	Attributes
	\|	\|----------	DeniedSigners			\|-------	DenyRuleId
	\|	\|	\|---------------	Attributes
	\|	\|	\|	\|---------	Workaround
	\|	\|	\|
	\|	\|	\|---------------	DeniedSigner
	\|	\|		\|---------	Attributes
	\|	\|		\|	\|-------	SignerId
	\|	\|		\|
	\|	\|		\|---------	ExceptAllowRule
	\|	\|			\|-------	Attributes
	\|	\|----------	FileRulesRef			\|-------	AllowRuleId
	\|		\|---------------	Atributes
	\|		\|	\|---------	Workaround
	\|		\|
	\|		\|---------------	FileRuleRef
	\|			\|---------	RuleId
	\|
	\|----------	TestSigners
	\|	\|----------	AllowedSigners
	\|	\|	\|---------------	Attributes
	\|	\|	\|	\|---------	Workaround
	\|	\|	\|
	\|	\|	\|---------------	AllowedSigner
	\|	\|		\|---------	Attributes
	\|	\|		\|	\|-------	SignerId
	\|	\|		\|
	\|	\|		\|---------	ExceptDenyRule
	\|	\|			\|-------	Attributes
	\|	\|----------	DeniedSigners			\|-------	DenyRuleId
	\|	\|	\|---------------	Attributes
	\|	\|	\|	\|---------	Workaround
	\|	\|	\|
	\|	\|	\|---------------	DeniedSigner
	\|	\|		\|---------	Attributes
	\|	\|		\|	\|-------	SignerId
	\|	\|		\|
	\|	\|		\|---------	ExceptAllowRule
	\|	\|			\|-------	Attributes
	\|	\|----------	FileRulesRef			\|-------	AllowRuleId
	\|		\|---------------	Atributes
	\|		\|	\|---------	Workaround
	\|		FileRuleRef
	\|		\|---------------	Atributes
	\|		\|	\|---------	Workaround
	\|		\|
	\|		\|---------------	FileRuleRef
	\|			\|---------	RuleId
	\|
	\|----------	TestSigningSigners
	\|	\|----------	AllowedSigners
	\|	\|	\|---------------	Attributes
	\|	\|	\|	\|---------	Workaround
	\|	\|	\|
	\|	\|	\|---------------	AllowedSigner
	\|	\|		\|---------	Attributes
	\|	\|		\|	\|-------	SignerId
	\|	\|		\|
	\|	\|		\|---------	ExceptDenyRule
	\|	\|			\|-------	Attributes
	\|	\|----------	DeniedSigners			\|-------	DenyRuleId
	\|	\|	\|---------------	Attributes
	\|	\|	\|	\|---------	Workaround
	\|	\|	\|
	\|	\|	\|---------------	DeniedSigner
	\|	\|		\|---------	Attributes
	\|	\|		\|	\|-------	SignerId
	\|	\|		\|
	\|	\|		\|---------	ExceptAllowRule
	\|	\|			\|-------	Attributes
	\|	\|----------	FileRulesRef			\|-------	AllowRuleId
	\|		\|---------------	Atributes
	\|		\|	\|---------	Workaround
	\|		FileRuleRef
	\|		\|---------------	Atributes
	\|		\|	\|---------	Workaround
	\|		\|
	\|		\|---------------	FileRuleRef
	\|			\|---------	RuleId
	\|
	\|----------	AppIDTags
		\|----------	Attributes
		\|	\|---------------	EnforceDLL
		\|
		\|----------	AppIDTag
			\|---------------	Attributes
				\|---------	Key
				\|---------	Value

	*1 = Required

SigningScenarios Elements and Attributes

Element Names	Nested Elements	Attribute Name	Description
SigningScenarios		ID	A unique identifier for the signing scenario.
		FriendlyName	Helps in easily identifying and managing the signing scenario.
		InheritedScenarios	Allows the signing scenario to inherit rules and settings from other defined scenarios, promoting reuse and consistency.
		MinimumHashAlgorithm	Ensures that only cryptographic hashes meeting the specified algorithm criteria are considered valid.
		Value	Required and defines the specific context or condition under which the signing scenario applies.
ProductSigners, TestSigners, TestSigningSigners	AllowedSigners	WorkAround	Provides flexibility in handling specific scenarios or exceptions that may not be directly addressed by the standard schema definitions, allowing for customized solutions to unique challenges.
	AllowedSigner	SignerId	Each signer can be distinctly recognized and referenced within the ACfB policy, allowing for precise control over which signers are trusted or denied.
	AllowedSigner/ExceptDenyRule	DenyRuleId	Used in the ExceptDenyRule element to reference a specific deny rule, making the allow rule conditional based on the deny rule.
	DeniedSigners	WorkAround	Provides flexibility in handling specific scenarios or exceptions that may not be directly addressed by the standard schema definitions, allowing for customized solutions to unique challenges.
	DeniedSigner	SignerId	Used in the AllowedSigner and DeniedSigner elements to distinctly recognize and reference each signer.
	DeniedSigner/ExceptAllowRule	AllowRuleId	Specification of the AllowRuleId.
	FileRulesRef	Workaround	Provides flexibility in handling specific scenarios or exceptions that may not be directly addressed by the standard schema definitions, allowing for customized solutions to unique challenges.
	FileRuleRef	RuleId	Specifies the ID of the file rule.
AppIDTags	EnforceDLL		If enabled ensures that only trusted DLLs are allowed to load.
	AddIDTag	Key	Specifies the key for the application ID tag.
		Value	Specifies the value for the application ID tag.

CiSigners

<CiSigners> are signers that ConfigCI asks CI to trust for all builds, including retail builds.

Normally CiSigners is empty or only includes production signers. For enterprise ConfigCI policy, you may need to include enterprise signers. Just make sure it is understood that CiSigners will be trusted by CI for ALL builds.

CiSigners
\|------	CiSigner *1
	\|------	Attribute
		\|------	SignerId

	*1 = Required

Element Names	Attribute Names	Description
CiSigners		A collection of CiSigner elements.
CiSigner	SignerId	To distinctly recognize and reference each signer within the ACfB policy. <cisigner />

Element Names

Attribute Names

Description

CiSigners

A collection of CiSigner elements.

CiSigner

SignerId

To distinctly recognize and reference each signer within the ACfB policy.

CiSigners Elements and Attributes

</CiSigners>

Settings

The <Settings> sub-element is used to define various configuration settings for the policy. These settings can include options such as enabling or disabling specific features, setting enforcement levels, and other parameters that control the behavior of the policy. By configuring <Settings>, organizations can customize the policy to meet their specific security requirements and operational needs. This helps in ensuring that the policy is applied in a manner that aligns with the organization's security objectives and operational practices.

Settings
\|-----	Setting
	\|-----	Attribute
	\|	\|-----	Provider *1
	\|	\|-----	Key *1
	\|	\|-----	ValueName *1
	\|
	\|-----	Value
		\|-----	SettingValueType *1
			\|------------	BooleanType
			\|------------	DWordType
			\|------------	xs:hexBinary
			\|------------	xs:string

	*1 = Required

Settings, Elements, Attributes and SettingValueType

Element Names	Attribute Names	Description
Settings		Collection of Setting(s).
Setting	Provider	Specifies the source or context of the setting. Required
	Key	Defines the category or type of information the setting pertains to. Required
	ValueName	Specifies the name of the specific value being set. Required
Setting/Value/SettingValueType Required	BooleanType	Represents a Boolean value, which can be either true or false.
	DWordType	Represents a double word (32-bit unsigned integer) value.
	xs:hexBinary	Represents binary data encoded as hexadecimal.
	xs:string	Represents a sequence of characters.

<Value>

</Value>

</Setting>

<Value>

<String>DefaultMicrosoftEnforced</String>

</Value>

</Setting>

<Value>

</Value>

EKUs

The <EKUs> sub-element is used to define the Extended Key Usage (EKU) attributes for certificates. EKUs specify the purposes for which the certificate's public key can be used, such as code signing, server authentication, and client authentication. By specifying EKUs, organizations can ensure that certificates are only used for their intended purposes, enhancing security and trust in digital communications.

EKUs
\|----	EKU
	\|----	Attributes
		\|------	ID *1
		\|------	Value *1
		\|------	FriendlyName

	*1 = Required

EKUs Elements and Attributes

Element Names	Attribute Names	Description
EKUs		Collection of EKU(s)
EKU	ID	A unique identifier for the Extended Key Usage. Required
	Value	Specifies the value of the EKU in hexBinary form. Required
	FriendlyName	An optional user-friendly name for the EKU.

<EKUs>

</EKUs>

UpdatePolicySigners

The <UpdatePolicySigners> sub-element is used to define the code signing certificates that are trusted for updating policy files. This ensures that only authorized entities can make changes to the policy, enhancing the security and integrity of the system. By specifying trusted signers, organizations can prevent unauthorized modifications and maintain control over policy updates.

updatepolicysigners
\|---------	updatepolicysigner
	\|---------	Attribute
		\|-----	SignerId

UpdatePolicySigner Elements and Attributes

Element Names	Attribute Names	Description
UpdatePolicySigners		Collection of UpdatePolicySigner(s)
UpdatePolicySigner	SignerId	A unique identifier for the signer. This attribute ensures that each signer authorized to update the ACfB policy can be distinctly recognized and referenced, allowing for precise control over which signers are trusted to make policy updates.

<SignerId>Example SignerId</SignerId>

</UpdatePolicySigner>

</UpdatePolicySigners>

HvciOptions

The <HvciOptions> sub-element is used to define the Hypervisor-protected Code Integrity (HVCI) settings. Hypervisor-Protected Code Integrity (HVCI) leverages virtualization-based security (VBS) to ensure that only trusted code runs in kernel mode, providing an additional layer of protection against malware and other threats. HVCI uses the Windows hypervisor to create an isolated virtual environment that becomes the root of trust for the operating system. This isolated environment ensures that kernel mode code integrity checks are performed within a secure context, preventing unauthorized code from executing. This helps in preventing unauthorized code from executing, thereby maintaining the integrity and security of the operating environment.

HVCIOptions

Element Name	Description
HVCIOptions	A friendly name for the HVCI option.

The <HvciOptions> element expects a numeric value that represents the specific configuration settings. Here’s a detailed explanation:

Possible Values for HvciOptions

Enabled (Value: 1): Turns on HVCI, ensuring that only trusted code can run at the hypervisor level.
Strict (Value: 2): Enforces stricter code integrity checks, providing an additional layer of security.
DebugMode (Value: 4): Enables debugging features for HVCI, useful for development and troubleshooting.
DisableAllowed (Value: 8): Allows HVCI to be disabled by the user outside of the Code Integrity policy enablement method.

These values can be combined using bitwise OR operations to enable multiple settings simultaneously.

Macros

A collection of macro definitions that can be used throughout the policy. Macros allow for text substitution, making it easier to manage and update policy configurations by using predefined values. Each macro is defined within a Macro element, which includes an ID and a value. By using macros, administrators can simplify the policy management process and ensure consistency across different policy elements.

Macros
\|-----	Macro
\|	\|-----	Attributes
\|	\|	\|-----	Id *1
\|	\|	\|-----	Value *1
\|	\|
\|	\|-----	Annotations
\|		\|-------	Documentation
\|			\|---------	(A Macro element defines a text substitution macro that can be used in other elements. Macros are referenced using NMAKE syntax, i.e. $(runtime.windows).)
\|			\|---------	(Required. The Id for this macro, used in macro references. For example, if the Id for this macro is "runtime.windows", the macro would be referenced as $(runtime.windows).)
\|			\|---------	(Required. The value that will be substituted for macro references in macro-enabled XML attributes.)
\|
\|-----	UniqueMacroId
	\|----------------	Selector (xpath="ps:Macro")
	\|----------------	Field (xpath="@Id")

	*1 = Required

Macros Elements and Constraints

Element Names	Attribute Names	Description
Macro
	Id	Used in macro references, allowing the macro to be called by its ID in other elements, ensuring consistency and ease of management. Required
	Value	Specifies the text to be substituted for macro references. This ensures that the defined value is consistently used wherever the macro is referenced, simplifying updates and maintenance. Required
“Macros” Constraints UniqueMacroId		Specifies the unique constraint's name, which in this case is UniqueMacroId. It ensures that each macro ID within the Macros element is unique, preventing duplication.
	Selector	Defines the XPath expression used to select the elements to which the unique constraint applies. In this case, it selects the Macro elements within the Macros element.
	Field	Specifies the field within the selected elements that must be unique. Here, it ensures that the Id attribute of each Macro element is unique within the Macros element.

SupplementalPolicySigners

The <SupplementalPolicySigners> element defines a collection of signers that are trusted to sign supplemental policies. Supplemental policies are additional policies that extend or modify the base policy, allowing for more granular and flexible control over application execution. The <SupplementalPolicySigners> element ensures that only authorized entities can create or update these supplemental policies, maintaining the integrity and security of the overall policy framework

SupplementalPolicySigners
\|----------------	SupplementalPolicySigner
	\|----------------	Attributes
		\|-------	SignerId *1

	*1 = Required

SupplementalPolicySigners Elements and Attributes

Element Names	Attribute Names	Description
SupplementalPolicySigner		Collection of Collection of SupplementalPolicySigner(s)
	SignerId	A unique identifier for the signer. Ensures that each signer authorized to sign supplemental policies can be distinctly recognized and referenced, allowing for precise control over which signers are trusted to create or update supplemental policies Required

Element Names

Attribute Names

Description

SupplementalPolicySigner

Collection of Collection of SupplementalPolicySigner(s)

SignerId

A unique identifier for the signer. Ensures that each signer authorized to sign supplemental policies can be distinctly recognized and referenced, allowing for precise control over which signers are trusted to create or update supplemental policies

Required

Schema Definition (CiPolicy.xsd - 1/27/2025) and location

The current schema definition can be found on a Windows 11 device at:

C:\Windows\schemas\CodeIntegrity\cipolicy.xsd

ACfB Example Policy locations

On Windows 11, ACfB example policies are saved in the following locations:

DefaultWindows_*.xml:

%OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_*.xml
%ProgramFiles%\WindowsApps\Microsoft.AppControl.WDACWizard*\DefaultWindows_Audit.xml

AllowMicrosoft.xml:

%OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowMicrosoft.xml
%ProgramFiles%\WindowsApps\Microsoft.AppControl.WDACWizard*\AllowMicrosoft.xml

AllowAll.xml:

%OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml

AllowAll_EnableHVCI.xml:

%OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowAll_EnableHVCI.xml

DenyAllAudit.xml:

%OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\DenyAllAudit.xml

SmartAppControl.xml:

%OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\SmartAppControl.xml

These example policies can be used as a starting point to create custom policies for your organization's needs.

By implementing a well-structured and ordered schema, organizations can create a secure and efficient environment, much like how Raven's schema keeps her safe and happy in our backyard.

Updated Mar 18, 2025

Version 1.0

PaulBergson

paulberg

Microsoft

Joined October 30, 2017

View Profile

Core Infrastructure and Security Blog

Follow this blog board to get notified when there's new activity

Blog Post

Application Control for Business, Schema Definition