What the first thirty days look like

A Baseline Assessment runs for roughly a calendar month. It ends with an inventory you trust, an exposure report with a defensible score, a standards mapping per asset, and a sequencing recommendation for the first tranche of work. This page describes each week, what you receive, and what your teams have to do.

Thirty days is a planning figure rather than a commitment. Access delays and contested scope are the two things that move it, and both sit on your side of the line. [PLACEHOLDER: contractual timeline and delivery terms for Baseline Assessment]

#The shape of the month

#Week one — scope and access

Kickoff is a working session, not a presentation. We walk the estate boundary line by line and record every exclusion, because an exclusion nobody wrote down becomes a disputed finding in week three. If you prepared the boundary described in What to have ready before we start, this takes under two hours.

The rest of the week is provisioning. Read-only access to repositories, configuration sources and endpoint metadata; workspace structure; single sign-on; notification routing. Access requests that will not be approved get recorded now as blind spots, so that the report states what was never examined.

• Your effort: one two-hour session, plus access approvals. Typically two to four hours of platform-team time.
• Our effort: scope documentation, environment setup, detector configuration for your stack.
• Most common blocker: an access request routed to a team that was not told it was coming.

#Week two — discovery

Detectors run. Each finding is recorded with the detector that produced it, the artefact and revision it was seen in, and the matched evidence. Findings are then de-duplicated into assets, which is where the count usually surprises people: one algorithm choice can appear in a library, a configuration file, a container image and a load-balancer profile, and it is one asset, not four.

Expect the raw finding count to be much larger than the final asset count, and expect the asset count itself to land somewhere you did not predict. In our pilot estate the figure was 42 assets. That is not a benchmark for yours; it is what one bounded estate contained. How discovery finds cryptography explains the mechanics.

#Week three — scoring and the review session

Assets are scored against the published method, tiered, and mapped to the NIST standard that applies to each: FIPS 203 for key establishment, FIPS 204 for general-purpose signatures, FIPS 205 for long-lived or firmware signing. The estate receives an aggregate. In the pilot estate, 36 of the 42 assets were classified vulnerable and the aggregate came out at 75 / 100.

The review session is the most valuable hour of the engagement. We put the highest-scoring findings in front of your engineers with the evidence attached, and they tell us which ones are wrong. Some are: a path is decommissioned, a configuration is overridden downstream, an endpoint is unreachable from outside a management network. Corrections are recorded with a reason, and the reason stays in the record.

1. 01We present each disputed or high-scoring finding with its evidence trail.
2. 02Your engineer confirms, corrects or annotates it.
3. 03Corrections are applied to the asset, not silently to the score.
4. 04The aggregate is recomputed and the change is visible in the record.
5. 05Anything unresolved is carried as an open item rather than quietly dropped.

Scores that survive this session are ones your own engineers have looked at. That matters more than any accuracy figure we publish, and it is why we do not deliver a report without it. What the risk tiers mean and Accuracy, false positives, and how we report error cover the mechanics.

#Week four — performance, sequencing and the readout

Before anything is recommended for scheduling, candidate replacements are measured against the current primitive on representative traffic. Post-quantum key establishment changes handshake sizes and latency, and post-quantum signatures are substantially larger than the ECDSA signatures they replace. Those costs are real and they land on services with existing latency budgets.

Sequencing then orders the work by exposure, data lifetime and remediation difficulty rather than by score alone. A critical finding in a system frozen for a regulatory release is not the first thing you do. Sequencing a migration and Proving the performance impact describe how both parts work, and Hybrid modes and keeping your rollback covers how the first changes are made reversible.

The readout is two sessions: one technical, one for leadership. Both use the same numbers. The deliverables are these.

Cryptographic inventory

Every asset in scope, with provenance and correction history

Exposure report

Per-asset scores, tiers, estate aggregate, and documented exclusions

Standards mapping

The FIPS 203 / 204 / 205 target for each vulnerable asset, with rationale

CBOM

Machine-readable cryptographic bill of materials for the estate in scope

Performance evidence

Before-and-after measurements for each candidate change

First-tranche plan

The sequenced work for the following quarter, with dependencies

Evidence Ledger record

Dated, append-only record of what was found, scored, disputed and corrected

#What thirty days does not produce

• No migrated systems. The first tranche is planned in week four; it is executed over the following quarters.
• No coverage of excluded scope. Whatever you left out stays out, and the report says so.
• No runtime cryptography we could not observe. Algorithms selected dynamically at runtime, and closed appliances that expose no configuration, remain blind spots. See What discovery will not do.
• No regulatory sign-off. The evidence supports your submission. It does not replace your regulator's assessment.

#After the readout

Most organisations do one of three things. Some take the report and run the migration themselves, returning periodically to re-run discovery and confirm the aggregate is moving. Some extend into a Deep Migration Engagement, where sequencing, performance re-measurement and rollout tracking continue alongside their delivery teams. Some stop, having established that their exposure is lower than assumed. All three are legitimate outcomes.

If you continue, the second engagement is where crypto-agility becomes the real deliverable: the aim is an estate where the next algorithm change is a configuration decision rather than a programme. See Designing for crypto-agility. Commercial terms for both engagement shapes are on /pricing.