The Next Identity Skills Gap Is Hiding Behind the Login Screen

Most people understand authentication as a familiar sequence. Enter credentials, prove who you are and access the application.

Modern systems keep working long after that login screen disappears.

Applications use identity and access tokens to determine what users and workloads are allowed to do. Tokens support capabilities such as single sign-on, federation and API access. NIST describes them as a central part of access management infrastructure and zero trust architectures.

On 15 September, NIST finalized IR 8587 with CISA involvement, providing implementation guidance for protecting tokens and assertions from forgery, theft and misuse. The publication covers identity providers, authorization servers, cryptographic key protection, token verification and lifecycle controls.

For cybersecurity teams, there’s a workforce implication hiding inside that architecture.

Identity Security Has Become an Engineering Skill

IAM can sound administrative: create accounts, assign permissions, remove access when someone leaves.

Those responsibilities remain. Cloud applications, APIs and machine identities have added another technical layer.

Security professionals increasingly need to understand:

• How tokens are issued, validated, renewed and revoked
• How SSO and federation move trust between systems
• Which cryptographic keys protect tokens and how those keys are managed
• How API permissions are scoped
• How workload identities differ from human identities
• What telemetry can reveal token misuse
• How identity controls behave when applications span multiple cloud services

NIST’s finalized guidance specifically adds workload identity considerations and recommends short-lived tokens rather than relying on static credentials and secrets.

That makes identity security relevant to cloud engineers, application security teams, security architects and SOC analysts alongside dedicated IAM specialists.

Stolen Credentials Aren’t the Whole Story

Training also needs to reflect how identity attacks can work after authentication.

An analyst investigating suspicious cloud activity may find that the account’s password was never used by the attacker. A stolen or forged token can potentially provide access without repeating the original authentication process.

That changes the investigation.

Teams need to examine token issuance, permissions, signing infrastructure, session activity and revocation. Application developers need to understand how their systems validate tokens. Architects need to design trust relationships carefully. SOC teams need telemetry that helps them identify unusual use.

Even logout deserves more thought than its humble button suggests. NIST’s Digital Identity Guidelines note that access and refresh tokens can remain valid beyond the original authentication session.

Put Identity Into the Lab

Identity security is well suited to practical training because the relationships become clearer when people can see them working.

Give learners several applications, an identity provider and an API. Let them trace authentication, inspect permissions and observe how tokens move between components. Then introduce a misconfiguration or compromised token and ask them to investigate what access becomes possible.

The exercise connects cloud security, application security and incident response around one identity chain.

That approach fits ITSEC Cyber & AI Academy, where hands-on environments can help learners understand how security controls behave across realistic systems rather than treating IAM as a diagram to memorise.

Passwords still matter.

The identity system around them has become a considerably bigger subject.

Explore practical cybersecurity and AI training at ITSEC Cyber & AI Academy.

References: NIST: Protecting Online Identity and Access Tokens From Misuse, 15 September 2026 · NIST IR 8587: Protecting Tokens and Assertions · NIST Digital Identity Guidelines · ENISA NIS Investments 2025