Re: building it yourself just isn't an option.
"That's my understanding too - but I just tried to find a statement to that effect on Microsoft's web site. I failed... Got any current links?"
I actually do, because someone asked for actual links on this site before. I've highlighted the relevant parts.
You can find the MS hardware certification requirements on their website. Here is a link to the PDF of them: MS Hardware Certification Requirements
I'm just going to copy and paste this from the last time I was asked to back up my statement (though why people are so keen to tell others that PCs are locked down, I have no idea):
"If you skip down to the section on UEFISecureBoot (begins on page 118) it is covered in this section. As per usual, when you actually get into the detail it's more complicated, but the summary version that it is a requirement to be able to disable secure Boot on x86 is correct. Relevant passages below:
"17. Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following:
a. It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.
b. If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off.
c. The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults.On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enabled.
18. Mandatory. Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv. A Windows Server may also disable Secure Boot remotely using a strongly authenticated (preferably public-key based) out-of-band management connection, such as to a baseboard management controller or service processor. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible. Disabling Secure Boot must not be possible on ARM systems."