ekeraThe security resources of a large group, shared among mid-sized companies
Ekera intends to become extremely secure, and brings a mid-sized company the security resources of a large group, shared among its customers. By sharing what they see, they also get the vigilance of a very large information system at the price of a mid-sized one. To make this possible, Ekera commits to spending at least 30% of every subscription on research, quality and security.
A mid-sized company on its own cannot pay every year for an audit, an independent penetration test, a bug bounty programme and a team that analyses attack signals. Pooled across clients, this spending becomes possible. What we already do to stay secure.
The common budget: at least 30% of every subscription
At least 30% of every subscription goes to a common budget. This is not money set aside: it is a commitment on how Ekera spends its revenue. That budget serves all clients, whatever their size: every flaw fixed, every reading error removed, every new trap tested is fixed or tested for everyone.
What the 30% pays for
Mostly people: R&D engineers who improve document reading, the calculation engine and the connectors; security engineers; analysts who validate the signals shared between clients. Then Ekera’s tests, audits, qualified hosting and certifications.
These needs grow with the number of clients: Ekera becomes a more attractive target for an attacker, there are more tools to support, and operators of vital importance (OIV) have stricter requirements. At the start, before subscriptions are enough, the fundraising pays for the first tests.
The more customers there are, the more resources the common budget funds:
- First customers: external penetration test of Ekera and a large-scale test bench, funded first by the fundraising;
- A few dozen customers: annual PASSI audit, regular penetration tests;
- A few hundred customers: permanent bug bounty, ISO 27001 certification, a dedicated security team, SecNumCloud-qualified hosting.
Nothing planned has been done yet. These tests cover Ekera, not customers’ architecture.
What we do to stay secure
These are the measures in place as of 21 October 2026, described at the level of principle; what is only decided or planned is written as such. Technical details are reserved for auditors, under a non-disclosure agreement.
Your data
- Open AI models served in France: customer data is never processed by a US model.
- Each customer is isolated at several levels, in the application and in the database; this isolation is tested by cross-access attempts between two customers.
- Nothing is erased: every change is compensated and traced.
- Decided, being put in place: production hosting in France; one encryption key per customer; at the end of the contract, erasure by destroying that key.
Access and writes in your tools
- Identity comes from your own directory: Ekera does not manage your staff’s passwords.
- Separate roles (read, write, administration), including a role dedicated to sharing signals.
- Read-only by default. Every approved write is signed, single-use, tied to the approved plan and recalculated by Ekera before it is applied.
- The collector installed on your site opens no inbound door: it only connects outwards.
- Uploaded documents (PDF, Word, Excel) are analysed in an isolated space with no network access.
- Decided, being put in place: fresh authentication for every write approval.
Our development
- Code review by a dedicated security role for every sensitive change, then independent review by a role that did not write the code.
- At every change: automated code analysis, secret scanning across the full history, locked and checked dependencies, licence checks.
- Tests that replay every known bypass, including instructions hidden in data; a threat analysis kept up to date.
This website
- Blocking checks before any publication, a strict content security policy, no third party loaded, not even a font.
What comes next
- Planned, not done: external penetration test of Ekera, audit by a PASSI-qualified provider, bug bounty, ISO 27001 certification, SecNumCloud-qualified hosting for operators of vital importance.
Ekera’s security roadmap
Ekera intends to become extremely secure: a tool that reads the map of its customers’ systems must itself meet the standards of a large group. Here are the dated steps; only the first one is done.
| Step | What is done or planned | Status |
|---|---|---|
| Today October 2026 | The measures described above: tested isolation, the customer’s own identity provider, signed writes, a collector with no inbound door, development reviewed and checked at every change, open models served in France | In place |
| Next step 12 to 18 months, funded by the fundraising | External penetration test of Ekera; audit by a PASSI-qualified provider; large-scale test bench (hundreds of fictitious companies) | Planned, not done |
| Then with subscriptions | Permanent bug bounty; ISO 27001 certification of Ekera; SecNumCloud-qualified hosting for operators of vital importance (OIV); a dedicated security team | Planned, not done |
What these tests test
The penetration tests, audits and certifications in this roadmap cover Ekera itself: its software, its hosting, its organisation. They do not cover our customers’ architecture.
Ekera does not certify a customer’s architecture and does not replace its penetration tests: it targets them, by showing what matters most, and tracks exposure between two campaigns. We will never tell a customer that it is secure or that it no longer needs to test.
Every client strengthens the others
A community navigation app works like this: every driver who reports a traffic jam helps all the others. Ekera applies the same idea to information-system security: when a client spots an attack, an exploited flaw or an incident, the other clients receive an alert and a protection.
A mid-sized company on its own sees few attacks. Pooled, the observations of dozens then hundreds of companies give each of them the vigilance of a large group. Ekera does not promise guaranteed security, but shared vigilance.
Signals that cannot be poisoned
A false signal could mislead the whole network. That is why every signal passes four barriers before it is shared:
- Four-eyes validation at the client: two people at the client validate the signal.
- Client consent: only a user with the “sharing” role can authorise it to be sent.
- Review by an Ekera analyst, then the signal is signed.
- Aggregated release only: a signal is released only once it has been observed in at least five companies.
No raw data leaves the client: only the validated, anonymised signal travels. The common budget also pays for the analysts who review these signals.
Who tests what: three areas
Ekera does not replace cybersecurity firms: it works alongside them, in three distinct areas.
| Area | What is checked | Who checks it |
|---|---|---|
| Accuracy of the AI | Does Ekera read the documents correctly? Are its figures right? | Ekera, with a test bench of fictitious companies, like an AI lab. This is its own strength. |
| Security of the Ekera product | Does the Ekera software resist attacks? | Ekera, through secure development already in place. An outside view is planned, funded first by the fundraising and then by the common budget: penetration test, PASSI audit, ISO 27001 (roadmap). |
| Security of the client’s IS | Does the client’s IS resist a real attack? | PASSI-qualified providers, who remain essential. Ekera never performs penetration tests. |
Ekera never enters the client’s IS. It reads exports and documents read-only, then calculates what an attack would stop and what it would cost. PASSI providers become partners, not competitors.
Ekera and penetration testing
Ekera makes penetration tests better targeted, without replacing them. We do not publish a savings percentage: it depends on each IS and has not been measured yet.
- Target: Ekera’s map shows single points of failure and the attack paths that would cost the most. The provider tests what matters first.
- Avoid: what has no business impact does not need to be tested first. The testing budget goes where it protects most.
- Close the loop: the provider’s findings come back into Ekera’s map and figures. The client sees what each fix protects, in euros.
- Follow up between campaigns: a penetration test is a snapshot. Ekera follows the changes and flags what deserves a new test.
What we offer partners
To PASSI providers: better-targeted engagements, prepared by Ekera’s map and figures; findings that keep their value after the engagement, because they feed the client’s map; and engagements on the Ekera product itself, funded by the common budget.
To cybersecurity firms and managed service providers: a client who knows what an attack would cost and which works would reduce it. Decisions move faster.
To insurers: verified indicators, with the insured’s consent. The product for insurers.
Assumptions and limits
- No PASSI audit, no external penetration test and no ISO 27001 certification has been carried out to date. The first ones are funded by the fundraising, the next ones by the common budget.
- These tests cover Ekera itself. Ekera does not certify a client’s architecture, does not replace its penetration tests and never tells it that it no longer needs to test.
- The signal network is only valuable with enough clients. Below five companies, no signal is released.
- Shared vigilance reduces risk; it does not remove it.
- Ekera does not perform penetration tests and does not enter the client’s IS. It replaces neither a PASSI provider nor a security team.
See also: our research and development, and shared security on the home page.