Edge Secured-core requires a version of Windows IoT that has at least five years of support from Microsoft remaining in its support lifecycle, at time of certification such as:
Hardware must support and have the following enabled:
Intel or AMD virtualization extensions
Trusted Platform Module (TPM) 2.0
For Intel systems: Intel Virtualization Technology for Directed I/O (VT-d), Intel Trusted Execution Technology (TXT), and SINIT ACM driver package must be included in the Windows system image (for DRTM)
For AMD systems: AMD IOMMU and AMD-V virtualization, and SKINIT package must be integrated in the Windows system image (for DRTM)
Kernel Direct Memory Access Protection (also known as Memory Access Protection)
Name
SecuredCore.Hardware.Identity
Status
Required
Description
The device identity must be rooted in hardware.
Purpose
Protects against cloning and masquerading of the device root identity, which is key in underpinning trust in upper software layers extended through a chain-of-trust. Provide an attestable, immutable and cryptographically secure identity.
Dependencies
Trusted Platform Module (TPM) v2.0 device
Name
SecuredCore.Hardware.MemoryProtection
Status
Required
Description
All Direct Memory Access (DMA) enabled externally accessible ports must sit behind an enabled and appropriately configured Input-output Memory Management Unit (IOMMU) or System Memory Management Unit (SMMU).
Purpose
Protects against drive-by and other attacks that seek to use other DMA controllers to bypass CPU memory integrity protections.
Dependencies
Enabled and appropriately configured input/output Memory Management Unit (IOMMU) or System Memory Management Unit (SMMU)
Name
SecuredCore.Firmware.Protection
Status
Required
Description
The device boot sequence must support Dynamic Root of Trust for Measurement (DRTM) alongside UEFI Management Mode mitigations.
Purpose
Protects against firmware weaknesses, untrusted code, and rootkits that seek to exploit early and privileged boot stages to bypass OS protections.
Ensures that the firmware and OS kernel, executed as part of the boot sequence, have first been signed by a trusted authority and retain integrity.
Dependencies
UEFI
Name
SecuredCore.Firmware.Attestation
Status
Required
Description
The device identity, along with its platform boot logs and measurements, must be remotely attestable to the Microsoft Azure Attestation (MAA) service.
Purpose
Enables services to establish the trustworthiness of the device. Allows for reliable security posture monitoring and other trust scenarios such as the release of access credentials.
Vulnerabilities that are high/critical (using Common Vulnerability Scoring System 3.0) must be addressed within 180 days of the fix being available.
Purpose
Ensures that high-impact vulnerabilities are addressed in a timely manner, reducing likelihood and impact of a successful exploit.
Linux OS Support
Note
Linux is not yet supported. The below represent expected requirements. Please fill out this form if you are interested in certifying a Linux device.
Linux Hardware/Firmware Requirements
Name
SecuredCore.Hardware.Identity
Status
Required
Description
The device identity must be rooted in hardware.
Purpose
Protects against cloning and masquerading of the device root identity, which is key in underpinning trust in upper software layers extended through a chain-of-trust. Provide an attestable, immutable and cryptographically secure identity.
Dependencies
Trusted Platform Module (TPM) v2.0 or *other supported method
Name
SecuredCore.Hardware.MemoryProtection
Status
Required
Description
All DMA-enabled externally accessible ports must sit behind an enabled and appropriately configured Input-output Memory Management Unit (IOMMU) or System Memory Management Unit (SMMU).
Purpose
Protects against drive-by and other attacks that seek to use other DMA controllers to bypass CPU memory integrity protections.
Dependencies
Enabled and appropriately configured Input-output Memory Management Unit (IOMMU) or System Memory Management Unit (SMMU)
Name
SecuredCore.Firmware.Protection
Status
Required
Description
The device boot sequence must support either:
Approved firmware with SRTM support + runtime firmware hardening
Firmware scanning and evaluation by approved Microsoft third party
Purpose
Protects against firmware weaknesses, untrusted code, and rootkits that seek to exploit early and privileged boot stages to bypass OS protections.
Ensures that the firmware and OS kernel, executed as part of the boot sequence, have first been signed by a trusted authority and retain integrity.
Name
SecuredCore.Firmware.Attestation
Status
Required
Description
The device identity, along with its platform boot logs and measurements, must be remotely attestable to the Microsoft Azure Attestation (MAA) service.
Purpose
Enables services to establish the trustworthiness of the device. Allows for reliable security posture monitoring and other trust scenarios such as the release of access credentials.
Dependencies
Trusted Platform Module (TPM) 2.0 or *supported OP-TEE based application chained to a HWRoT (Secure Element or Secure Enclave)
The device must feature a secure enclave capable of performing security functions.
Purpose
Ensures that sensitive cryptographic operations (those key to device identity and chain-of-trust) are isolated and protected from the primary OS and some forms of side-channel attack.
Linux Configuration Requirements
Name
SecuredCore.Encryption.Storage
Status
Required
Description
Sensitive and private data must be encrypted at rest using dm-crypt or similar, supporting XTS-AES as the default algorithm with a key length of 128 bits or higher, with encryption keys backed by hardware protection.
Purpose
Protects against exfiltration of sensitive or private data by unauthorized actors or tampered software.
Name
SecuredCore.Encryption.TLS
Status
Required
Description
The OS must support a minimum Transport Layer Security (TLS) version of 1.2 and have the following TLS cipher suites available and enabled:
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Purpose
Ensure that applications are able to use end-to-end encryption protocols and ciphers without known weaknesses, that are supported by Azure Services.
Name
SecuredCore.Protection.CodeIntegrity
Status
Required
Description
The OS must have dm-verity and IMA code integrity features enabled, with code operating under least privilege.
Purpose
Protects against modified/malicious code, ensuring that only code with verifiable integrity is able to run.
Name
SecuredCore.Protection.NetworkServices
Status
Required
Description
Services listening for input from the network must not run with elevated privileges, such as SYSTEM or root. Exceptions may apply for security-related services.
Purpose
Limits the exploitability of compromised networked services.
Linux Software/Service Requirements
Name
SecuredCore.Built-in.Security
Status
Required
Description
Devices must be able to send security logs and alerts to a cloud-native security monitoring solution, such as Microsoft Defender for Endpoint.
Purpose
Enables fleet posture monitoring, diagnosis of security threats, and protects against latent and in-progress attacks.
The device must support auditing and setting of system configuration (and certain management actions such as reboot) through Azure. Note: Use of other system management toolchains (e.g. Ansible) by operators aren't prohibited, but the device must include the azure-osconfig agent for Azure management.
Purpose
Enables the application of security baselines as part of a secure-by-default configuration posture, reducing the risk of compromise through incorrectly configured security-sensitive settings.
Dependency
azure-osconfig
Name
SecuredCore.Update
Status
Audit
Description
The device must be able to receive and update its firmware and software through Azure Device Update or other approved services.
Purpose
Enables continuous security and renewable trust.
Name
SecuredCore.UpdateResiliency
Status
Required
Description
The device must be restorable to the last known good state if an update causes issues.
Purpose
Ensures that devices can be restored to a functional, secure, and updatable state.
Name
SecuredCore.Protection.Baselines
Status
Required
Description
The system is able to successfully apply a baseline security configuration.
Purpose
Ensures a secure-by-default configuration posture, reducing the risk of compromise through incorrectly configured security-sensitive settings.
Updates to the operating system, drivers, application software, libraries, packages, and firmware must be signed.
Purpose
Prevents unauthorized or malicious code from being installed during the update process.
Linux Policy Requirements
Name
SecuredCore.Policy.Protection.Debug
Status
Required
Description
Debug functionality on the device must be disabled or require authorization to enable.
Purpose
Ensures that software and hardware protections cannot be bypassed through debugger intervention and back-channels.
Name
SecuredCore.Policy.Manageability.Reset
Status
Required
Description
It must be possible to reset the device (remove user data, remove user configs).
Purpose
Protects against exfiltration of sensitive or private data during device ownership or lifecycle transitions.
Name
SecuredCore.Policy.Updates.Duration
Status
Required
Description
Software updates must be provided for at least 60 months from date of submission.
Purpose
Ensures a minimum period of continuous security.
Name
SecuredCore.Policy.Vuln.Disclosure
Status
Required
Description
A mechanism for collecting and distributing reports of vulnerabilities in the product must be available.
Purpose
Provides a clear path for discovered vulnerabilities to be reported, assessed, and disclosed, enabling effective risk management and timely fixes.
Name
SecuredCore.Policy.Vuln.Fixes
Status
Required
Description
Vulnerabilities that are high/critical (using Common Vulnerability Scoring System 3.0) must be addressed within 180 days of the fix being available.
Purpose
Ensures that high-impact vulnerabilities are addressed in a timely manner, reducing likelihood and impact of a successful exploit.
Azure Sphere Platform Support
The Mediatek MT3620AN must be included in your design. More guidance for building secured Azure Sphere applications can be found within the Azure Sphere application notes.
Azure Sphere Hardware/Firmware Requirements
Name
SecuredCore.Hardware.Identity
Status
Required
Description
The device identity must be rooted in hardware.
Purpose
Protects against cloning and masquerading of the device root identity, which is key in underpinning trust in upper software layers extended through a chain-of-trust. Provide an attestable, immutable and cryptographically secure identity.
Dependencies
Azure Sphere meets this requirement as MT3620 includes the integrated Pluton security processor.
Name
SecuredCore.Hardware.MemoryProtection
Status
Required
Description
All DMA-enabled externally accessible ports must sit behind an enabled and appropriately configured Input-output Memory Management Unit (IOMMU) or System Memory Management Unit (SMMU).
Purpose
Protects against drive-by and other attacks that seek to use other DMA controllers to bypass CPU memory integrity protections.
Dependencies
Azure Sphere meets this requirement through a securely configurable peripheral firewall.
Name
SecuredCore.Firmware.Protection
Status
Required
Description
The device boot sequence must protect against firmware security threats.
Purpose
Protects against firmware weaknesses, persistent untrusted code, and rootkits that seek to exploit early and privileged boot stages to bypass OS protections.
Dependencies
Azure Sphere meets this requirement through a Microsoft-managed, hardened, and authenticated boot chain.
Name
SecuredCore.Firmware.SecureBoot
Status
Required
Description
The device boot sequence must be authenticated.
Purpose
Ensures that the firmware and OS kernel, executed as part of the boot sequence, have first been signed by a trusted authority and retain integrity.
Dependencies
Azure Sphere meets this requirement through a Microsoft-managed authenticated boot chain.
Name
SecuredCore.Firmware.Attestation
Status
Required
Description
The device identity, along with its platform boot logs and measurements, must be remotely attestable to a Microsoft Azure Attestation (MAA) service.
Purpose
Enables services to establish the trustworthiness of the device. Allows for reliable security posture monitoring and other trust scenarios such as the release of access credentials.
Dependencies
Azure Sphere meets this requirement through the Device Authentication and Attestation (DAA) service provided as part of the Azure Sphere Security Service (AS3).
Name
SecuredCore.Hardware.SecureEnclave
Status
Required
Description
The device must feature a secure enclave capable of performing security functions.
Purpose
Ensures that sensitive cryptographic operations (those key to device identity and chain-of-trust) are isolated and protected from the primary OS and some forms of side-channel attack.
Dependencies
Azure Sphere meets this requirement as MT3260 includes the Pluton security processor.
Azure Sphere OS Configuration Requirements
Name
SecuredCore.Encryption.Storage
Status
Required
Description
Sensitive and private data must be encrypted at rest, with encryption keys backed by hardware protection.
Purpose
Protects against exfiltration of sensitive or private data by unauthorized actors or tampered software.
Dependencies
Azure Sphere enables this requirement to be met using the Pluton security processor, in-package non-volatile memory, and customer-exposed wolfCrypt APIs.
Name
SecuredCore.Encryption.TLS
Status
Required
Description
The OS must support a minimum Transport Layer Security (TLS) version of 1.2 and have secure TLS cipher suites available.
Purpose
Ensures that applications are able to use end-to-end encryption protocols and ciphers without known weaknesses, that are supported by Azure Services.
Dependencies
Azure Sphere meets this requirement through a Microsoft-managed wolfSSL library using only secure TLS cipher suites, backed by Device Authentication and Attestation (DAA) certificates.
Name
SecuredCore.Protection.CodeIntegrity
Status
Required
Description
The OS must feature code integrity support, with code operating under least privilege.
Purpose
Protects against modified/malicious code, ensuring that only code with verifiable integrity is able to run.
Dependencies
Azure Sphere meets this requirement through the Microsoft-managed and hardened OS with read-only filesystem stored on in-package non-volatile memory storage and executed in on-die RAM, with restricted/contained and least-privileged workloads.
Name
SecuredCore.Protection.NetworkServices
Status
Required
Description
Services listening for input from the network must not run with elevated privileges, such as SYSTEM or root. Exceptions may apply for security-related services.
Purpose
Limits the exploitability of compromised networked services.
Dependencies
Azure Sphere meets this requirement through restricted/contained and least-privileged workloads.
Name
SecuredCore.Protection.NetworkFirewall
Status
Required
Description
Applications can't connect to endpoints that haven't been authorized.
Purpose
Limits the exploitability of compromised or malicious applications for upstream network traffic and remote access/control.
Dependencies
Azure Sphere meets this requirement through a securely configurable network firewall and Device Authentication and Attestation (DAA) certificates.
Azure Sphere Software/Service Requirements
Name
SecuredCore.Built-in.Security
Status
Required
Description
Devices must be able to send security logs and alerts to a cloud-native security monitoring solution.
Purpose
Enables fleet posture monitoring, diagnosis of security threats, and protects against latent and in-progress attacks.
Dependencies
Azure Sphere meets this requirement through integration of Azure Sphere Security Service (AS3) telemetry with Azure Monitor and the ability for applications to send security logs and alerts via Azure services.
The device must support auditing and setting of system configuration (and certain management actions) through Azure.
Purpose
Enables the application of security baselines as part of a secure-by-default configuration posture, reducing the risk of compromise through incorrectly configured security-sensitive settings.
Dependencies
Azure Sphere meets this requirement through secure customer application configuration manifests, underpinned by a Microsoft-managed, and hardened OS.
Name
SecuredCore.Update
Status
Required
Description
The device must be able to receive and update its firmware and software.
Purpose
Enables continuous security and renewable trust.
Dependencies
Azure Sphere meets this requirement through a Microsoft-managed and automatically updated OS, with customer application updates delivered remotely via the Azure Sphere Security Service (AS3).
Name
SecuredCore.Protection.Baselines
Status
Required
Description
The system is able to successfully apply a baseline security configuration.
Purpose
Ensures a secure-by-default configuration posture, reducing the risk of compromise through incorrectly configured security-sensitive settings.
Dependencies
Azure Sphere meets this requirement through a Microsoft-managed and hardened OS.
Name
SecuredCore.Protection.Update Resiliency
Status
Required
Description
The device must be restorable to the last known good state if an update causes issues.
Purpose
Ensures that devices can be restored to a functional, secure, and updatable state.
Dependencies
Azure Sphere meets this requirement through a built-in rollback mechanism for updates.
Name
SecuredCore.Protection.SignedUpdates
Status
Required
Description
Updates to the operating system, drivers, application software, libraries, packages, and firmware must be signed.
Purpose
Prevents unauthorized or malicious code from being installed during the update process.
Dependencies
Azure Sphere meets this requirement.
Azure Sphere Policy Requirements
Name
SecuredCore.Policy.Protection.Debug
Status
Required
Description
Debug functionality on the device must be disabled or require authorization to enable.
Purpose
Ensures that the software and hardware protections cannot be bypassed through debugger intervention and back-channels.
Dependencies
Azure Sphere OS meets this requirement as debug functionality requires a signed capability that is only provided to the device OEM owner.
Name
SecuredCore.Policy.Manageability.Reset
Status
Required
Description
It must be possible to reset the device (remove user data, remove user configs).
Purpose
Protects against exfiltration of sensitive or private data during device ownership or lifecycle transitions.
Dependencies
The Azure Sphere OS enables OEM applications to implement reset functionality.
Name
SecuredCore.Policy.Updates.Duration
Status
Required
Description
Software updates must be provided for at least 60 months from date of submission.
Purpose
Ensures a minimum period of continuous security.
Dependencies
The Azure Sphere OS meets this requirement as Microsoft provides OS security updates, and the AS3 service enables OEMs to provide application software updates.
Name
SecuredCore.Policy.Vuln.Disclosure
Status
Required
Description
A mechanism for collecting and distributing reports of vulnerabilities in the product must be available.
Purpose
Provides a clear path for discovered vulnerabilities to be reported, assessed, and disclosed, enabling effective risk management and timely fixes.
Dependencies
Azure Sphere OS vulnerabilities can be reported to Microsoft Security Response Center (MSRC) and are published to customers through the Azure Sphere “What’s New” page, and through Mitre’s CVE database.
Vulnerabilities that are high/critical (using Common Vulnerability Scoring System 3.0) must be addressed within 180 days of the fix being available.
Purpose
Ensures that high-impact vulnerabilities are addressed in a timely manner, reducing likelihood and impact of a successful exploit.
Dependencies
Azure Sphere OS meets this requirement as Microsoft provides OS security updates meeting the above requirement. The AS3 service enables OEMs to provide application software updates meeting this requirement.
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.