Public Key Infrastructure (PKI) is like experiencing a renaissance. PKI, formerly thought to be the realm of cryptography specialists and obsolete hardware, is now a strategic enabler of business identity and access management, with one key difference: it no longer requires ownership by a specialized team.
Today, PKI management is not about forming a new team. It’s about providing your existing IT, security, and identity teams with the necessary tools to support scalable, certificate-based authentication. With cloud-native platforms such as SecureW2, the emphasis changes from infrastructure maintenance to cross-functional collaboration.
Let’s look at how PKI ownership has changed and what a modern PKI management team structure looks like.
Traditional PKI: Who Used to Own It?
Historically, PKI was a specialized service carried out by specific security teams or cryptography experts. Common roles included:
- PKI Architect: Developed certificate policies, trust models, and lifecycle strategies.
- CA Admin: Oversaw internal certificate authority, issued/revoked certificates, and maintained CRLs.
- Security Engineers: Integrated PKI with firewalls, VPNs, and authentication systems.
These positions were frequently separated from the IT and application teams, making PKI feel like a black box. The architecture was generally on-premises, consisting of Hardware Security Modules (HSMs), Active Directory Certificate Services (ADCS), and manual revocation methods.
According to the 2024 Ponemon PKI Trends Study, 52% of organizations continue to employ PKI professionals, with the remaining 48% relying on consultants or managed services due to the high complexity and specific skill requirements.
What is the most significant hurdle to PKI success?
No clear ownership, followed by a lack of skills.
The Modern Approach: Cross-Functional Collaboration
PKI is no longer a specialized field limited to hyper-specialized security teams. With the rise of cloud identity, BYOD, and remote work, certificate-based access must now accommodate a more diverse landscape:
- Devices (Both managed and unmanaged)
- Users (employees, contractors, and students
- Networks (Wi-Fi, VPN, Zero Trust settings)
To properly enable this, ownership of PKI transitions from a centralized expert team to a collaborative effort across existing departments:
IT Administrators analyze network records and handle connection issues. They are frequently the first to identify certificate-related issues that disrupt network connectivity.
IAM Engineers verify that certificates are properly mapped to user identities through connections with identity providers such as Azure AD, Okta, and Google Workspace.
MDM Administrators use device management technologies like Intune, JAMF, or Kandji to develop and distribute certificate enrollment profiles such as SCEP or ACME. They also set up the secure API connections required to allow certificate automation.
Help Desk Teams are frequently the initial point of contact for users who face onboarding challenges or certificate failures. With the contemporary stack, they must be able to interact with onboarding tools, verify MDM agent status, and guide people through multi-OS processes.
The introduction of cloud-native software to speed certificate-based access has made it simpler for non-specialists to assist PKI operations. However, this also implies that teams must be educated to interface with these systems as part of their daily tasks.
Bottom line: PKI no longer requires hyper-specialized teams. What you need is cross-functional collaboration, with your existing teams contributing to certificate management in ways that are consistent with their current responsibilities.
Cloud PKI’s Impact on Team Structure
The emergence of cloud-native PKI technologies, such as SecureW2, has fundamentally altered internal team duties. Here are the changes:
What goes away:
- Managing on-premises CA, CRL, and HSMs
- Maintaining complicated ADCS settings.
- Manual certificate revocation procedures
What gets automated:
- Certificate issuance and renewal
- Enrollment rules depend on user/device context.
- Logging and auditing using connected dashboards.
What gets distributed:
- Security defines policy: Who obtains what certificates and at what risk criteria.
- IT enables implementation: By integrating PKI with RADIUS, Wi-Fi, VPN, and so on.
- IAM limits access: SAML and SCIM connections with cloud IdPs (e.g., Azure AD, Okta) enable BYOD and unmanaged device enrollment via user authentication and role-based access.
- MDM automates deployment: For managed devices, pushes SCEP/ACME profiles, assures trusted status, and manages certificate lifecycles depending on device compliance.
Rather than confining PKI management to a single owner, cloud PKI makes it a shared, automated, and integrated component of enterprise IT. Teams focus on governance, not grunt work.
Real-World Example: PKI Without The Experts
A forward-thinking IT consulting agency recently used SecureW2 to evaluate certificate-based authentication before suggesting it to its clients. Their objective was to implement smart card-based authentication and certificate-backed EAP-TLS without devoting significant internal resources or PKI professionals to the task.
Despite the complexity of their goals—smart card login on Mac devices, certificate enrollment for unmanaged BYOD, and connection with Okta—the project was managed exclusively by their current IT staff, with SecureW2 providing the necessary tools and assistance.
Here’s how the deployment looked:
- The agency deployed SecureW2’s PKI to issue X.509 certificates to various managed and unmanaged devices.
- Employees enrolled their own devices utilizing JoinNow MultiOS, a self-service onboarding tool that required no IT assistance to configure.
- Smart cards, such as Yubikeys, were utilized for biometric login on Mac devices, with SecureW2 providing a secure backend solution for Mac keychain integration.
- Cloud RADIUS with Identity Lookup guaranteed that each authentication request was validated in real time against Okta, with the most recent access controls applied dynamically.
What started as a test evolved into a complete deployment. Despite lacking in-house PKI knowledge, the agency was able to build a secure, passwordless authentication solution for their team, demonstrating that with the correct platform, PKI can be operationalized by any business utilizing their current team structures.
Read the full case study here.
How SecureW2 Eliminates the Need for Deep PKI Expertise
Modern PKI is no longer a stand-alone task; it is shared by IT, IAM, MDM, and security teams. SecureW2 enables this by eliminating the traditional infrastructure load. There is no need to administer certificate authorities, CRLs, or HSMs.
Instead, SecureW2 provides a user-friendly platform with built-in automation, allowing regular administrators to manage certificate issuance, renewal, and troubleshooting. Whether it’s enforcing access controls, pushing device profiles, or troubleshooting onboarding difficulties, any team may participate without requiring extensive PKI expertise.
The result? Your existing team structure is sufficient to administer enterprise-grade PKI—specialists are not required.
PKI Success Depends on Team Infrastructure, Not Just Technology
A contemporary PKI team structure focuses on rethinking cooperation rather than increasing numbers. It is an ecosystem of IT, security, IAM, and MDM teams working together to implement a single, certificate-based access approach.
The true infrastructure is not just technological, but also organizational. It is about creating a security-first culture in which all stakeholders contribute to defining and enforcing identity trust.
Cloud-native systems, such as SecureW2, make this feasible. They transform PKI into a service that your current teams can manage, administer, and scale—no cryptography expertise necessary.
Radhika Vyas