Frequently asked questions

We connect readers using OSDP, and one of the things our test environment does is observe the response time when a card is presented. It does this by monitoring the messages exchanged between the reader and the panel. There is, in fact, a 200 millisecond threshold in OSDP beyond which issues can occur.

We track these timings closely, and with PKOC keycards using NFC, the number of message exchanges is very small. As a result, the unlock time typically falls within the 30 to 100 millisecond range, well under 200 milliseconds.

Additionally, from a metrics perspective, we have used apps and cards with built-in diagnostics to measure and track timing directly. This is done alongside the OSDP test tool, so the figures are verified and not just estimates.

FIDO is more focused on the logical (digital authentication) side, whereas PKOC has traditionally focused more on the physical (access control) side. However, the two can coexist well. In fact, it’s possible to have a single credential that supports both FIDO and PKOC.

Both approaches are based on asymmetric cryptography, but they serve different purposes. They are also both industry standards that can be considered together rather than as competing options. In practice, it’s more about how they complement each other than how they differ.

FIDO 2 for enterprise environments relies heavily on public key cryptography and, in some cases, certificates. PKOC also uses similar underlying technologies, though the way messages and protocols are structured differs, especially when compared to traditional access control models.

With modern smart cards or mobile devices, it is entirely reasonable to deploy both technologies together. In fact, this is often what happens in real-world implementations. For example, a single credential can support both FIDO2 and PKOC when used with a multi-technology reader capable of handling both.

In short, coexistence is not only possible but practical, and many deployments could successfully use both technologies side by side.

First, the issuance or creation of keys is a function of PKI. When you install an applet on a smart card, such as a Java Card or another secure card, or install a mobile app (and in the future, PKOC may support wallets), the credential is created at that stage. As part of this creation process, a public/private key pair is generated.

Once generated, the public key exists, and the derivative we use is the X portion of that key, which is 256 bits. To meet PKOC compliance, the minimum requirement is to use the last 8 bytes (64 bits) of that X portion. This provides sufficient randomness to avoid duplicate credentials, eliminating the need for site codes or facility codes. The system can also support up to the full 256 bits if required.

Provisioning is effectively self-service. After the key is created, the next step is obtaining permission to send the public key to the system that will enroll it. The system extracts the X portion and uses it as the credential representation.

In environments with more than 50,000 users, this process scales efficiently. Invitations can be sent simultaneously to all users, who can then complete enrollment at their own pace through the app. This approach avoids bottlenecks and supports large-scale deployments, particularly in mid-sized to enterprise PACS environments.

PKOC uses the key as a core part of the credential, and there is no third-party signing operation involved. This means there is no need for a certificate authority. Since the keys are generated at the time the application or card is created, there is no requirement for a formal issuance ceremony.

For example, if you purchase 1,000 or 50,000 cards from a manufacturer, they will show up with preloaded with key pairs. These keys are generated within a secure, certified environment on the smart card itself, or via equivalent secure mechanisms on a mobile device.

Starting with the controller side: most modern controllers can already handle a minimum 64-bit card number. From the controller’s perspective, it is simply receiving a long card number from the reader. At this stage, the reader is responsible for passing that value through.

We are working on a second iteration of the specification where the controller performs the authentication, but for now the reader simply sends the long card number. Because of this, it is important to ensure your panels accept at least a 64-bit number. A 128-bit capacity is better, and if possible, 256-bit support is ideal.

In most cases, existing panels can be repurposed.

If you are using OSDP-capable devices, modern systems should be able to use standard mechanisms to perform firmware updates on readers and update credential formats. With sufficiently modern hardware, the intention is that readers can be updated to support PKOC or other new credential types, and also configured to use the correct format.

However, if you have very old readers, such as 20-year-old Wiegand devices, you will not be able to do this. In those cases, you are effectively forced into replacement, which is expected with legacy technology like this during any migration process.

As for credentials, these are new. They are provisioned at the factory with a public key already loaded, or in the case of mobile credentials, the key is generated when you enrol and create the credential on the device.

From a PACS perspective, PKOC is treated as a card format that can range from 64 bits up to 256 bits. Some PACS systems, such as those based on Mercury hardware, may limit this to 200 bits. However, many modern PACS platforms especially those used in government environments, will support at least 200 bits, and often up to 256 bits.

For legacy systems, support may drop down to 64 bits depending on the age of the reader and system capabilities. The key requirement is having readers that are PKOC-compliant and capable of being updated.

Migration to PKOC can be approached in different ways. One option is to issue multi-technology credentials that support existing technologies, such as proximity, MIFARE, or DESFire, while also including the new public-key credential. As new readers are introduced, the same credential will work across both old and new infrastructure. Over time, you can phase out legacy readers without a full rip-and-replace approach.

Another option is to deploy multi-technology readers that can interpret multiple credential types. This allows you to migrate at a pace that aligns with budget and operational constraints, rather than replacing everything at once.

There are, however, licensing and deployment considerations depending on the existing credential infrastructure, and these must be followed carefully. Engaging with PSIA members or relevant vendors is recommended to ensure the migration approach is correctly designed for your environment.

First of all, the intention is typically for the user to have the same credential across both systems. Ideally, you wouldn’t need separate PKOCs for A and B. The whole point of planning from the start is to use the same credential and enroll it across the various systems, so this wouldn’t become an issue.

However, if you do have two PKOCs on the same device, the situation isn’t really that different from using physical cards. For example, if I have two prox or MIFARE cards, one from Building A and one from Building B, the reader will recognise both formats, if configured to do so. However, the card from Building B won’t be enrolled in Building A’s system, so it will simply be treated as an unknown card. The same principle applies to PKOC credentials.

As mentioned earlier, there’s generally no need to have multiple PKOCs, because you could take a Kastle PKOC and enroll it in a Johnson Controls C.CURE system, and it would work fine. That’s the whole interoperability concept: any PKOC credential can work with any PKOC-compliant reader. This ideally removes the need for multiple credentials altogether.

That said, if multiple PKOCs are used, the credential intended for a specific system e.g. Johnson Controls would need to be enrolled as a separate credential. In that case, both credentials could work, but it ultimately comes down to how they are enrolled.

Another way to look at it is that, since the credential is open and you can build logic around it, you could intelligently select which credential to use. For example, you could use GPS location or a Bluetooth iBeacon to determine which credential should be active. This gives you more flexibility to design the user journey, you can use a single credential, multiple credentials, or dynamically select the appropriate one based on context.

Additionally, many mobile apps already allow users to select which credential they want to use. This is something people are doing today. For example, in a scenario where there are two different sites belonging to two different customers, and they require separate credentials for compliance reasons, users could still manage both on a single mobile device. Instead of carrying two physical badges, they could simply select the appropriate credential within the app depending on the site.

Today PKOC is not in the wallet. For those of you that are following the open standards this February 2026, we saw the launch of Aliro. Aliro is native wallet out of the gun but it creates the ability to support the public key infrastructure, which is certainly the same foundation that public key open credential is based on. With Apple’s and Google’s focus on CSA and Aliro we’ve purposely not had those conversations and are letting Aliro pave the way for this capability, it can certainly be a future discussion for PKOC. But today, it is not Wallet, it is app, and it is card.

The PKOC specification process will advocate three specific formats 64, 128 and 256 bit with the intention that readers in a given deployment will be set up for one of these formats, with the idea that you pick a format that works on all the readers that you’re using. 

64 bit is very common, it’s not so common for readers to be able to output to 256 or for PACS vendors to read it, so 64 bit tends to be the dominant one, but the idea is you would configure the devices to read the same format. You wouldn’t have one PKOC card for deployment which is in a system in three different formats. You’d stick with one format.

64 bit would be your default but customers are pressing to go higher up to 256 bit to add extra security. However the PKOC working group will continue to advise and encourage people to use the strongest option available. Over time, as products evolve and our legacy hardware is phased out and newer equipment launches, the idea is that we all embrace 256 bit and stay stronger.