R2PQCryptographic assurance

EVIDENCE BEFORE ASSURANCE

Your customer asked.
Make your answer
defensible.

Cryptographic evidence assessments for software suppliers facing a real customer request—and a deadline.

We assess one application or release, review what the evidence supports, and help you respond to questions about cryptographic inventory, CBOM, encryption and PQC readiness.

Discuss a cryptographic request See an example finding

One application or release. Agreed scope. Explicit unknowns.
An evidence assessment—not certification.

BUILT AROUND THE REQUEST

  • Cryptographic inventory
  • CBOM
  • Encryption details
  • PQC readiness

01 / THE GAP

You have fragments.
Your customer needs
a supported answer.

Engineering has source indicators. Vendors have documentation. Operations has configuration. A questionnaire turns those fragments into a claim your company has to stand behind.

We connect the available material to the specific questions being asked—and identify where it does not establish an answer.

SourceDependenciesConfigurationExisting claims

Source observations do not, by themselves, establish deployed behavior or complete cryptographic coverage.

02 / THE DELIVERABLES

One bounded assessment.
A usable evidence package.

Built around one application or release and the actual request you need to answer. Scope, access and output formats are agreed before work begins.

01 Scope & coverage record

The application, release, supplied materials, questions, exclusions and collection limits.

02 Reviewed cryptographic inventory

Algorithms, key-related details and dependencies where established, linked to source observations. CBOM output where supported by the evidence and agreed format.

03 Findings & next actions

Supported and unsupported claims, explicit unknowns, and prioritized investigation or migration actions.

04 Customer response material

A scoped answer your team can review and send, with supporting references and one bounded clarification round.

05 Integrity & verification receipt

A record of delivered artifacts and the integrity checks applied. It establishes what was checked—not the truth of every claim.

03 / WHAT A DEFENSIBLE ANSWER LOOKS LIKE

A claim is only as useful
as its boundaries.

Evidence, interpretation and review stay distinguishable. This fictional example shows how a broad claim becomes a precise customer response.

ILLUSTRATIVE FINDING · CR-014API SERVICE / RELEASE 2.4

CLAIM UNDER REVIEW

“All application traffic uses approved cryptography.”

Partially supported — the broad claim is not established for the stated scope

01

Source / observation

The supplied outbound-client configuration sets a minimum TLS version of 1.2.

Source: client-config.yml · lines 18–21 · release 2.4 snapshot

Inspect the illustrative source
# Illustrative configuration only
outbound_client:
  tls:
    minimum_version: "1.2"

This record describes supplied configuration, not a runtime observation.

02

Deterministic check

The field exists and its literal value equals 1.2.

Example check CFG-01 v1 · supplied file only · result: passed

A passed field check does not establish negotiated protocols, cipher suites or policy approval.

03

Analyst / AI interpretation

The configuration supports a narrower statement about this client. It does not substantiate “all traffic” or “approved cryptography.”

Origin: illustrative analyst interpretation · AI contribution: none in this example

04

Unknown / not evaluated

Deployment overrides, other traffic paths, negotiated cipher suites and the customer’s approval criteria were not evaluated.

Next evidence: deployed configuration, relevant runtime records and the applicable policy.

05

Human review

Disposition: narrow the response and request additional evidence before making the broader claim.

Illustrative reviewer: assessment lead · review scope: this finding

06

Verification result

The example field check passed. The broad claim remains unverified.

An artifact-integrity receipt can establish a file match; it cannot establish runtime security.

THE SCOPED RESPONSE

“The supplied release configuration specifies a minimum of TLS 1.2 for this outbound client. Deployed behavior, other traffic paths and compliance with your approval criteria have not been established.”

RECOMMENDED NEXT ACTION

Obtain the deployed configuration for this release and the customer’s stated approval criteria, then re-state the claim at the scope that evidence supports. Until then, the narrower response above is the defensible answer.

Fictional demonstration. No customer data, live analysis or actual verification is represented.

04 / HOW AN ENGAGEMENT RUNS

Nothing is collected
before the scope is agreed.

The order is deliberate. Evidence requirements, handling and transfer method are settled in writing before any assessment material changes hands.

  1. 01 Show the request

    Send the type of request you received, who asked for it and your deadline. No technical evidence at this stage.

  2. 02 Fit check

    We determine whether the request fits a bounded assessment of one application or release — or tell you it does not.

  3. 03 Agreement

    Application and release, components and environments in scope, exclusions, the customer question being answered, evidence sources, handling and transfer method, review expectations, deliverables and price are agreed in writing.

GATE No assessment material is collected before this point.

  1. 04 Evidence collection

    Only the agreed material, by the agreed method. Analysis under your own control is preferred where it is feasible.

  2. 05 Assessment and review

    Defined checks run against the collected material. Material conclusions go to human review before they are written down.

  3. 06 Delivery

    Deliverables, explicit unknowns, and the limitations that apply to each conclusion.

  4. 07 Clarification

    One bounded clarification round on what was delivered.

Steps 01–03 involve no assessment material. If the request does not fit a bounded assessment, we say so at step 02 rather than scoping work around it. A later release or a material change is a new evidence state — earlier conclusions are not assumed to carry forward.

05 / HOW CONCLUSIONS ARE REVIEWED

Every material finding
carries its own origin.

Detection, deterministic checks, interpretation and human judgement are recorded separately, in this order. Section 03 shows the same structure applied to a single claim.

  1. Source artifact
  2. Observation
  3. Deterministic check
  4. Interpretation
  5. Human review
  6. Unknown / limitation
  7. Recommended action

Who reviews

Founder & Assessment Lead

Assessments are reviewed by the founder and assessment lead. Material conclusions are based on documented evidence, defined checks and explicit scope. Where specialist validation is required beyond the engagement’s evidence or competence, the conclusion remains unresolved rather than being inferred.

This is founder-led technical review. It is not independent assurance, accredited review, certification, a third-party audit or a licensed cryptographic assessment.

What each stage can establish

Automated detection
Produces candidate observations. A candidate is not a finding, and absence of a candidate is not absence of the thing.
Deterministic checks
Establish only the defined technical condition, against the supplied input, at the recorded time. Method, version, scope and limitations are recorded with the result.
AI assistance
May help interpret or draft. It is not evidence, it is identified where it is used, and it does not decide anything material.
Human review
The founder and assessment lead decide whether a conclusion is supported. Review is not the same as approval, and approval is not the same as technical truth.
Specialist validation
Where the engagement’s evidence or competence is insufficient, the conclusion stays unresolved and the specialist input required is named. It is not inferred.
Unsupported conclusions
Remain inconclusive or not evaluated, and are reported that way rather than being resolved by inference.
Scope and exclusions
Are part of the deliverable, not a preamble to it. A conclusion travels with the boundary it was established within.

How a conclusion is dispositioned

Supported
The evidence establishes the claim within the stated scope.
Partially supported
Part of the claim is established; the remainder is not.
Contradicted
The evidence is inconsistent with the claim as stated.
Inconclusive
The evidence does not settle the question in either direction.
Not evaluated
Outside the agreed scope, or no evidence was collected for it.
Needs further evidence
A specific additional artifact would settle it, and that artifact is named.

“Verified” is used only where a named verification procedure actually passed, inside its own scope and time. “Secure”, “compliant” and “PQC ready” are not used as states of a system. This site claims no accreditation, no certification authority and no independent assurance standing.

06 / WHEN IT FITS

Start with a request.
Not a quantum countdown.

Post-quantum migration planning starts with knowing what cryptography is present, what depends on it and what remains unknown. Discovery informs that work; it does not establish readiness on its own.

PQC means post-quantum cryptography. CBOM means cryptographic bill of materials.

A useful fit

  • You supply software and have a customer, procurement, audit or partner request.
  • You can identify one application or release and make relevant material available.
  • You need a reviewed answer with scope and limitations your team can explain.

Typically an engineering or security team at a software supplier with roughly 50–500 employees.

Probably not the right first purchase

You have no specific question yet, cannot supply relevant material, or need certification or discovery across your entire enterprise.

CLEAR BOUNDARIES

What this assessment
does not claim.

  • No certification or accreditation
  • No penetration test
  • No complete enterprise inventory
  • No complete runtime visibility
  • No security or PQC-readiness guarantee
  • No automated compliance

AI output is not evidence. Any assurance statement is limited to the questions, materials, methods and release actually assessed.

07 / INFORMATION HANDLING

Send the question first.
Not the evidence.

These are the handling expectations for an engagement. Where an arrangement is not yet operationally established, it is stated below as a requirement to be agreed — not as a control that already exists.

The first inquiry carries no evidence

Name, company, business email, the type of request you received, and a deadline. Nothing technical is needed to determine fit.

Do not send secrets through this path

Source code, credentials, private keys, cryptographic key material, internal configuration, customer-confidential material and regulated data do not belong in a public inquiry form or in an unplanned email.

Evidence follows scope, not the reverse

Assessment material is collected only after scope, exclusions and a transfer method are agreed. That is step 04 of the sequence above.

PROPOSED REQUIREMENT Transfer method agreed in writing

No transfer mechanism is offered, operated or implied by this site today. One must be agreed before any evidence moves.

PROPOSED REQUIREMENT Local or customer-controlled analysis preferred

Where feasible, analysis should run under your control rather than requiring material to leave your environment. Feasibility depends on the request and is settled at step 03.

PROPOSED REQUIREMENT Retention and deletion agreed before acceptance

No retention period, deletion process or storage arrangement is currently established. These must be agreed before sensitive evidence is accepted.

What this site does with your information

This site has no backend, no database, no analytics and no cookies. The inquiry form runs entirely in your browser: nothing is submitted or stored here, and no inquiry reaches us until you choose to send the prepared email yourself.

Email is the temporary inquiry mechanism while a dedicated intake is built. Once you email us, your message sits in an ordinary mailbox. We claim no encryption at rest, no deletion timescale, no secure vault and no certification of any kind. Retention and deletion for sensitive material are agreed before such material is accepted — which is why the initial inquiry carries none.

The section above states engagement expectations, not a legal privacy programme. A privacy notice and engagement terms are required before this site is published publicly.

BRING THE QUESTION

Tell us what your customer
is asking for.

The first message carries no technical material — only the request you received, who asked for it, and when you have to answer. We reply on whether a bounded assessment fits.

  • No evidence at this stage
  • A fit check before any scoping
  • Scope agreed before anything is collected

Read the information-handling expectations

Or email contact@r2pq.dev directly.

Start the conversation

Do not include technical evidence in this form. No source code, credentials, private keys, cryptographic key material, internal configuration, customer-confidential material or regulated data. Evidence is collected later, by a method agreed in writing.

All fields are required unless marked optional.

Used only to reply about this request.

What they asked for

A product or release name is enough.

Non-sensitive context only. No configuration, keys, code or customer data.

Nothing is sent automatically. This prepares a summary in your browser. You then hand it off by email, from your own mail app, when you choose to. This site has no backend and stores nothing.