GitHub
Open source · MIT · Laravel 13

Tenant isolation that holds. An audit log that proves.

The ef.next Security Framework gives Laravel applications three properties that regulated environments demand: guaranteed tenant isolation, a tamper-evident audit log and stable public IDs. Open source under MIT, with signed releases and a software bill of materials. Built by ef.next as its own reference case for the Cyber Resilience Act.

Repository on GitHub How we meet the CRA

Pre-release 1.0.0-beta.2 of 28 October 2026. Not a product, nothing to buy: free to use, source open.

Three tenants in separate areas of one application; a reference across the boundary is refused. Below, a chained audit log bound to an anchor outside the application. Application · Database Tenant A inv_7f3k9z… inv_2q8mx4… usr_c1bt5r… Tenant B inv_9h2vp7… inv_k4d8sw… usr_m6e3qa… Tenant C inv_x3n7ft… inv_r8w2jc… usr_t5y9kd… Audit log · chained and signed #1a91f 3e… #27c0d b2… #3e4a8 91… #452f7 6c… External anchor immutable
Separated tenants, refused cross-references, a chained log with an anchor outside the database.
  • Fail-closed: refuses instead of guessing
  • Signed releases with SBOM
  • Vulnerabilities: acknowledged within two business days
  • MIT licence, free to use
The challenge

Four questions software in regulated environments has to answer.

Products with digital elements, platforms serving several customers, processes with mandatory approvals: at some point an auditor, a customer or an authority asks for evidence. Then what counts is not what the software was supposed to do, but what it can prove.

  • Several customers on one platform. Who guarantees the data does not mix?

    In most applications, separation rests on discipline: on a filter condition that has to appear in every query. One forgotten filter is enough for one customer to see another's data. An audit wants that ruled out, not promised.

    Tenant isolation
  • Who did what, and when? And is the log still intact?

    A log that lives in the same database as the data can be changed by anyone with access. It only proves that someone wrote something. Not that it has remained unchanged since.

    Traceability
  • Our IDs appear in URLs and reports. And they can be enumerated.

    Sequential numbers reveal how many records exist and invite trying the next one. References that change during a migration make old reports and interfaces worthless.

    Public identifiers
  • The Cyber Resilience Act demands evidence. Where do we start?

    Software bill of materials, vulnerability process, secure updates: from December 2027 the requirements apply in full, the reporting obligations already since September 2026. Evidence is not produced after the fact. It has to be part of the release process.

    Cyber Resilience Act
Our approach

Refuse instead of guessing. Prove instead of promising.

The framework does not rely on discipline. It makes the three properties a precondition for the application to run at all, and for every commitment it states what it depends on.

  1. 01
    Fail-closedWhatever wants to run without a tenant context does not run. A mistake becomes a failed test, not a data leak.
  2. 02
    The database helpsTriggers reject changes to the log, composite keys prevent foreign references. That holds for raw SQL too, and for administrators.
  3. 03
    Keys and anchors outsideEntries are signed with keys that do not live in the database and are anchored regularly in immutable storage. Whoever controls the database does not control the chain.
  4. 04
    Commitments with conditionsEvery guarantee is documented together with its precondition. A self-check inspects the installation and fails loudly when one is missing.
  5. 05
    Open and verifiableMIT licence, signed releases, software bill of materials, documented limits. What we claim, you can read and recompute.
Comparison: without the framework, a query without a tenant returns every record of every customer. With the framework, the same query is refused. Without the framework SELECT * FROM invoices no tenant set Tenant A · inv_7f3k9z… Tenant B · inv_9h2vp7… Tenant C · inv_x3n7ft… Tenant A · inv_2q8mx4… Tenant B · inv_k4d8sw… returns everything – from every customer With the framework SELECT * FROM invoices no tenant set Query refused Exception · test fails no record leaves the application
The same query without a tenant context: without the framework it returns everything, with the framework it fails loudly.
The framework

Three components, one package.

For Laravel 13 on PHP 8.3 to 8.5, with PostgreSQL, MySQL or MariaDB. Installed together, one repository, one release. The details are in the documentation in the repository; this is the picture in broad strokes.

Tenant isolation

efnext/security-tenant

Resolves the tenant of a request, a background job or a command and carries it through the whole processing chain. Queries on tenant-owned data without a tenant are refused. Memberships and roles are enforced; references across tenant boundaries fail in the database itself.

Audit log

efnext/security-audit

Writes every relevant event into a chain per tenant: numbered in sequence, linked to the hash of its predecessor, signed. The database refuses updates and deletes. Anchors in external storage and a verification run make every deviation visible.

Public IDs

efnext/security-addressing

Issues readable, unguessable identifiers such as dom_7f3k9zq2m4x8c1bt and global object IDs for references across system boundaries. They stay stable, reveal no database keys and cannot be enumerated.

Commitments and their conditions

What holds, and what it depends on.

Security commitments are only worth the conditions behind them. That is why every commitment is documented with its precondition, and a self-check verifies it in the running installation.

  • A tenant-owned query never runs without a tenant.The model is marked as tenant-owned. Without a context the query aborts with an exception.
  • A row cannot reference another tenant's row.Composite foreign keys from the framework's migrations. The database enforces them for raw SQL too.
  • Audit entries cannot be changed or removed.The framework's database triggers on PostgreSQL 14 to 17, MySQL 8.0/8.4 or MariaDB 10.11 to 11.
  • Tampering with the chain is detectable.Signing keys outside the database and external anchors in immutable storage.
  • Business change and log entry are committed together.The change runs inside the framework's audit transaction.
  • Background jobs run in the tenant that queued them.The framework's queue integration; commands run through the tenant runner.
What it does not do

Limits, stated openly.

  • It does not encrypt data at rest and does not make an insecure application secure. It makes two kinds of failure impossible to overlook: missing isolation and a modified log.
  • Public IDs prevent enumeration. They do not replace authorisation checks.
  • Whatever bypasses the framework's interfaces, such as raw SQL or deliberately disabled safeguards, lies outside the commitments. The repository names these limits.
  • Pre-release: the interfaces may change before 1.0.0, and every change is listed in the changelog. An independent third-party security audit has not been completed yet.
Use and documentation

Self-hosting is possible.

Whoever uses the framework runs it themselves. Installation, operation, key rotation and incident handling are documented in the repository; an example application shows the integration step by step. The documentation is written in English, and the user and operator pages also exist there in German and Swedish.

For teams working with AI coding agents, the repository ships an integration contract so that agents know the rules for tenant context and audit logging before they write code.

Documentation in the repository

Cyber Resilience Act

What the CRA demands, and how we met it in our own code.

The Cyber Resilience Act applies to products with digital elements and requires manufacturers to provide evidence across the whole lifecycle: secure development, a software bill of materials, vulnerability handling, secure updates. ef.next sets up such evidence for customers. To do that credibly, our own framework goes through the same process. What we ask of customers, we show in our own code.

11 Sep 2026Reporting obligations

Reporting of actively exploited vulnerabilities

Manufacturers must report actively exploited vulnerabilities and severe incidents. That requires a reporting channel that is defined beforehand.

In force
11 Dec 2027Full application

All requirements apply

Including technical documentation, conformity assessment and CE marking for products with digital elements.

13 months left
Evidence chain of a release: signed tag, quality gates, artefacts with bill of materials and checksums, published release. 1 · Signed tag git tag -s v1.0.0 signature verified against trust root in the repository 2 · Gates Tests · analysis 5 databases PHP 8.3 · 8.4 · 8.5 mutation ≥ 70 % 3 · Artefacts Archive + SBOM SPDX · CycloneDX SHA256SUMS provenance 4 · Release v1.0.0-beta.2 GitHub release Packagist traceable Every stage fails loudly: no artefact without a valid signature, no release with a red gate.
The evidence chain of every release. Nothing is built by hand; every artefact traces back to the tag, the tag to a key.
  • Integrity of software and updatesEvery release is a signed git tag. The release process verifies the signature against a trust root committed in the repository before any artefact is built. The archive, checksums and a build provenance attestation signed by GitHub ship alongside.Releases
  • Software bill of materials (SBOM)With every release, a bill of materials of the runtime dependencies in SPDX and CycloneDX, generated automatically from the tagged state. Exactly what customers and auditors ask manufacturers for.Release process
  • Vulnerability handling and reporting channelSECURITY.md defines how to report (security@ef-next.com, no public issues), what is in scope, and that reports are acknowledged within two business days. Only the latest minor release receives fixes.SECURITY.md
  • Secure defaultsFail-closed is the default. In production the application refuses to boot when signing keys are missing or tamper protection is switched off, and a self-check verifies every precondition of the commitments.Production guide
  • Logging and traceabilityThe audit log records who did what and when, and makes later changes detectable. The basis for incident analysis and for evidence towards customers and authorities.Auditing guide
  • Checks before every releaseNo release while a gate is red: tests on every supported combination of PHP version and database, static analysis, mutation testing with a minimum threshold, and a dependency audit for known vulnerabilities.Quality gates
  • Threat model and limitsA threat model, a list of what the framework does not do, and runbooks for key rotation and incident response are part of the documentation. Evidence is only worth the limits it names.Threat model

In context: the framework does not make a product CRA-compliant by itself. A product's conformity remains the manufacturer's responsibility. The framework provides building blocks for isolation and traceability and shows, on itself, what release evidence can look like.

Licence and use

MIT. Free to use, open to inspect.

The framework is released under the MIT licence, copyright 2026 ef.next AB. You may use, modify and redistribute it, commercially too. Self-hosting is possible; whoever runs it carries operation and configuration themselves, as described in the repository.

ef.next does not sell the framework. It is the technical foundation of ef.next's own software and, at the same time, its own reference case for the Cyber Resilience Act.

Who is behind it

Developed and operated by ef.next AB.

ef.next delivers quality, product security and compliance to manufacturing companies as verified results. The framework is the technical foundation for that. More about the company at ef-next.com.

  • Enrico EngelProduct, software architecture, AI, automation. Responsible for the framework.
  • Stephan CarlAudit, quality management, management systems.
  • Companyef.next AB, Sweden
  • Questionsinfo@ef-next.com
Latest

News about the framework.

Releases, notes and articles. Posts appear in the language they were written in.

  • 1.0.0-beta.2: first public releaseRelease

    The framework is public on GitHub, built for Laravel 13 on PHP 8.3 to 8.5. The release is a signed tag with an archive, a software bill of materials in SPDX and CycloneDX, checksums and a provenance attestation. The interfaces may still change before 1.0.0.

    Release on GitHub

  • Package available on PackagistNote

    The package efnext/security-framework is published on Packagist and can be installed like any other Composer package. Installation is described in the README.

    Package on Packagist

All news

Contact

Questions about the framework? Write to us.

For questions about use, limits or working together, an e-mail is enough. We answer in English, German or Swedish, usually within two business days.

We usually answer within two business days.

Your details are used only to answer your enquiry and are delivered by e-mail to info@ef-next.com. Details in the privacy policy.

Directly by e-mail

info@ef-next.com

Questions about use, limits and working together. Also for press and partners.

Report a vulnerability

security@ef-next.com

Not as a public issue, please. Process and scope are in SECURITY.md; acknowledged within two business days.

ef.next AB

Sweden. We answer in English, German or Swedish.