Integrating cryptography with Identity and Access Management (IAM) isn’t just a good idea – it’s a necessity in today’s complex threat landscape. For too long, information security frameworks have treated cryptography, especially PKI, as a separate entity from access control. While PKI’s historical focus on human identity lifecycle management (think Registration Authorities, Certificate Authorities, and identity proofing) made sense in its time, it now significantly overlaps with modern enterprise IAM systems. Traditional PKI models, often defined by RFC 6484-style Certificate Policies, even included physical security, audit logs, and personnel controls – domains now covered mainly by ISMS frameworks like NIST SP 800-53 or ISO 27002. This redundancy creates complexity and potential inefficiencies.
Organizations grappling with regulations like DORA and NIS-2, or simply trying to mitigate information security and privacy risks, must effectively weave cryptography into the fabric of their IAM. This integration must also account for modern realities: the rise of cloud computing, the complexities of supply chain management, the criticality of incident response, and the ever-expanding attack surface.
Understanding Stakeholder’s PKI Needs
So, where do we begin? A key first step is understanding stakeholder information needs. By framing these needs as pointed questions – much like a well-crafted Statement of Work – we can define project scope and deliver precisely what’s required. Here are ten critical questions to guide your thinking:
1. Who are we dealing with: B2E, B2B, or B2C?
Just as in Identity Governance and Administration (IGA), protection needs are intrinsically linked to the “user”. We must consider both the legal/organizational context (workforce, business partner, consumer, etc.) and the user’s nature (human, device, workload, service, agent). One-size-fits-all policies simply won’t cut it. Policies must fit each category’s specific requirements.
2. How sensitive is the data: Public, Restricted, or Highly Restricted?
A tiered approach, typically three or four levels, offers a practical compromise between granular control and manageable complexity. This applies across the board – identity assurance (think NIST 800-63 LoA), risk profiles (NIST 800-53 baselines), and information classification (public, restricted, highly restricted). We need clear policies dictating when data must be encrypted. For instance:
- Restricted Data: Encrypt when traversing external networks.
- Highly Restricted Data: Encrypt always.
Don’t forget Segregation of Duties (SoD). Should system administrators really have unfettered access to highly restricted data? Think carefully about the implications. This adds another layer of security if an admin account is hijacked.
3. Scoping cryptography, what are use cases and cryptographic application domains?
Let’s avoid muddying the waters with an overly broad definition of “use case.” We’ll stick to the classic actor-uses-black-box metaphor (enrollment, key distribution, revocation, key escrow). “Cryptographic application domains,” on the other hand, are technology-dependent: TLS, SSH, IPSec, storage encryption, secure boot, code signing, Kerberos, WebSSO, client authentication, S/MIME, document signatures – the list goes on.
4. How do IAM assurance levels connect to cryptographic keys?
Managing keys securely is a constant battle. The late 90s hype around smart cards and dedicated terminals has given way to more scalable, but often less secure, approaches. Private keys are now often centrally generated, stored in directories, or held within Windows domain login sessions. While scalability is paramount, we must balance it with risk. Hardware-based key protection remains a best practice for high-assurance needs.
5. How do we enforce segregation of duties in high-risk environments?
When defining key management controls, ask yourself these tough questions:
- If keys are accessible via enterprise SSO, how do we achieve sufficient assurance?
- Do we need a separate, hardened environment (jump host, privileged access workstation)?
- How do we prevent administrators from impersonating key holders?
6. What are the critical differences between normal operations and emergency recovery?
Incident recovery demands meticulous planning. Consider:
- Can we establish a secure operational base with minimal dependencies during a crisis?
- Can we support secure login without relying on enterprise SSO (hint: X.509 client certificates are your friend)?
Smoothly operating, highly interconnected systems can become a tangled mess during recovery. A simple, isolated PKI for a small group of indispensable administrators, using smartcard-like USB tokens, can be a lifesaver, providing a trusted authentication platform in both normal and recovery modes.
7. How tightly is asset management integrated?
Many organizations fail to properly map cryptographic uses and key material to their asset inventory. Drill down:
- Do we know who owns the keys and certificates? Is there a clear link to an asset owner role?
- Is the protection level of keys and certificates derived directly from the asset’s protection level?
- What algorithms, parameters, key sizes and protocols are used where?
- What should be encrypted but isn’t?
8. What about roles, responsibilities, and organizational structure?
Consider these organizational factors:
- Is the PKI team tied to a specific technology (like Active Directory)? If so, does the CA’s security depend on it?
- Are responsibilities for decentralized key material clearly defined for server and service administrators?
9. How do we manage key and certificate lifecycles effectively?
Ask yourself:
- When can we leverage standard IGA processes (request, approve, auto-provision, recertification)?
- How do we align data between existing key management systems and IGA?
10. How do we handle user-based encryption securely?
User-based encryption is deceptively complex and requires a risk-based analysis. Encryption itself is straightforward; key management combined with entitlements is the real challenge. Crucial questions include:
- What technique do we use to share access to encrypted content? (Shared keys are a terrible idea; key wrapping with individual keys is best practice; a KMS is a secure alternative).
- How do we use entitlement management to grant multiple users access to an encryption key?
- What safeguards are in place during provisioning to prevent unauthorized key access?
PKI, IAM, and Governance
These ten questions underscore the fundamental overlap between cryptography and IAM. Effective governance and architecture planning requires close collaboration – a true meeting of the minds – between IAM and cryptography experts. Only then can we build truly secure and resilient systems.
Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.
For additional reading on PKI and IAM, see the IDPro Body of Knowledge article, “Practical Implications of Public Key Infrastructure for Identity Professionals” by Robert Sherwood.
Author
Rainer Hörbe, based in Vienna, Austria, is Senior IAM Architect at KPMG.
