Working with Redlings

How security assessments work with Redlings.

You hand us an unreleased, confidential product, source code, firmware, architecture, credentials, devices. This page describes concretely how we handle it: before the assessment, during testing, in the report and afterwards.

PRODUCT / QUESTION NDA if required TECHNISCHES SCOPING ACCESS / DEVICES / CODE ASSESSMENT REPORT & REVIEW RETEST
WHO WORKS ON YOUR PROJECT

You work with the person whose name is on the report.

Redlings is a senior-led boutique, founded and led by Dr. Ewan Fleischmann. Every assessment is led by an experienced senior consultant, from scoping to final review. There is no junior staffing and no intermediate layer between you and the tester.

For specific domains, such as protocol reverse engineering or side-channel analysis, we bring in vetted specialists. Involvement is documented in the scope and coordinated with you.

STARTING POINT

A short technical description is enough to start.

Useful initial information, nothing more is needed; detailed scoping follows with a technical person:

  • Product / platform
  • High-level architecture
  • Lifecycle stage
  • Interfaces/components in scope
  • What changed or what is causing concern
  • Expected timing
  • NDA requirement
Before the assessment

Framework first, material second.

Nothing sensitive is shared before NDA and scope are in place.

NDA

An NDA can be signed before architecture, source code or findings are shared, using your template if preferred.

Scoping with engineering

Architecture, trust boundaries and attacker assumptions are defined together with your engineering team, not through a form.

Access and environments

Required access, test devices and test environments are defined before the engagement starts. Production systems are only involved by explicit agreement.

Hardware shipment

If devices are required: shipping address and procedure are communicated after NDA and documented in the scope.

Point of contact

One technical contact on each side, decisions during testing do not need a management layer.

Handling sensitive material

Source code, firmware, credentials, data.

How material reaches us and who works with it.

Secure transfer

Source code, firmware images and other sensitive artifacts are never sent by normal email. After contact, we provide an appropriate secure transfer method.

Credentials

Credentials are used only for the agreed purpose, stored encrypted and deleted or revoked after project completion.

Customer data

Production and personal data are avoided where possible. Where test data is needed, synthetic data is agreed or handling is explicitly defined.

Access

Access to your material is limited to the named project team members. No disclosure to third parties, no use for other purposes.

Storage

Project material is stored separately from general operations. Deletion or return after completion is agreed and documented.

Devices

Your hardware stays your hardware.

Shipment and labeling

Devices are shipped by agreement, labeled uniquely and documented on receipt.

Storage

Devices are stored locked and, where agreed, without network connectivity.

Destructive testing

Interventions that may damage devices (e.g. chip removal, fault injection) happen only with explicit written approval.

Return

After completion, devices are returned, including final documentation of device condition.

During testing

No surprises mid-engagement.

Communication

An agreed channel and regular status, you always know where the engagement stands.

Critical-finding escalation

A critical finding with immediate risk is reported at once, not first in the report.

Production-near systems

Testing against production-near systems happens strictly within the agreed rules of engagement.

Remote and onsite

Remote and onsite execution are defined in the scope, typically remote, with device work in the lab.

Reporting

Technically reproducible, not decorative.

Findings

Every finding is documented reproducibly: attack path, technical impact, evidence.

Severity and impact

Rated by technical impact, with reasoning, not just a score.

Remediation context

Fix direction per finding, including variants that share the same root cause.

Closing briefing

A technical walkthrough with your engineering team; open questions are resolved in conversation.

Afterwards

Retest, deletion, return, questions.

Retest

Fixed findings are verified against the original attack path, within the engagement or as a follow-up.

Retention and deletion

Scope and timing of project material deletion are agreed and confirmed.

Hardware return

Devices are returned in full.

Follow-up questions

Technical questions about findings and fixes are welcome after completion.

ACCESS MODELS

We work with the evidence the product exposes.

Not every input is required, scope and architecture determine what is needed.

Input / access Typical use
Physical devices Hardware, debug, boot, firmware, wireless
Firmware images Extraction, update, reverse engineering
Source code Focused security-critical implementation review
Test environment Application/API/backend testing
Mobile/desktop clients Product control paths
Protocol captures Protocol reconstruction and testing
Architecture docs Trust boundaries and scope
Vulnerability report / PoC Reproduction and exploitability
VULNERABILITY RESPONSE

If the problem already exists, start with the report.

For reported or suspected product vulnerabilities, work can begin with reproduction, exploitability, affected versions, root cause and remediation verification.

A Response Retainer can establish contacts, product context and the commercial working relationship before the next urgent report arrives.

View Vulnerability Response →

KNOWLEDGE TRANSFER

Hand the findings to the team that fixes them.

The report goes to the security lead, but it is implemented by the developers who write the firmware. Following an assessment, we turn your findings into a workshop for your engineering team: every weakness, how it came about, how to fix it, hands-on, on real hardware.

1–2 days · 6–10 participants · German or English · at your site or in Mannheim · documented attendance record for IEC 62443-4-1 and CRA documentation

Request a workshop →

FAQ

Common questions before first contact.

Do we need to know which service we need?

No. Start with the product and the question, we define the technical scope together.

Can an NDA be signed first?

Yes. NDA and commercial setup can come before any detailed exchange.

Do you need source code?

Not necessarily. Source code is one possible input, assessments also run with devices, firmware images, test environments and documentation.

Can you test a product still in development?

Yes. Development stages are a typical starting point; relevant limitations are documented in the scope.

Can we send physical devices?

Yes, shipping address and procedure after NDA, documented in the scope.

Do you provide retesting?

Yes. Fixed findings are verified against the original attack path.

Can you work on-site?

Remote and onsite shares are defined in the scope, typically remote, with device work in the lab.

Do you certify CRA / IEC 62443?

No. Technical testing and evidence, certification and legal assessment are outside the scope.

Secure material

For a first conversation you do not need to send any material, the product, its environment and two sentences are enough for scoping. Please do not send source code, credentials or unreleased security information unencrypted by email; after an NDA we provide an encrypted transfer channel. Details on the contact page.

Get in touch   Responsible Disclosure

Ready to show us your product?

Tell us briefly what you need. We usually reply within one business day.

NDA first if required.