Authentication

Authentication is where identity proves itself, whether through a sign-in, a credential issued earlier, or a chain of trust enforced at every request. People, contractors, service accounts, workloads, agents, and customers all pass through this point, and the operating model has to govern them all.

The identity leaders I talk with describe the same reality. Passkeys are being rolled out. MFA and SSO still are not, or cannot be, fully extended to legacy systems. Authentication has to be coordinated across dozens or thousands of systems while passkeys, conditional access, and session security keep advancing. Firefighting and building strategy happen at the same time, across every system. Building the plane while flying it.

Implementing authentication as a function of the operating model means deciding how each identity type authenticates and writing those decisions down as authentication standards. It means identity proofing happens before the credential is issued and again when it is recovered, not only at sign-in. It means assigning ownership for authentication configuration, conditional access, and session governance to named people, not leaving them in a tool no one is accountable for. It means encryption protects credentials and tokens end to end, and session monitoring continues after sign-in completes. It means phishing-resistant methods become the default for employees, contractors, and privileged identities alike, with exceptions documented, time-bound, and reviewed.

Implementation is also about sequence. Legacy systems that cannot accept modern authentication need a stated plan, even if that plan is compensating controls until retirement. New applications, agents, and workloads need authentication standards and credential governance before they go live.

Start by getting clear on:

• Which legacy applications still sit outside governed authentication
• Whether factor requirements match each identity type in the model
• Whether phishing-resistant methods are the default across identity types
• Whether sessions and tokens are governed after authentication
• Where exceptions have become normal

Measure:

• Application coverage behind SSO
• Identities enrolled in phishing-resistant methods (FIDO2, passkeys, certificates)
• Encryption coverage for credentials, tokens, and session data
• Authentication exceptions by type
• Token and session anomalies after authentication

Authentication proves you. Governance decides if your name is on the list.

❓ Where is your authentication strongest: at the sign-in moment, before it, or after it?