Join our Newsletter — 33% off our NHI Course
Home› FAQ› Foundations & NHI Taxonomy› How should security teams scale PKI when most…
Foundations & NHI Taxonomy

How should security teams scale PKI when most employees suddenly start working remotely?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated September 25, 2026 Domain: Foundations & NHI Taxonomy

Security teams should treat remote work as a scale problem, not just a connectivity problem. The first priority is inventorying which certificates exist, what they protect, and where they live. From there, teams can prioritize the assets that now matter most, such as VPN and remote access paths, and ensure certificate lifecycle management can operate beyond the traditional office boundary.

When most employees move remote at once, PKI stops being a desktop convenience and becomes a core access dependency. The practical challenge is not just issuing more certificates, but keeping issuance, renewal, revocation, and inventory reliable when endpoints are outside the office network and IT’s normal support path.

What changes in PKI when remote work becomes the default?

Remote work changes the certificate population, the trust boundaries, and the operational tempo. Devices may never touch the corporate LAN, so certificate discovery and renewal can no longer rely on office-bound tooling or manual support. That makes visibility into certificate owners, expiration dates, and dependencies essential before scale problems turn into outages.

Teams should also expect more pressure on remote access services. VPN gateways, remote desktop infrastructure, Wi-Fi access, and device authentication often become the first systems that expose certificate fragility when access demand suddenly rises. The right response is to map which certificates directly protect business continuity and prioritize those paths first.

At scale, the main failure mode is not a single expired certificate. It is a missed renewal workflow, a hidden certificate on an unmanaged system, or a revocation process that cannot keep up with churn. When those weak points are distributed across many endpoints, even small process gaps can affect large parts of the workforce.

How should teams scale the certificate lifecycle?

Scale starts with inventory and ownership. Teams need a current list of certificates, where they are deployed, what service or device they protect, and which renewal mechanism controls them. Without that baseline, automation and policy enforcement are usually incomplete because they miss shadow certificates and legacy dependencies.

From there, the lifecycle should be centralized enough to reduce manual effort but flexible enough to support remote users and devices. That usually means automated issuance and renewal, clear certificate expiration thresholds, and reliable revocation paths that do not depend on someone being on-site. For certificate lifecycle discipline, the NIST SP 800-57 Key Management guidance is a strong reference point.

Publicly trusted certificates also need strong alignment with issuer and revocation practices. Where external trust is involved, certificate policy and baseline requirements matter because remote work amplifies the consequences of delayed revocation or weak issuance hygiene. The CA/Browser Forum baseline requirements are especially relevant when internet-facing trust chains are part of the environment.

For teams dealing with broad credential estates, certificate management should sit alongside the wider access and secret inventory problem. A compromised repository or unmanaged workflow can expose multiple trust artifacts at once, including certificates and keys. The Sisense breach is a useful reminder that secret and certificate exposure can scale quickly once access boundaries fail.

How do you avoid outages while expanding remote trust?

The safest approach is to separate business-critical certificates from lower-priority ones and protect the former with tighter monitoring and shorter renewal windows. Certificates that support authentication into VPN, remote access, device trust, or internal services should be treated as availability-critical, because their failure can block work across the organisation.

Teams also need to validate that certificate telemetry is visible outside the office. If monitoring only sees on-prem traffic, remote failures can look like user problems until they become widespread. Good practice is to track issuance success, renewal success, expiration proximity, and revocation latency as operational signals, not just compliance data.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-57, NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST SP 800-57Key ManagementPKI scaling depends on certificate and key lifecycle management.
Recommendation — Centralize key lifecycle policy and automate rotation, renewal, and revocation.
NIST SP 800-53 Rev 5IA-5 — Authenticator ManagementCertificate operations are part of managing authenticators and their lifecycle.
IA-9 — Service Identification and AuthenticationRemote PKI often secures services, devices, and automated access paths.
Recommendation — Enforce lifecycle controls for certificates, keys, and renewal thresholds. Use service authentication controls to protect remote access paths and machine trust.
NIST CSF 2.0PR.AA-05 — Identity Management, Authentication and Access ControlPKI supports authentication and access control for remote workers and devices.
Recommendation — Maintain identity and access controls that remain reliable outside the office boundary.
CIS Controls v8CIS-5 — Account ManagementScaled PKI requires ownership, inventory, and lifecycle oversight of access material.
Recommendation — Inventory and govern certificate-related access artifacts with clear ownership.

Practitioner Guidance

What to prioritise: Start with the certificate paths that can stop remote work entirely, especially VPN, remote access, device trust, and internal authentication flows. If a certificate failure would prevent login or connectivity for many users, it belongs in the highest-priority recovery bucket.

What to verify: Confirm that every production certificate has an owner, a renewal method, a failure alert, and a tested revocation path. If any of those four are missing, treat the certificate as operationally fragile even if it is not close to expiration.

Practitioner takeaway: Remote scale exposes PKI weak points fastest where certificate inventory is incomplete and lifecycle automation is only partially deployed, so the real objective is resilient certificate operations, not just more certificates.

Deepen Your Knowledge

Sign up to our weekly newsletter — get 33% off our NHI Foundation Level Course

    NHIMG Editorial Note
    Reviewed and updated by the NHIMG editorial team on September 25, 2026.
    NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org