Is Your Organization Updated with the Public Key Cryptography Standards?

Introduction

Cryptographic standards exist for two reasons: to make different vendors’ implementations interoperable, and to prevent the well-known implementation errors that show up again and again in hand-rolled cryptographic schemes. The Public Key Cryptography Standards (PKCS), a numbered set of specifications originally published by RSA Laboratories and now largely maintained through IETF RFCs and OASIS technical committees, are what make that interoperability possible for public key cryptography. This post walks through what each active PKCS standard covers, which ones have been superseded and by what, and what an organization should actually check to know whether its PKI, HSMs, and certificate workflows are still aligned with current practice.

Quick Answer: What Are the PKCS Standards?

PKCS is a set of specifications, numbered 1 through 15, that define how public-key cryptography is implemented in practice: key formats, certificate requests, encrypted message syntax, and the interface to cryptographic hardware. Several PKCS numbers have since been formalized as IETF RFCs or moved to OASIS, but the numbering is still the common shorthand the industry uses.

Key Takeaways

• PKCS #1 (RSA), PKCS #10 (certificate requests), PKCS #11 (hardware token interface), and PKCS #12 (identity/key transfer) are the four PKCS numbers most PKI and HSM deployments touch directly today.
• Several PKCS numbers are now published under different names: PKCS #1 is IETF RFC 8017, and PKCS #7 has been superseded by Cryptographic Message Syntax (CMS), currently RFC 5652.
• PKCS #11 (Cryptoki) is no longer maintained solely by RSA Laboratories; it now sits under an OASIS technical committee, with the current specification at version 3.2, approved June 2026.
• NIST finalized its post-quantum cryptography standards (FIPS 203, 204, and 205) on August 13, 2024, which means the RSA and Diffie-Hellman algorithms PKCS #1 and PKCS #3 were built around now have a dated retirement path.
• Auditing which PKCS versions your PKI, HSMs, and applications actually implement is a prerequisite for any crypto-agility or post-quantum migration plan.

Why This Matters Now

PKCS standards are not just historical trivia. NIST finalized ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) on August 13, 2024, and every one of those new algorithms needs an identifier, key format, and message syntax defined somewhere, which almost always means an update to the PKCS family or its RFC successors that your applications, HSMs, and certificate tooling need to actually support before they can issue or validate a post-quantum certificate.

Certificate automation is also accelerating because of a separate deadline. Under CA/Browser Forum Ballot SC-081v3, approved April 11, 2025, publicly trusted TLS certificate validity drops from 398 days to 200 days starting March 15, 2026, then to 100 days from March 15, 2027, and to 47 days from March 15, 2029 onward. That schedule depends entirely on automated certificate requests built on PKCS #10 and automated identity transfer built on PKCS #12, so gaps in how those formats are implemented turn into outages fast. DigiCert’s Trust Pulse Survey, published July 2, 2025, found that nearly half of enterprises experienced a certificate-related outage in the past year, with 37.5% of incidents tied specifically to expired certificates, which is exactly the failure mode that manual, non-standardized certificate handling produces.

PKCS Specifications at a Glance

The table below lists each PKCS number, its subject, and its current status. Several have been retired or absorbed into an IETF RFC; others are still actively maintained under their PKCS number.

No.	PKCS Title	Current Status
1	RSA Cryptography Standard	Published as IETF RFC 8017 (RSA Cryptography Specifications v2.2)
2	(RSA signature and message-digest)	Incorporated into PKCS #1
3	Diffie-Hellman Key Agreement Standard	Superseded by IEEE 1363a and ANSI X9.42/X9.44/X9.63
4	(RSA key syntax)	Incorporated into PKCS #1
5	Password-Based Cryptography Standard	Still referenced; latest version published as IETF RFC 8018
6	Extended-Certificate Syntax Standard	Historical; superseded by X.509 v3 extensions
7	Cryptographic Message Syntax Standard	Superseded by CMS, currently IETF RFC 5652
8	Private-Key Information Syntax Standard	Active; also published as IETF RFC 5958
9	Selected Object Classes and Attribute Types	Active, current version 2.0
10	Certification Request Syntax Standard	Active; also published as IETF RFC 2986
11	Cryptographic Token Interface Standard (Cryptoki)	Now maintained by OASIS; current specification version 3.2, approved June 2026
12	Personal Information Exchange Syntax Standard	Active, current version 1.1
13	(reserved for elliptic curve cryptography)	Never published
14	(reserved for pseudo-random number generation)	Never published
15	Cryptographic Token Information Syntax Standard	Active, maintained by OASIS PKCS 15 Technical Committee

PKCS Standards In Depth

Public key cryptography is based on an asymmetric cryptographic algorithm, using two mathematically related keys, a public key and a private key, where deriving the private key from the public key is computationally infeasible. Users publish their public keys in directories such as LDAP, while private keys stay with their owner. The PKCS standards below define exactly how those keys, certificates, and messages are formatted so that different vendors’ software can interoperate.

PKCS #1: RSA Cryptography Standard

PKCS #1 defines RSA-based public key encryption and digital signature schemes, along with the ASN.1 syntax for representing RSA keys. It is now published as IETF RFC 8017, RSA Cryptography Specifications Version 2.2. RSA’s security rests on the difficulty of factoring the product of large prime numbers, and the standard also defines multi-prime RSA, where the modulus is the product of more than two primes to improve performance of RSA operations.

PKCS #3 (Superseded): Diffie-Hellman Key Agreement Standard

PKCS #3 described how two parties agree on a secret key known only to them using Diffie-Hellman key agreement. It has been superseded by the modern treatment of key establishment in IEEE 1363a and ANSI X9.42, X9.44, and X9.63.

PKCS #5: Password-Based Cryptography Standard

Most public-key systems ultimately depend on a password somewhere, most often to encrypt a stored private key. Passwords create two problems: they are not directly usable as cryptographic keys, and they are drawn from a much smaller space than a proper key, which makes them vulnerable to search attacks. PKCS #5 defines key derivation functions, encryption schemes, and message-authentication schemes that turn a password into something safe to use cryptographically. The current version is published as IETF RFC 8018.

PKCS #6 (Historical): Extended-Certificate Syntax Standard

PKCS #6 was drafted when X.509 was still version 1.0 and certificates had no extensions field. Once X.509 v3 introduced the extensions component, PKCS #6 became historical, since any information it added can now live directly in a standard X.509 v3 certificate.

PKCS #7 / CMS: Cryptographic Message Syntax

PKCS #7 has been superseded by Cryptographic Message Syntax (CMS), currently IETF RFC 5652, which is the basis for the S/MIME specification. CMS defines the syntax used to digitally sign, digest, authenticate, or encrypt arbitrary message content, and it supports nested encapsulation, meaning one signed or encrypted envelope can wrap another. A range of certificate-based key management architectures, including the one defined by the IETF PKIX working group, are supported by CMS.

PKCS #8: Private-Key Information Syntax Standard

The security of any public-key system depends entirely on protecting the private key, which is generally encrypted with a password and stored on disk or in a token. PKCS #8, also published as IETF RFC 5958, defines a standard syntax for private-key information, including the key itself, a set of attributes, and a syntax for the encrypted form, so private keys can move between systems without a proprietary conversion step.

PKCS #9: Selected Object Classes and Attribute Types

To support PKCS-defined attributes in LDAP and X.500-based directory systems, PKCS #9 defines two auxiliary object classes, pkcsEntity and naturalPerson, so PKCS attributes can be stored in a directory and exported to other environments. It also defines attribute types used elsewhere in the family, such as challengePassword and extensionRequest in PKCS #10, and several attribute fields used in CMS.

PKCS #10: Certification Request Syntax Standard

PKCS #10, also published as IETF RFC 2986, specifies the syntax for a certificate signing request (CSR). When an entity wants a public key certificate, it builds a CSR and sends it to a certification authority, which authenticates the requester, verifies the request’s signature, and, if valid, issues an X.509 certificate built from the distinguished name, public key, issuer name, serial number, validity period, and signature algorithm. This is the format every ACME, SCEP, and EST-based automated enrollment workflow still relies on today.

PKCS #11: Cryptographic Token Interface Standard (Cryptoki)

PKCS #11 defines “Cryptoki,” an application programming interface to devices that hold cryptographic material and perform cryptographic operations, such as smart cards and Hardware Security Modules (HSMs). It presents a technology-independent, object-based view of the device as a “cryptographic token,” so an application can talk to any compliant token without knowing its internal details. PKCS #11 is no longer solely an RSA Laboratories document; it is now maintained by an OASIS technical committee, with the current specification at version 3.2, approved as an OASIS Standard in June 2026.

PKCS #12: Personal Information Exchange Syntax Standard

PKCS #12 defines a transfer syntax for personal identity information: private keys, certificates, and other secrets, bundled into a single portable file (the familiar .p12 or .pfx format). It builds on PKCS #8 by adding identity information alongside the private key and layering on public-key-based privacy and integrity protections, which is why it remains the standard way to move a certificate and its private key between systems, browsers, and applications.

PKCS #15: Cryptographic Token Information Syntax Standard

Cryptographic tokens such as smart cards are secure computing platforms that can hold digital certificates, authorizations, and cryptographic keys, and can perform operations on that data without exposing it to a potentially compromised host. PKCS #15 defines a common on-token format for these credentials, so applications from different vendors can read digital credentials off the same token instead of each requiring a proprietary format. It is now maintained by an OASIS technical committee.

How the Standards Fit Together: A Certificate’s Life Cycle

The PKCS family is easiest to remember by where each standard sits in a certificate’s life cycle:

1. A private key is generated and stored following PKCS #8 (private-key syntax), often inside an HSM accessed through PKCS #11 (Cryptoki).
2. A certificate signing request is built following PKCS #10 and submitted to a Certificate Authority.
3. The CA issues an X.509 certificate, and any signed or encrypted messages exchanged along the way use CMS (formerly PKCS #7) syntax.
4. The certificate and its private key are packaged for transfer or backup following PKCS #12, protected using password-based cryptography defined in PKCS #5.
5. If the credential lives on a smart card or token rather than in a file, it is stored following PKCS #15.

Practical Checklist: Auditing Your Organization’s PKCS Usage

• Confirm which RSA key sizes and padding schemes your applications actually implement against current PKCS #1 / RFC 8017 guidance, rather than a hard-coded value chosen years ago.
• Verify every CSR-issuing system (ACME, SCEP, EST, or a manual process) produces PKCS #10-compliant requests that your CA accepts without manual patching.
• Check the PKCS #11 version your HSMs and applications support, since a mismatch between an HSM’s supported Cryptoki version and an application’s expected version is a common source of integration failures.
• Inventory where PKCS #12 files (.p12/.pfx) are stored, who can access them, and whether they are password-protected with a strong, unique password rather than a shared default.
• Map which of your currently deployed algorithms are RSA or Diffie-Hellman based (PKCS #1 and PKCS #3 territory), since those are exactly the algorithms NIST’s post-quantum standards are designed to eventually replace.
• Run a cryptographic discovery and inventory pass to find any certificates, keys, or tokens that were never accounted for in the checks above.

Glossary and Decision Table: When Each PKCS Standard Matters

Concept	When It Matters	Example	Implementation Consideration
PKCS #1 (RFC 8017)	Any RSA key generation, encryption, or signing	TLS server certificate using RSA	Confirm padding scheme (OAEP/PSS) matches current guidance, not legacy PKCS #1 v1.5 padding
PKCS #10 (RFC 2986)	Requesting a new certificate from any CA	ACME client generating a CSR for auto-renewal	Automate generation; manual CSR creation is the most common source of shrinking-lifetime outages
CMS / PKCS #7 (RFC 5652)	Signing or encrypting a message or file, including S/MIME email	Code-signing signature wrapped in a CMS structure	Confirm tooling targets current CMS (RFC 5652), not the retired PKCS #7 document directly
PKCS #11 (Cryptoki)	Any application that needs to use keys stored in an HSM or smart card	A CA’s signing service calling into an HSM to sign a certificate	Match the Cryptoki version your HSM vendor supports against what your application expects
PKCS #12	Moving a certificate and private key between systems	Exporting a client certificate from one browser to import into another	Enforce strong, unique passwords; treat every .p12/.pfx file as sensitive as the private key itself
PKCS #15	Storing credentials on a smart card or hardware token	An employee badge that also holds a login certificate	Confirm the token and the reading application agree on the same PKCS #15 profile

Who Should Care About This

PKCS compliance is not just a PKI team concern. Here is what each role should take away.

PKI Administrators

Own which PKCS versions the CA, HSMs, and issuance tooling actually implement. Action item: confirm CSR handling matches current PKCS #10/RFC 2986 syntax and that no legacy, deprecated padding schemes remain in production.

Security Architects

Own how PKCS-defined algorithms map onto the organization’s crypto-agility and post-quantum migration plan. Action item: identify every system relying on PKCS #1 (RSA) or PKCS #3 (Diffie-Hellman) as a starting inventory for post-quantum readiness.

Platform/DevOps Teams

Own the automation that generates PKCS #10 CSRs and handles PKCS #12 files in CI/CD pipelines. Action item: confirm secrets scanning covers .p12/.pfx files so they are never committed to source control unencrypted.

Compliance Teams

Own the evidence that cryptographic implementations match current standards rather than retired ones. Action item: verify audit documentation references current RFC numbers (RFC 8017, RFC 5652, RFC 2986) rather than outdated PKCS version numbers alone.

CISOs

Own the budget and timeline for crypto-agility work driven by shrinking certificate lifetimes and the post-quantum transition. Action item: treat a PKCS/cryptographic standards audit as a prerequisite line item in any PQC migration budget, not an afterthought.

Our Take: How Encryption Consulting Supports Cryptographic Standards Compliance

Encryption Consulting LLC helps organizations confirm their PKI, HSMs, and applications actually implement current cryptographic standards rather than the legacy versions many environments were built on years ago. Our CertSecure Manager and PKI-as-a-Service platforms automate PKCS #10 certificate requests and PKCS #12 credential handling so certificate issuance keeps up with shrinking validity windows without manual intervention, and our HSM-as-a-Service gives applications a current, standards-compliant PKCS #11 interface to FIPS-validated key storage.

For organizations planning ahead of the post-quantum transition, our PQC Center of Excellence and CBOM Secure cryptographic discovery and inventory identify every RSA and Diffie-Hellman based system still running on the algorithms PKCS #1 and PKCS #3 were built around, which is the starting point for any credible migration plan. For further reading, see IETF RFC 8017 (PKCS #1), IETF RFC 5652 (CMS), and OASIS PKCS #11 v3.2.

Conclusion

The PKCS numbering is still the common shorthand the industry reaches for, but several of the standards behind those numbers have moved: PKCS #1 is now RFC 8017, PKCS #7 has become CMS under RFC 5652, and PKCS #11 and PKCS #15 are now maintained by OASIS rather than RSA Laboratories alone. None of that is cosmetic. Shrinking certificate lifetimes depend on PKCS #10 automation working correctly, HSM integrations depend on matching PKCS #11 versions, and the post-quantum transition starts with knowing exactly where PKCS #1 and PKCS #3’s RSA and Diffie-Hellman algorithms are still running. An organization that has not checked which version of each standard it actually implements cannot credibly claim to be ready for any of those three shifts.

Frequently Asked Questions

What is the main takeaway from the PKCS standards?

PKCS is a numbered set of specifications that define how public-key cryptography is implemented in practice, but several PKCS numbers have since been formalized as IETF RFCs or moved to OASIS. Organizations should track the current RFC or OASIS document behind each PKCS number they rely on, not just the original PKCS number itself.

Why does this matter for enterprise PKI teams?

PKI teams rely on PKCS #10 for every certificate request, PKCS #11 for every HSM integration, and PKCS #12 for every credential transfer. A mismatch between what an application expects and what a standard’s current version specifies is a common source of failed automation and outages.

What risks increase if PKCS compliance is handled manually or ignored?

Manually maintained systems tend to keep running on retired standards like the original PKCS #7 instead of current CMS, or on outdated PKCS #1 padding schemes, which increases the risk of interoperability failures and known cryptographic weaknesses that current versions were specifically revised to close.

Which teams should own PKCS compliance?

PKI administrators typically own day-to-day compliance of the CA and issuance tooling, security architects own how PKCS-defined algorithms map to the crypto-agility roadmap, platform teams own automation that generates CSRs and handles credential files, and compliance owns the audit evidence trail.

How does PKCS connect to certificate lifecycle management?

Certificate lifecycle management depends on PKCS #10 for requesting certificates and PKCS #12 for transferring and backing up the resulting certificate and private key. As certificate lifetimes shrink toward 47 days under the CA/Browser Forum’s schedule, automation built on these formats has to work correctly at much higher frequency than before.

What common mistakes should teams avoid?

Common mistakes include citing the original PKCS number without checking its current RFC or OASIS successor, using outdated PKCS #1 v1.5 padding instead of current OAEP/PSS guidance, storing PKCS #12 files with weak or shared passwords, and assuming an HSM’s supported PKCS #11 version automatically matches an application’s expected version.

What is PKCS #11, and why does it matter for HSMs?

PKCS #11, also called Cryptoki, is the standard application programming interface applications use to talk to Hardware Security Modules and smart cards. It is now maintained by an OASIS technical committee, with the current specification at version 3.2, approved June 2026, and version mismatches between an HSM and an application are a frequent source of integration failures.

How does PKCS connect to the post-quantum cryptography transition?

PKCS #1 and PKCS #3 define the RSA and Diffie-Hellman algorithms that NIST’s finalized post-quantum standards, FIPS 203, 204, and 205, published August 13, 2024, are designed to eventually replace. Inventorying every system that relies on PKCS #1 or PKCS #3 is a practical first step toward a post-quantum migration plan.

What should be reviewed periodically to keep PKCS usage current?

Periodically review which RFC or OASIS version each PKCS-derived standard your organization implements resolves to, whether HSM firmware and application libraries agree on a common PKCS #11 version, and whether any system still depends on a formally retired document like the original PKCS #7 rather than its CMS successor.