Welcome back to my RACF TechNotes series.

In the previous post, I covered User Quarantine, a strategy on how to lock down compromised or high-risk user IDs to help protect your z/OS environment.

This time, the focus shifts to another core RACF capability: PassTickets. They are a practical way to reduce password exposure while still allowing secure authentication across applications.

What is a PassTicket?

A PassTicket is a one-time, short-lived authentication token that lets a user access an application without sending or storing a reusable password.

A few key characteristics:

• Works like a temporary password
• Generated on demand
• Valid for a short period-usually seconds or minutes
• Tied to a specific user and application

Why use PassTickets?

Passwords are still everywhere, but they are also one of the most common sources of exposure. This becomes a bigger issue when applications need to authenticate programmatically. For example, in batch jobs, scripts, or internal services, where storing passwords is risky.

PassTickets solve this by relying on a shared secret key instead of the user’s actual password. That means trusted applications can authenticate users without ever handling or storing real credentials.

You might also hear PassTickets referred to as Secured Signon which is an older term still seen in some places. They’re especially useful when one application needs to authenticate to another on a user’s behalf, such as:

• Session managers
• CICS, DB2, and WebSphere workloads
• Custom middleware

Introducing Enhanced PassTickets

Legacy PassTickets have been used in z/OS environments for a long time and have proven reliable, but they’re based on older cryptography that doesn’t really hold up to current security standards. To address that, IBM introduced Enhanced PassTickets. They behave the same from an application standpoint, so there’s no real change in how apps interact with them, but the underlying security is much stronger.

Enhanced PassTickets improve security by using stronger encryption methods than older approaches. They use a modern HMAC-based algorithm, replacing the older DES-based approach and providing stronger cryptographic protection. This helps protect the sign-on process and makes it harder for attackers to break or reuse credentials.

They also support a wider range of characters, let you control how long a ticket is valid instead of relying on a fixed window, and offer improved protection against replay attacks. In short, they strengthen security without forcing changes to existing applications.

Migrating to Enhanced PassTickets

Moving to Enhanced PassTickets is simple. In most cases, it’s a configuration change and no application updates or API changes required. RACF determines whether to generate Legacy or Enhanced PassTickets based on configuration.

You can also run both Enhanced and Legacy PassTickets at the same time. RACF will generate Enhanced PassTickets while still accepting legacy ones, which makes it easy to transition gradually without disrupting existing applications.

How PassTickets Work with RACF

Applications are defined to RACF using a PTKTDATA profile. This includes the application name, the cryptographic key, and the rules for generating and validating PassTickets.

A trusted system or application generates a PassTicket (or asks RACF to generate one) for a specific user and application. It can also be generated externally using the published algorithm, as long as the same key is used. When connecting, the PassTicket is sent in place of a password. It looks and behaves just like one from the application’s perspective.

Authentication is handled through standard RACF interfaces like RACROUTE REQUEST=VERIFY, initACEE, UNIX password services, or z/OS Java APIs. PassTickets are processed as part of normal authentication.

RACF evaluates the value provided. If it recognizes it as a PassTicket, it validates it using the user ID, application name, and the key defined in the PTKTDATA profile. If validation succeeds, RACF authenticates the user, builds the ACEE, and grants access—without ever needing the actual password.

Auditing

PassTicket activity can be logged through RACF SMF records when auditing is enabled, so you can see exactly how authentication is happening. This includes successful logins, replay attempts, generation events, and evaluation details.

With Enhanced PassTickets, the logs also indicate whether a legacy or enhanced token was used. That makes it easier to monitor adoption, support compliance reporting, and verify everything is working as expected. SMF 80 records also show how a user authenticated, whether by PassTicket, password, passphrase, or MFA.

Where You'll See Them

• PassTickets are commonly used in CICS environments, especially to avoid password propagation and reduce dependency on password rotation
• Automated TSO/E logon or job submission
• z/OSMF workflows that need to pass credentials
• Custom middleware or schedulers that want secure, password-free authentication
• MFA-enabled users can be configured to allow PassTickets depending on MFA policy settings.

Best Practices

• Use a unique PassTicket key for each application
• Migrate to using Enhanced PassTickets if still on Legacy PassTicket
• PassTickets have a defined lifetime up to 10 minutes. And enhanced can be configured to less for increased security
• PassTickets handle authentication only, you still rely on RACF profiles, groups, and resource classes for authorization
• System clocks must be synchronized between systems generating and validating PassTickets

Conclusion

PassTickets are still one of the simplest ways to strengthen authentication on z/OS without adding operational overhead. As more workloads rely on automated authentication, setting them up correctly becomes even more important.

In the next post, I’ll take a closer look at Enhanced PassTickets and some of the added protections they provide.