New cmdlet #28134

Or rather, what APIs (such as WMI) does Windows offer for the user to obtain firmware information instead of direct syscalls?

This already exists with Get-ComputerInfo on Windows where we can return BIOS information as part of that cmdlet, or there is the more direct Get-CimInstance Win32_BIOS option.

I don't believe the above has been ported to Linux/MacOS, due to using native windows API's & from reading this should be enough for this on linux

Get-Content /sys/class/dmi/id/bios_vendor
Get-Content /sys/class/dmi/id/bios_version
Get-Content /sys/class/dmi/id/product_name

Ah, of course, the famous Get-ComputerInfo. But it doesn't show certain things and is a bit "legacy".

What do you think of a command that shows if Secure Boot is enabled, the status of the ACPI tables (only a part of it, because it's quite dangerous for a regular user to know about this), the exact BIOS version, and whether it's UEFI or no, what do you think? A command dedicated to Firmwares....

What do you think of Get-FirmwareInfo or something similar?

What do you think of Get-FirmwareInfo or something similar?

Who is it for? Who is the audience? Who is going to use it, when and why?

The raison d'être of PowerShell was to manage servers, after twenty years most of these details have been worked out.

What do you think of a command that shows if Secure Boot is enabled

I would say it already exists, Confirm-SecureBootEUFI

If you think there is value, write it, put it on PSGallery and see how many downloads it gets.

However I would suggest don't waste your time. PowerShell has a backlog of tasks that are actually wanting time and effort if you want to contribute.

Go to the issues page, go to the Labels filter and choose "Up for grabs". These are work items that have been requested and approved by the project for people to work on.

Thanks for the feedback!
While it's true that Get-ComputerInfo exists on Windows, it behaves as a massive, legacy-heavy wrapper that dumps hundreds of OS-level properties (and handles things very differently across platforms). It doesn't provide a unified, fast, and cross-platform way to inspect low-level firmware state.
Get-FirmwareInfo solves a specific pain point for systems engineers, security auditors, and cross-platform developers who need a dedicated, lightweight cmdlet to inspect:
Secure Boot status cleanly across different OS environments.
UEFI presence and BIOS/SMBIOS details without having to write boilerplate CIM queries on Windows or raw file-parsing scripts (/sys/class/dmi/id/ and /sys/firmware/efi) on Linux.
Consistent OutputType (FirmwareInfo) that normalizes data structures regardless of whether you're running it on Windows, a Linux server, or macOS.

Get-FirmwareInfo solves a specific pain point for systems engineers, security auditors, and cross-platform developers

If you have found a need that is fine, the only person you have to convince is yourself. All you need to do is write your cmdlet and publish it in PSGallery.

I suggest you have a look at the other 22 firmwarepackages which are already there.

It doesn't provide a unified, fast, and cross-platform way to inspect low-level firmware state.

Yeah unfortunately, this is one of those, it's almost not possible to do things.
Mainly because device manufacturers and firmware creators (including hackers with hacked firmware) do not fully follow set guidance of how and what they must expose in a way that you could get programmatically.

My guidance to you comes as part of the Cmdlets Working Group, & that is if you want to try tackle this, please do go ahead, but you would need to do so outside of this repository, as from support and maintainability this isn't something that the PowerShell Team has the bandwidth to add at this time, perhaps ever, to the core product.

It would be a great thing to have, don't get me wrong, but this is an area where it seems like it should be simple but is very much fraught with dragons that'll likely burn you on the way.

I strongly advise that you try building this in your own repository, publish the resulting cmdlet as a module on the PowerShell Gallery & provide us with an update as to how you got on by creating a discussion in this repository or bringing to the community by one of the User Groups or conferences & publishing about it on the likes of Bluesky, Reddit and in the PowerShell groups on LinkedIn, Microsoft Tech Community and other such places.

Also the bar of acceptance into this repository is incredibly high, and from looking at your profile, I don't see any previous PowerShell related projects. Also your issue in raising this doesn't meet the quality needed for me to take this to the Cmdlets Working Group to discuss & this should have really been opened as a discussion, as opposed to an issue. Which is why I am converting this from an issue to a discussion.