A city discovers dozens of TLS certificates for public portals with no inventory, no owner, and no scheduled rotation. Which cryptographic lifecycle action should the security architect prioritize first?

Cryptographic lifecycle management for municipal portals starts with knowing what material exists and who owns it. An authoritative inventory of TLS certificates and keys—paired with named owners, expiry tracking, and a documented rotation and renewal schedule—creates the control surface every later action depends on. Without that catalog, the city cannot prove coverage, cannot prioritize weak algorithms, and cannot prevent surprise outages when public services expire overnight. Ownership also creates accountability: each certificate maps to a steward who receives renewal alerts and can authorize replacement or revocation.

Replacing every certificate with self-signed material does not fix lifecycle gaps; it removes public trust anchors citizens and browsers rely on and still leaves ownership and expiry unmanaged. Disabling TLS on quieter sites to wait for a new PKI vendor trades confidentiality and integrity for project convenience and expands cleartext exposure on municipal channels. Lengthening keys only on the mayor’s office site leaves orphaned portals unchanged and demonstrates selective hardening without enterprise control of the crypto inventory.

Exam caveat: CISSP emphasizes lifecycle hygiene—generation, distribution, storage, use, rotation, revocation, and destruction—before brand-name algorithm upgrades. Inventory and rotation are foundational, not optional polish after a vendor RFP.

Operational check: export or discover certificates from load balancers, reverse proxies, and application stores; record subject, SAN, issuer, key type/length, owner, and not-after dates; feed renewals into a calendar or CMDB with dual alerts; test revocation and replacement on a nonproduction portal before the first mass renewal window.