What is Secured-core PC and when does it make sense for a company?
Secured-core PC is a Windows device standard combining TPM 2.0, Secure Boot, firmware protection, memory isolation and controls that limit vulnerable drivers. It matters most where a laptop provides access to email, VPN, Microsoft 365, customer data or regulated systems. Hardware alone is not enough: management policies, updates, MFA, BitLocker, EDR, an exception owner and periodic reporting for IT or audit are also required. Check Secured-core status and requirements in Microsoft and OEM documentation for the specific model, firmware and Windows version; TPM alone does not establish that all requirements are met.
Configuration items that need to be checked
A device carrying the Secured-core PC label becomes a security control only when the required functions are enabled, centrally managed and visible in a compliance report.
- TPM 2.0, Secure Boot and current firmware aligned with the vendor policy
- VBS/HVCI, credential protection and vulnerable-driver blocking
- BitLocker with secure key escrow and a tested recovery process
- Defender or EDR with active telemetry and an alert-response procedure
- Intune, UEM or GPO with a baseline profile, application control and updates
- MFA, conditional access and separation of administrative and standard accounts
The most common Windows hardening mistakes
Most gaps appear when hardening is treated as a one-off task instead of a maintained fleet standard.
- buying devices with a Secured-core label without checking enabled functions
- no central report for BitLocker, firmware, updates and compliance
- local administrator accounts left without review or an accountable owner
- exceptions without justification, expiry date or a risk-acceptance decision
- no recovery-key test or procedure for a lost device
How to deploy a hardened Windows configuration
The strongest model is a corporate device standard: a baseline, exception groups, a pilot, compliance testing and regular review. It should connect to purchasing, onboarding, offboarding and privileged-account reviews because an endpoint is only one part of the path to business data. A phased plan reduces risk without stopping work and gives management a measurable view of progress. Without a common standard, every laptop remains a separate case. The 30- and 60-day checkpoints below are illustrative; address urgent gaps immediately rather than deferring protection until a phase ends.
- define device and user classes together with the minimum security profile
- inventory hardware capabilities, operating systems, licences and current tools
- deploy settings to a pilot group with a documented plan to restore the previous configuration
- record each exception, its owner, risk and next review date
- include compliance in the purchase, issue and return process for every device
- 30 days: inventory devices, TPM, Secure Boot, BitLocker, Windows versions, Defender and local exceptions.
- 60 days: deploy the Windows baseline, update policies, MFA, encryption, key recovery and conditional access.
- Ongoing: monitor non-compliant devices, firmware, drivers, EDR alerts and policy changes.
- Management evidence: compliant-device counts, risk exceptions and purchasing decisions required for fleet replacement.
Critical Secured-core PC settings
Protection works only when hardware, firmware, the operating system and administration are consistent. A missing layer creates a false sense of security.
- active TPM, Secure Boot and Virtualisation Based Security confirmed by measurement
- BitLocker with secure recovery-key storage, access control and rotation after use or according to policy.
- current firmware and drivers covered by a tested update cadence
- restricted local privileges and separate accounts for administrative work
- application control, Defender and EDR policies resistant to local disabling
How Secured-core fits into endpoint management
Windows hardening should extend beyond individual computers. Intune, GPO or UEM should show the expected state and deviations. Endpoint protection, updates, inventory and helpdesk should use consistent device identifiers.
- detect devices without encryption, current firmware or active EDR
- enforce compliance profiles and conditional access to Microsoft 365 and VPN
- connect technical alerts to a ticket, an owner and a response deadline
- handle new, returned and lost devices through one operating process
- report deviations by risk, business unit and duration
Rollout without productivity loss
A hardened configuration should not block users unnecessarily. The rollout should begin with pilots and distinguish the needs of management, finance, administrators, field staff, developers and shared workstations.
- prepare communications, a support channel and a rollback scenario for the pilot
- deploy policies in waves based on role, risk and application criticality
- analyse errors, exceptions and user impact after each wave
- approve the next wave only after recovery and helpdesk procedures are proven
Windows workstation compliance evidence
A company should be able to prove that required functions operate across the fleet, not only on a few new devices.
- a device report covering TPM, Secure Boot, BitLocker, Windows version and update status
- a security-profile exception list with justification and a review deadline
- Defender or EDR alerts with evidence that response-required events were handled
- onboarding and offboarding procedures with confirmation that access was revoked
How to measure hardening effectiveness
Metrics distinguish a declaration from an operating control and show where configuration, licensing or hardware replacement is required.
- proportion of devices with active encryption and securely escrowed recovery keys
- EDR coverage, Intune profile compliance and update timeliness
- number of local administrators and unmanaged endpoints
- devices with outdated firmware or disabled Secure Boot
- number, age and owners of approved exceptions
- time from detecting non-compliance to correction or formal risk acceptance
Deliverables after a Secured-core PC and Windows review
The result is not merely confirmation that a computer supports Secured-core. The company needs a standard and process that preserves configuration after hardware replacement, a user change or an operating-system update.
- a Windows baseline with required settings and compliance criteria
- a fleet report with gaps, exceptions and remediation priorities
- a device matrix for configuration, replacement or explicit risk acceptance
- a security remediation plan with owners, deadlines and licensing dependencies
- Evidence for management and customers may support an ISO 27001 audit and NIS2/national-law or DORA requirements where applicable. An endpoint review alone does not establish compliance or certification.
Acceptance criteria for a Secured-core PC configuration
Acceptance should confirm not only pilot settings but also the organisation's ability to maintain the standard.
- pilot devices are encrypted, report compliance and have active EDR
- recovery keys are securely stored and the recovery procedure has been tested
- exceptions have an owner, justification, deadline and accepted risk
- helpdesk and administrators know the failure, return and device-loss procedures
- the next review cycle, metrics and management-reporting method are agreed
When the topic requires a management decision
Windows hardening often requires decisions about purchasing, exceptions, implementation timing and risk acceptance. These rules should be agreed before an incident or a customer audit.
- replacement of devices without TPM 2.0 or support for a current operating system
- funding for Intune, EDR, UEM or a higher Microsoft 365 licence tier
- temporary use of legacy hardware and the required compensating controls
- rollout priority for privileged users and regulated data
Turning Secured-core PC into purchasing decisions
Secured-core PC should be part of the laptop standard for devices used away from the office, storing data locally or providing access to email, VPN, Microsoft 365 and critical applications.
- require TPM 2.0, Secure Boot, supported firmware and Intune compatibility
- assess full lifecycle cost instead of the device price alone
- verify compliance reporting, serviceability and driver-update support
- define a procedure for equipment that cannot be replaced immediately
How hardware and system protection works in practice
Protection begins before Windows starts: firmware, Secure Boot and TPM form a chain of trust, while VBS provides an isolated environment for security controls. These functions reach their full value only when connected to BitLocker, updates, Defender, EDR, MFA and compliance reporting.
- Secure Boot limits unauthorised code execution before the operating system
- TPM stores cryptographic material and supports boot-integrity measurement
- VBS provides an isolated environment; HVCI protects kernel code integrity, while Credential Guard uses VBS to protect credentials
- BitLocker, EDR and conditional access protect data and active user sessions
Decision areas for the Windows fleet
Secured-core PC should be an operating standard rather than a one-off purchase. Four areas help decide what to configure, what to replace and which exceptions to escalate.
- hardware: TPM 2.0, Secure Boot, firmware, Intune compatibility and purchasing policy
- system: BitLocker, VBS/HVCI, Defender, updates and vulnerable-driver blocking
- access: MFA, conditional access, administrator accounts and key recovery
- evidence: compliance report, exception list, decision owner and review date
Controls and services that complete the endpoint standard
Secured-core PC delivers the greatest value as part of a coherent model for device management, identity, detection and response.
Firmware and boot protection
TPM, Secure Boot, VBS and an update policy reduce tampering below the operating-system layer.
Identity and privileged access
MFA, separate administrative accounts and least privilege limit the impact of a compromised session.
Endpoint monitoring
EDR telemetry and response procedures show whether protection remains active after rollout.
Configuration review
A documented baseline, exceptions and remediation owners turn settings into auditable controls.
When a Windows review produces a quick result
Fleet replacement, an Intune migration, a customer audit or increased hybrid work are the best moments to connect the security standard with purchasing, onboarding and ongoing administration.
Microsoft 365 and Intune
Device policies, MFA, conditional access and compliance reporting become one process.
EDR on endpoints
Endpoint alerts are connected to the Windows baseline and a response procedure.
IT outsourcing
Ongoing administration preserves compliance after laptop purchases and user changes.
Contact
During the call, we establish the device count, management model, BitLocker, MFA and EDR status, and hardware exceptions. The company receives a scope and priorities for IT and purchasing.
- contact: +48 12 200 27 10 and identification of the project owner
- minimum data: device count, management model, Microsoft 365 licences and current EDR
- result: a security-risk reduction plan, decision owners, compliance evidence and rollout order
