Security

ClearPass Onboard i is user centric, I think you are only able to issue user certificate with the built in Onboard enrollment.

Possibly you can enable SCEP in ClearPass and enroll the certificates this way for the computer account. Another possible way could be to use the CA function in Central NAC to enroll for machine certificates.

One important thing to remember is that you also need to reconfigure your 802.1x profiles on the computers, and change to "User or computer authentication" otherwise Windows will not change the authentication to the machine certificate when there are no user logged on.

Not to take away with anything that others have responded on. But machine auth on windows will work when user is logged off, while user auth will take place when user logs in. I am assuming you are using intune to push profiles as you talk about entra. The intune profiles have an option for machine vs user and the microsoft documentation does a pretty good job and defining what attributes you can use. Onboard is just a certificate authority and in some ways its not much different at signing certs then what you can do with an AD CA. 

Onboard certs can be used for user certs or machine certs the same as AD CA can. It really depends how the cert is generated in order to accomplish this. We are migrating from Microsoft Cloud PKI to Onboard with SCEP. There are no issues with generating machine certs. You do loose some some certificate attributes when you use SCEP vs the default onboarding process with clearpass. You can still use the UPN property in cert generation and it will show up as the username in clearpass. It does come down to the decision on what info you want to be in the cert and if this could be a security concern. In our case we often reference the hostname or service tag, and its acceptable to create a cert with this value in it. The ops team can serach by the service tag and revoke if needed. 

The only real caveat I found is that intune does not allow a UPN or email to be tied to a machine cert. Due to this the machine cert will use a license and the user cert will use a 2nd license. An onboard license is based on the username vs the number of certificates used. If you use the same username for mobile and computer you can technically get away with a single license count. You can use the UPN field in cert to return the machine name, and this will show in onboard when a cert is generated via SCEP. There are also other cloud PKI's that you can use outside microsoft if you choose. 

We are using machine auth on our computers and if they are single use computers they do have a user account tied to that resource in Intune / entra. At that point the intune extension will have info populated in endpoints about the user email address of that resource. If you wish to return the username of endpoint attribute, it will show a username for wifi client in dashboards vs the hostname or azure device id. 

Fair correction, and useful to hear from someone running it. I'd framed MDM as the natural path because it's where most Entra shops already live, but you're right that Onboard with SCEP does machine certs perfectly well, and going that direction rather than the other way is a real data point.

Your licensing note is the part worth pulling out for anyone reading this later. If Intune can't attach a UPN or email to a machine cert, and Onboard counts licenses by username rather than by certificate, then the MDM route quietly costs a second license per device while the Onboard route can land both certs under one. That's a genuine argument for Onboard that has nothing to do with the certificates themselves.

So to the original question, either path gets you machine certs. Pick based on where you want the CA to live and how the licensing math lands, and either way don't forget the user or computer authentication change on the supplicant, which is the bit that actually keeps the device online at sign-out.

Not to take away with anything that others have responded on. But machine auth on windows will work when user is logged off, while user auth will take place when user logs in. I am assuming you are using intune to push profiles as you talk about entra. The intune profiles have an option for machine vs user and the microsoft documentation does a pretty good job and defining what attributes you can use. Onboard is just a certificate authority and in some ways its not much different at signing certs then what you can do with an AD CA. 

Onboard certs can be used for user certs or machine certs the same as AD CA can. It really depends how the cert is generated in order to accomplish this. We are migrating from Microsoft Cloud PKI to Onboard with SCEP. There are no issues with generating machine certs. You do loose some some certificate attributes when you use SCEP vs the default onboarding process with clearpass. You can still use the UPN property in cert generation and it will show up as the username in clearpass. It does come down to the decision on what info you want to be in the cert and if this could be a security concern. In our case we often reference the hostname or service tag, and its acceptable to create a cert with this value in it. The ops team can serach by the service tag and revoke if needed. 

The only real caveat I found is that intune does not allow a UPN or email to be tied to a machine cert. Due to this the machine cert will use a license and the user cert will use a 2nd license. An onboard license is based on the username vs the number of certificates used. If you use the same username for mobile and computer you can technically get away with a single license count. You can use the UPN field in cert to return the machine name, and this will show in onboard when a cert is generated via SCEP. There are also other cloud PKI's that you can use outside microsoft if you choose. 

We are using machine auth on our computers and if they are single use computers they do have a user account tied to that resource in Intune / entra. At that point the intune extension will have info populated in endpoints about the user email address of that resource. If you wish to return the username of endpoint attribute, it will show a username for wifi client in dashboards vs the hostname or azure device id.