Here’s the news of the day, X509 is not supported with Remote PowerShell to Office 365 Services.
Limitation
They say a picture can speak a thousand words. We don’t need a thousand, just one, X509.
What is X509?
Public key cryptography relies on a public and private key pair to encrypt and decrypt content. The X.509 public key infrastructure (PKI) standard identifies the requirements for robust public key certificates. A certificate is a signed data structure that binds a public key to a person, computer, or organization. In other words, X509 lets Cyber sleep better at night. Maybe. For more information on X509, Bing X509.
On the left, a user with PIV attempts to access PS with PIV. On the right, the same user attempts to access the Office 365 web portal with PIV. What do they have in common? AD FS, Modern AUTH, and, you guessed it PIV. As you can see, by default ADFS displays "Sign in using an X.509 certificate" when using user certificate authentication. However, certificate authentication is not supported with PowerShell in Azure AD.
Here is the word from the product group, (drum roll please)….. “I was thinking about the PowerShell idea, which is useful for people to run scheduled jobs. The gap is that the current CBA support from AAD revolved around mobile devices (https://docs.microsoft.com/en-us/azure/active-directory/active-directory-certificate-based-authentication-ios) I haven’t done the analysis to understand what it takes for AAD to support CBA for PowerShell. This is on our todo list. Yes you heard it, something magical is happening at Microsoft.
Workaround
And there you have it, a front row seat to the story of my life. 
For short, the only work around is, you guessed it, User object , synced via AD Connect, with interactive logon disabled. This account will leverage AD FS with WIA. For added security you can enable MFA for either Office 365 or Azure and it works!
Update coming soon!