WEEK 23 · INVENTORY

Create a CBOM (Cryptographic Bill of Materials)

Know your public endpoints, TLS version and cypher suites before Friday

Submitted by Benjamin Cedoz · Velatura Public Benefit Corp. Director of Cybersecurity

June 1, 2026

Every day we hear news about how artificial intelligence is accelerating research and development in life sciences, pharmaceuticals, and robotics, but the same is true for mathematics and physics.

As a cybersecurity professional, your instincts should be at near constant tingle with the threats and opportunities that this acceleration poses. Specifically, in the realm of quantum computing and what it means for RSA encryption. Estimates suggest that once QC becomes commercially viable, Shor’s algorithm will be able to crack RSA in approximately 9 minutes.

NIST has called for phasing out RSA by 2030, but I argue that AI acceleration + data retention requirements (depending on your industry) + HNDL means you need to act now. That starts with knowing where you are vulnerable so you can make a plan.

So, here is the MondayMove

Without any fancy tools or budget, open a text file and document these answers. What:

  • Are your public endpoints?
  • Version of TLS is in use? (You will need to migrate to TLS 1.3.)
  • Cipher suites does your application support? (You will need to support ML-KEM.)?
  • Is the aging policy on these certs? (You will want to get to 47 days, per upcoming browser requirements, which likely means investing in automation.)?
  • Version of your application introduces support for TLS 1.3 + ML-KEM? (This one will take some research)?

Start this today. Surface it with your organization. The work needs to begin now, and the first step is understanding the full breadth of what you’ll need to do.

Friday Follow-Up

Create a CBOM (Cryptographic Bill of Materials)

Harvest Now, Decrypt Later (HNDL) is a real threat that cybersecurity leaders need to mitigate at their organizations today

Submitted by Ben Cedoz · Velatura Public Benefit Corp. Director of Cybersecurity

June 5, 2026

MondayMove gives you one concrete action every Monday. FridayFollowUp closes the loop.

Each Friday, a short dispatch on what practitioners actually found when they ran the week's move: where they got stuck, what surprised them, and what to do next. Not sanitized case studies. Field notes. Practitioner to practitioner.

This week's move was tactical but uncomfortable: without fancy tools or budget, document your public endpoints, TLS versions, cipher suites, cert aging policies, and when your application will support TLS 1.3 + ML-KEM. Start building your CBOM before quantum computing makes it a crisis instead of a project.

You've had the week. Let's talk about what happened.

We didn't set out to form a roadmap for post-quantum readiness. No vendor pitch. Just an honest check-in on what you actually found when you looked at your cryptographic posture with fresh eyes.

Did you open the text file?

You had to start somewhere.

Did you start the inventory, or did the week swallow it? Was finding your public endpoints easier than expected, or did you realize you don't have a single source of truth? Did you do this solo, or did you need to pull in someone from infrastructure or DevOps?

What the inventory actually showed you

How many endpoints did you document? Were there any surprises — shadow IT, forgotten test environments left open to the public, third-party integrations you'd lost track of? What TLS versions are you running? Any TLS 1.0 or 1.1 still in production?

How deep did you get into the cipher suites? Did you already know what cipher suites your applications support, or was this new territory? How many of your endpoints are quantum-vulnerable right now? Did you find any weak or deprecated ciphers still enabled?

The cert question nobody wants to answer

What does your current certificate posture look like? Are you at 90 days, a year, longer? How close are you to the upcoming 47-day browser requirement? Is your renewal process automated or still manual?

The vendor conversation

Did you find documentation on when your application stack will support post-quantum cryptography? Did you discover that your vendors don't have a timeline yet? Is this something your team controls, or are you dependent on third-party updates?

The gap between assumed and actual

Did you find endpoints you didn't know existed? Did you realize your inventory process is more manual than you thought? Did this exercise surface a gap between what you thought your cryptographic posture was and what it actually is? Did you communicate with your vendors and find that they have decided to categorize updating their application to support PQC as 'custom development?'

Organizational readiness

Did you surface this with leadership or your team? What was the reaction — urgency, indifference, or surprise? Does your organization understand the quantum threat timeline, or is this still abstract to them? Do you have budget or roadmap space to address this before 2030?

What changes?

Finally, what happens now? Is this a one-time snapshot, or the start of a living inventory? Were you already planning for migrating to TLS 1.3 and post-quantum cipher suites? What's the first actual change you'll make based on what you documented?

Drop your answers in the comments — no names needed, no specifics required. What I care about is what the inventory surfaced that your security dashboard never would have.

And if you didn't start the inventory this week, that's worth saying too. What got in the way? Lack of access, uncertainty about where to start, or the realization that you'd need help from teams you don't have a relationship with yet? Where it stalls says something real about how cryptographic visibility gets prioritized in security work.

No correct answers here. This is practitioner-to-practitioner. The more honest the responses, the more useful this gets for everyone reading on Monday morning.

See you then.

Discussion