Hi Prashant,
That pattern usually means the Windows Hello for Business sign-in path is no longer getting usable on-prem Kerberos credentials, so password sign-in works but PIN sign-in does not. In Windows Hello for Business, the PIN unlocks a key on the device; it is not the same as using the user’s password. On hybrid/on-prem setups, Windows Hello also depends on the correct on-prem authentication mode, such as cloud Kerberos trust or certificate trust.
Do this on one affected PC right after signing in with PIN:
Open Command Prompt and run klist. If you do not see a normal Kerberos TGT/service tickets, that confirms the Hello sign-in is not producing the ticket path your shares and ADUC need. Then run klist purge, sign out, sign back in, and test again. Microsoft’s Kerberos guidance also says to check Event Viewer for Kerberos-related errors on the client, target server, and domain controller.
Also check Event Viewer > Applications and Services Logs -> Microsoft -> Windows -> User Device Registration -> Admin and dsregcmd /status. Microsoft uses those logs and status checks to troubleshoot Windows Hello for Business and hybrid join/authentication issues.
The most likely root cause is one of these: a policy change affecting Windows Hello for Business, broken cloud Kerberos/certificate trust, or loss of line-of-sight to a domain controller. If this started suddenly last Friday, I would first review any GPO, Intune, DC certificate, or security update changes made around that time.
Can you paste the output of dsregcmd /status and the klist output?