October 2025, Paris. Thieves dressed as construction workers break into the Louvre and steal eight pieces of the French Crown Jewels valued at approximately €88 million.
The robbery took place in broad daylight, and lasted less than eight minutes. As of the time of writing, only one of the jewels was recovered, a crown belonging to Napoleon III's wife Eugénie, which the thieves dropped in the street as they fled.
The investigation into the Louvre heist uncovered startling cybersecurity weaknesses at the museum. According to multiple security reports, a 2014 audit by France’s National Cybersecurity Agency (ANSSI) identified serious flaws in the museum’s digital infrastructure, including the fact that the password protecting a core surveillance system was simply “Louvre,” and that several monitoring devices were running outdated or unsupported software.
Adding analytics to your app - security features to keep in mind
The thieves in the Louvre heist didn’t force their way in; they blended in as construction workers, exploiting assumed legitimacy.
Your data is like the crown jewels at the Louvre. The analytics solution you embed in your applications needs to choose who can access and modify it, who can only view it, and who has no access at all. Embedded analytics designed with a safety-first approach can provide flexibility of access aligned with your business requirements while keeping your data safe.
Just like the museum failed to verify the "workers" entering its halls, software vendors often fail to secure third-party integrations. This is why the NIS2 Directive now mandates that organizations rigorously assess the cybersecurity risks “in their supply chains and those of their suppliers and subcontractors".

Embedded analytics should be treated as a privileged participant. It runs in your application, affects sensitive data, and is exposed to your users, which means it must be governed like any other critical supplier.
Why Auditing is so Important
Once the thieves fled with the jewels, the immediate challenge for the police was piecing together the timeline of the eight minutes the thieves spent inside.
In the software industry, this forensic capability is a regulatory mandate. Think of Google Docs. When you are creating a document, every change is logged in version history.
Under DORA, financial-sector organizations and their software providers must be able to "reconstruct exactly what happened before and during an incident". To prevent fines and ransom, you should learn from previous attacks.

The resilience imperative
Of the eight stolen pieces, only one - a crown belonging to Empress Eugénie - was recovered, and only because the thieves were clumsy.
In the digital context, relying on luck for data recovery is unacceptable, including by law. EU legislation like the Digital Operational Resilience Act (DORA), for example, dictates that software must be "recoverable", and requires organizations to prove they can "stay operational even when their digital systems fail" or are attacked.
In other words, true resilience is twofold - not just preventing security breaches from happening, but also recovering fully and quickly when they do. The analytics component of your app is only part of that resilience. Another is the database the analytics tool is querying. This is why databases like InterBase focus so much on security and things like point-in-time recovery, encryption, and journaling.
Multi-tenancy
In customer-facing and embedded analytics, multi-tenancy is critical.
Secure platforms isolate organizations logically so each tenant has its own users, content, and branding, even while sharing the same underlying infrastructure.
This approach prevents data leakage between customers while keeping operations scalable. Platforms such as Yellowfin follow this model, allowing each organization to operate independently without duplicating environments.
Yellowfin’s approach to security
Yellowfin is designed as an embedded-first analytics platform. This means its security model is built to sit inside another application (your product) without creating friction or vulnerabilities.

Governance & role-based access control
Yellowfin uses a granular permission model that separates Content Security from Functional Security.
- Functional Security: Controls what a user can do (e.g., Can they create reports? Can they export data? Can they admin users?).
- Content Security: Controls what a user can see (e.g., access to specific dashboards, folders, or data categories).
This matters because in a custom build, developers often hard-code permissions. Yellowfin allows non-technical admins to manage these roles via a UI, reducing engineering bottlenecks.
Native multi-tenancy
This is Yellowfin's strongest security asset. It allows a single instance of the software to serve multiple distinct customers (tenants) while keeping their data separated.
Each tenant can also have their own physical database, and Yellowfin dynamically routes the connection based on who logs in.
Finally, two users looking at the exact same report can see different data based on their permissions. For example, a Sales Manager sees all regional sales, while a Rep only sees their own.
Get started with Yellowfin
The lessons of the Louvre are brutal: complacency, outdated systems and practices, and an “it can never happen to us” attitude led to the loss of priceless national treasures.
How can you prevent such gaps in your systems? Choose a solution that logs every action, recovers gracefully when things break, and enforces permissions with the rigor of a museum that's been robbed once and refuses to let it happen again.
Yellowfin is a BI decision engine with a security architecture that shields you from data leaks, compliance violations, and the ongoing cost of maintaining secure data access.
See how Yellowfin approaches security (bonus: a demo of the platform).