EmberKat

Experience

Fourteen years of practice behind a brand that is new.

EmberKat is a new name. The experience behind it is not — fourteen years across engineering, infrastructure, architecture, security and technical leadership.

Discuss the work
A practitioner adds a dependency note among worn architecture sketches, medical imaging films and release evidence accumulated through regulated software work.

Attribution policy

Whose work this was

Work done for an employer, or under another firm's contract, is not presented as EmberKat delivery.

How the practice got here

Four steps, one of which was not planned

  1. 01 / Building

    Built regulated medical imaging software as a developer.

    Regulated medical imaging software used in clinical settings — DICOM and its failure modes learned from implementing them, not from a specification summary.

  2. 02 / National scale

    Delivered a national-scale medical imaging archive.

    A state-level DICOM archive, taken through national registration and state audit review — the level of scrutiny where an architectural shortcut becomes someone else’s problem for a decade. The same pattern was repeated afterwards in neighbouring national programmes; I worked on those too, as an employee of a different company and on a different cluster.

  3. 03 / The turn

    A tier-one buyer’s security requirements created the role.

    A tier-one European enterprise buyer evaluated the product for a national deployment. Its requirements — per-product security reporting, security controls inside the delivery process — went beyond what the vendor could answer at the time. The response was to build a dedicated security engineering function.

  4. 04 / Now

    Product security and secure delivery, from the vendor side.

    Release security documentation, dependency and CVE hygiene, internal security, and the security questions customers ask before they sign. Including coordinated vulnerability disclosure: intake from a major disclosure programme, triage, fix, release, and the customer questions that follow once a national authority publishes an advisory.

In 2023 a demanding buyer asked for security reporting per product and security controls inside the delivery process. That is close to what the Cyber Resilience Act begins requiring of manufacturers on 11 September 2026. The capability was built because a customer insisted, before the law did.

Experience areas

Technical and leadership scope

  1. 01

    Medical imaging: DICOM, PACS architecture and clinical imaging workflow

  2. 02

    Product security: secure delivery, SBOM, dependency and CVE triage

  3. 03

    Coordinated vulnerability disclosure from the vendor side

  4. 04

    Regulatory technical evidence: IEC 62304 and 81001-5-1 territory, state audit review

  5. 05

    Infrastructure, platform and DevOps, including hardware and on-premise realities

  6. 06

    Architecture assessment and root-cause analysis across complex systems

  7. 07

    EU-funded research and development projects

  8. 08

    Delivery across Western, Northern and Central European markets

Public evidence

Engagement records

Published only where the commissioning client has approved it and cannot be identified from what is written. Client names and references are not published at all.

Contact

Discuss relevant experience and scope