The Comprehensive Guide to Product Lifecycle Management

Reports about unintended sensitive data exposure in Mendix applications due to authorization misconfiguration are not new. Similar discussions have surfaced over the past few years, often following security reviews, pen tests, or internal audits, with the topic receiving extensive attention in the Dutch market due to the recent Odido hack.

While high-profile incidents typically result from a combination of technical, organizational, and operational factors, discussions around such events often raise questions about the role of platforms and enablement software used within application landscapes.

It is important, therefore, to clarify that these situations generally do not concern structural security issues or vulnerabilities within the Mendix platform itself, but rather application-level security configuration in Mendix apps, including how authorization settings, data access, roles, and constraints are implemented and maintained.

The Mendix runtime, cloud infrastructure, and core security architecture remain robust and continuously improved, having been significantly strengthened in recent versions. But authorization misconfiguration can occur when these elements are not designed or validated carefully.

Since correct implementation and lifecycle governance remain the responsibility of application owners and their implementation partners, it becomes essential to understand how organizations can structurally prevent security misconfiguration in Mendix applications and ensure application security throughout the entire lifecycle.

Security misconfiguration in Mendix applications: Risks and business impact

What investigations such as the DVID research have highlighted is that in some Mendix environments (cloud hosted, on-premise, and internet facing portals), data sources have been accessible to users who should not have access. In most cases, this turns out to be a common security misconfiguration at the application level, typically related to:

• Overly permissive entity access rules
• Incorrect or overly broad role mappings
• Missing or insufficient XPath constraints
• Anonymous user permissions that are too broad
• Default or newly registered users receiving unintended access
• Insufficient authorization checks in microflows or published REST services
• Unrestricted data exports or bulk data retrieval functionality without proper authorization controls

Like other cloud and PaaS platforms, Mendix operates under a shared responsibility model. While the platform provider secures the underlying infrastructure, runtime environment, and core platform capabilities, application owners remain responsible for the correct configuration of authorization, roles, and data access within their Mendix applications.

If runtime permissions are configured too broadly, data can be retrieved through normal Mendix runtime requests. In other words, when authorization misconfiguration occurs, the runtime simply returns the data it has been configured to expose.

This behavior can unintentionally lead to sensitive data exposure, creating potential risks for organizations, including:

GDPR / AVG exposure‍

Personal data such as names, addresses, contact details, or documents may become accessible to unintended users, potentially triggering regulatory obligations.

Fraud and phishing risk‍

Exposed data can be leveraged for targeted phishing, social engineering, or impersonation.

Reputational damage‍

Even limited exposure can harm trust among customers, partners, and regulators.

Compliance and audit impact‍

Authorization gaps may lead to audit findings, remediation requirements, or breach notification assessments.

In many environments, additional technical safeguards (such as IP filtering or network restrictions) may reduce external exposure. However, investigations repeatedly show that when security misconfiguration in Mendix apps occurs, infrastructure-level controls alone are not sufficient to mitigate the underlying configuration risk.

Mendix security best practices: Why authorization must be continuously validated

Authorization security in Mendix app development is not a one-time configuration task. It is an ongoing discipline that requires structural validation, recurring checks, and governance throughout the application lifecycle. At CLEVR, Mendix security best practices are embedded in both development and support processes.

Structural Mendix security validation

To structurally validate authorization models, we leverage a combination of dedicated CLEVR tooling and established security analysis solutions within the Mendix ecosystem. Historically, we have used ACR and explored QSM as validation mechanisms, alongside role visibility and authorization insight tools available in the Studio Pro directly.

To ensure that authorization is not only configured but continuously verified against best practices, we perform structural security checks that validate:

• Entity access rules
• Module role mappings and user role assignments
• Page access configuration
• XPath constraints and data visibility rules
• Anonymous user settings

These validations are a core part of secure Mendix app development and help prevent security misconfigurations before applications go live.

Continuous Mendix security revalidation in support

Applications under support are periodically and structurally rechecked as part of our governance model. With every support release, we repeat authorization and Mendix security validations to prevent regressions, unintended permission changes, or gradual authorization drift that can occur as Mendix apps evolve.

This continuous revalidation ensures that new features, bug fixes, or role adjustments do not unintentionally broaden data access or weaken existing controls. When findings are identified, configurations are amended and the authorization model is reassessed to prevent recurrence and reduce the risk of sensitive data exposure.

We also deliberately go one step further by continuously reassessing not only the applications themselves, but also the way we validate them. Tooling, processes, and governance mechanisms are reviewed to ensure they remain scalable and futureproof. This includes investigating automated scans triggered by proactive tickets and exploring sustainable alternatives for existing validation tools.

In a reality where structural checks require continuous discipline, especially under the daily pressure of projects and support activities, continuously strengthening validation frameworks is essential. By doing so, organizations can prevent blind spots, reduce human dependency, and ensure that Mendix security governance evolves alongside both the applications and the platform itself.

5 Practical Mendix security best practices to prevent sensitive data exposure

With over 30 years of experience implementing Mendix low code applications, we have identified proven Mendix security best practices for organizations operating one or multiple Mendix apps.

‍

1. Review authorization in Mendix applications structurally

Authorization reviews should not be incidental but systematic. Organizations should conduct structured and recurring reviews of entity access rules, role mappings, XPath constraints, anonymous user permissions, default user roles, and published services. This helps identify authorization misconfiguration early and prevent sensitive data exposure.

2. Treat Mendix security as a lifecycle responsibility

While authorization is often designed during early Mendix app development, it cannot remain a onetime exercise. Security must be continuously monitored throughout the lifecycle of Mendix apps to ensure that evolving features and role changes do not introduce new security misconfigurations.

3. Upgrade to supported Mendix versions

Supported LTS/MTS versions provide improved Mendix security capabilities, including clearer role insights and enhanced governance tooling. Staying on supported versions allows organizations to benefit from ongoing platform security improvements.

4. Combine application and infrastructure security controls

Preventing sensitive data exposure requires layered security. Organizations should combine application-level Mendix authorization with infrastructure controls such as IP restrictions, optimized security headers, certificate-based access, monitoring, and periodic security testing.

5. Choose an experienced Mendix implementation partner

Security maturity in Mendix app development is strongly influenced by implementation expertise and governance discipline. Organizations should evaluate partners not only on delivery speed, but also on their ability to implement Mendix security best practices, validate authorization models, and perform recurring security reviews.

Strengthening Mendix security through strategic governance

The renewed attention around security misconfiguration in Mendix applications should not lead to alarm, but it should encourage strategic reflection. These discussions do not point to a structural vulnerability in the Mendix platform, but rather highlight the importance of governance, validation, and disciplined implementation of Mendix security practices.

For organizations using Mendix apps, this is a valuable opportunity to reassess authorization models, review existing configurations, and strengthen security governance with their development or support partners.

Security in Mendix is not a one-time checkpoint but a continuous operational discipline. And organizations looking to evaluate their Mendix security posture or validate their authorization model may benefit from an expert consultation.

Reach out for a consultation on how to strengthen governance in a pragmatic and structured way.

Robotics, digital twins, advanced automation, and emerging technologies such as generative AI are attracting immense investment across the manufacturing sector. Organizations are building increasingly connected ecosystems of data, platforms, and cyber-physical systems in pursuit of seamless interoperability and end-to-end visibility.

Yet for many manufacturers, these initiatives struggle to scale beyond pilots, stall during enterprise rollout, or result in standardized technology stacks that lack the flexibility to adapt to the unique workflows of each plant and operation. Recent Deloitte research confirms this paradox, citing mitigating operational risk, addressing talent and skills gaps, and aligning IT and OT priorities among the primary culprits.

But if the technology works, then why doesn’t the smart factory?

Smart manufacturing requires more than standardization

Industry case studies consistently demonstrate that smart factories are both achievable and capable of delivering measurable improvements in efficiency, quality, and capacity. The digital backbone reliably manages engineering intent, planning, costing, and execution control. The execution layer provides real-time operational visibility from machines and shop floor systems. And emerging technologies such as digital twins, IoT platforms, and AI further enhance performance through advanced analytics, simulation, and predictive intelligence.

However, organizations progress at different speeds, shaped by varying levels of digital maturity, technical capability, and transformation readiness. The breakdown rarely occurs within individual systems. It emerges between them, where workflows must connect engineering, planning, execution, and optimization into a coherent, end-to-end operating model.

Standardized platforms, while essential, are not designed to accommodate the full diversity of workflows, product variants, and governance structures that exist across plants and business units, making smart manufacturing more than just a technological adoption problem.

Where manufacturing process optimization breaks down

When workflows are not fully aligned, symptoms becomes visible across PLM, ERP, MES/MOM, and the shop floor, creating operational friction, slowing decision-making, and undermining the consistency of day-to-day execution.

‍

1. Engineering-to-production misalignment

In manufacturing environments, engineering updates a design, variant configuration, or Bill of Materials in PLM, but the change is not automatically reflected in MES work instructions or on the shop floor. Operators continue building to outdated specifications, while ERP planning still references previous routings or components. The result is rework, quality deviations, and delayed deliveries not because systems failed, but because the digital thread between PLM, ERP, and MES is incomplete.

‍

2. Planning vs. execution gaps

ERP releases production orders based on forecasted capacity and inventory assumptions, yet real-time constraints (like machine availability, tool wear, or labor allocation) are only visible in MES or on the shop floor. Without a synchronized workflow between ERP and MES/MOM, planners operate on outdated data while production teams manage exceptions manually.

‍

3. Shop floor visibility without enterprise integration

Sensors and machine data provide rich operational insight, but deviations captured on the shop floor do not consistently trigger structured workflows in ERP, quality management, or service systems. Maintenance teams may see alerts, yet spare parts planning, cost tracking, or customer communication remain disconnected.

‍

4. Service feedback not closing the loop

For machine builders in particular, insights from installed machines (such as performance data, recurring faults, configuration issues, etc.) are not systematically fed back into engineering in PLM. As a result, product improvements rely on informal communication rather than traceable, data-driven workflows across the lifecycle.

‍

5. IT/OT governance misalignment across systems

IT teams standardize architectures across PLM, ERP, and enterprise systems, while OT teams prioritize uptime and local production stability in MES and shop floor environments. Without clearly defined cross-system workflows, integrations stall, exceptions bypass governance, and digital initiatives lose credibility.

‍

Low code manufacturing workflow orchestration: connecting PLM, ERP, and MES/MOM and shop floor integration

Positioned on top of existing PLM, ERP, MES/MOM, and shop floor systems, low code enables manufacturers to connect their digital backbone, execution layer, and optimization technologies into one coordinated operating model.

By acting as the connective tissue between systems, low code transforms technical interoperability into operational interoperability, ensuring:

‍

1. Real-time decision activation across PLM, ERP, and MES

Engineering changes in PLM can automatically update ERP planning parameters and MES work instructions, enabling synchronized execution instead of manual reconciliation and delayed corrections.

‍

2. Closed-loop production and service feedback

Machine data, quality deviations, and field performance insights can trigger structured workflows back into ERP and PLM, creating a continuous improvement loop rather than isolated reports.

‍

3. Operational dashboards tailored to roles and plants

Low code enables plant managers, planners, and service teams to access unified, role-specific dashboards that combine ERP, MES, and shop floor data, supporting faster, data-driven decisions in daily operations.

‍

4. Exception-driven workflow automation

Instead of relying on emails or manual escalations, deviations in production, inventory, or machine performance automatically initiate traceable workflows across systems, reducing response time and execution risk.

‍

5. Variant and configuration management aligned with execution

For machine builders, product variants and custom configurations can be reflected consistently from PLM through ERP to shop floor systems, minimizing rework and delivery delays.

‍

6. Scalable integration without disrupting core systems

Manufacturers can extend ERP, PLM, and MES capabilities incrementally, adding new workflows and use cases as business needs evolve, without destabilizing their existing technology landscape.

Build your smart factory with the right strategic implementation partner

Low code does far more than connect systems. It enables manufacturers to operationalize data across the entire product and manufacturing lifecycle, turning insight into structured, measurable action.

From engineering and planning to production and service, low code strengthens how information flows across the organization. And at CLEVR, we partner with manufacturers to translate that potential into tangible business outcomes.

With 30+ years of experience in the Siemens Xcelerator portfolio and advanced low code application development, we bridge strategy and execution, connecting proven industrial platforms with the flexibility required to adapt to evolving operational demands. We begin by defining where value can be unlocked across the operational chain, then design and implement tailored workflows that connect PLM, ERP, MES/MOM, and shop floor systems. Rather than forcing your organization into rigid templates, we use Mendix—the leading enterprise low-code platform—to build orchestration layers aligned with your specific processes, governance model, and growth ambitions.

This approach allows manufacturers to:

• Align PLM, ERP, MES/MOM, and shopfloor processes around shared outcomes.
• Leverage existing Siemens Xcelerator components while extending them where standard functionality stops.
• Handle exceptions and deviations consistently across teams and systems.
• Evolve workflows incrementally as operations, products, and strategies change.

Smart factories are built on aligned workflows

Smart factories are not defined by the technologies they adopt, but by how well workflows align people, systems, and decisions. Until that alignment exists, even the most advanced digital initiatives will struggle to deliver lasting impact.

With the right strategic implementation partner, however, manufacturers can overcome these challenges, align systems with business ambitions, and tailor operations to the specific performance goals they set for growth, efficiency, and innovation.

If you are ready to move beyond isolated initiatives and build a truly connected manufacturing environment, contact us for a consultation to explore how your organization can unlock measurable operational value.

Every day when I wake up, I open my laptop, read my emails, and check the news (also the AI news). And every day I see new models, new research papers, and new projects. There's a lot of things happening.

I feel haste. I feel urgency. I have the feeling that I have to do something with this information and also a little bit of FOMO. I see other companies taking actions and I think maybe we should do too.

All this creates a kind of pentup energy that I don’t really know where to put. It makes me feel like I should do something. And like every person in business I fall back on the most familiar reflex when something becomes too big, too fast, or too complex to handle: outsource it, hire help, make it someone else’s problem.

And with AI I think that it's the wrong way to look around about it.

Outsourcing AI thinking is dangerous

We see this with many of our clients. They bring in external teams like us to build software, just like they hire plumbers to fix blocked pipes. They don’t train plumbers internally because it’s inefficient, and they don’t stand up full development teams from scratch because it takes enormous time, cost, and organisational effort. In most cases, outsourcing is simply the fastest and least disruptive way to keep the business running.

But the moment you hand it off, you also hand off the learning that comes with it. The thinking, the decisionmaking, the conversations you should be having internally about AI, those end up happening somewhere else, with someone who isn’t living your organisation’s reality.

And that’s the real risk. AI is topic simply too big, and it’s going to change the way we work too deeply, for any organization to outsource the understanding and the learning to an entity outside your own walls.

Why AI is different from every "disruptive" technology before

When we talk about technology, we often throw around the word “disruptive,” but AI genuinely earns it. Not because it’s louder or faster, but because it changes where work happens and who can do it. So the question becomes: why is AI different from all the other technologies we once thought would change everything? For me, it comes down to three simple but profound shifts.

1. Humans work inside systems, AI works across them

We all work in systems. Whether it’s CRM, email, development tools, ERP (you name it) our daily work happens inside these structured applications. But the real effort, the part no system truly handles, lives between those tools.

Whenever something is too complex or too unstructured to automate, we put humans there. They make judgment calls, chase information, talk to multiple teams, fix issues, and move processes from status A to status B. In practice, people act as the connective tissue that keeps all these systems aligned and moving.

They are the glue between applications, and that’s exactly the space where AI is starting to make an impact.

Those inbetween roles, those loops are now increasingly automatable. Five years ago this simply wasn’t realistic. Today, AI can take over more of that glue work, the work currently done by people, and in the future this will only accelerate.

2. AI automates what was previously not automatable

The AI market can be sliced in many ways, but the distinction that works best for me is this:

On one side, you have tools, the more traditional, incremental form of software development. A new feature here, a small improvement there, something that makes a product 5% better or a bit nicer to use. In the AI world, that’s things like translation features, summarisation buttons, or a smart autocomplete that fills in a few fields for you. Useful, but ultimately just extensions of what software has always done.

Then you have agents. And I’ll be honest, I don’t even like the word, because everyone calls everything an “agent” these days, and 9 out of 10 times it isn’t one. Because if you look carefully at what a true agent actually is, it’s something very different.

It's a software system that can take unstructured information, turn it into its own todo list, execute that list (or ask other AIs to do it), move between systems, pull data from your CRM, make decisions, and then produce structured, meaningful output. That’s not a nicer tool. That’s a different category of software entirely.

Because the truth is, our work is really just a bundle of tasks. Some of those tasks are incredibly difficult to automate (like building relationships, reading a room, having dinner with a client if you are a salesperson). Human connection isn’t something AI can replace so those parts of the task bundle are, for now, safe.

But the small, repetitive administrative tasks? Current AI systems can already automate many of these or help you complete them much faster. And everything in between. Those mixed bundles of judgment, admin, and minor decisions, AI will become increasingly capable of handling. And that capability will only continue to grow.

But how will people experience these shifts? How will we guide them through it? How will we make sure this transition strengthens, rather than unsettles, the organization?

Navigating the human side of an AI-driven workflow

Certain tasks will naturally shift from humans to AI, we see that happening little by little everyday. One or two tasks here, a small process there, nothing dramatic at first. The work doesn’t disappear. It simply stops being done by people.

And that’s where the real conversation begins. Because while tasks may move, the people doing them don’t vanish. Their identity, their sense of contribution, and the value they bring to the organisation are tied to that work. So we need to start talking about these things now, openly and honestly.

The financial pressure

A little while ago, we visited one of our retail clients. In many ways, their organisation was wellstructured: each department ran efficiently within its own vertical, people knew what they were responsible for, and they solved problems quickly. But the moment work had to move between those verticals, everything started to slow down.

They had people manually moving information from one system to another. Typing data into Excel, copying it into Outlook, pulling information back out of Outlook, adjusting formats, fixing small inconsistencies (“this should be five numbers instead of six”), and repeating that process dozens of times a day. None of it was strategic work. All of it was essential work.

And this is the reality for many organisations. These manual gluetasks easily cost €50,000 per person per year. Now imagine an AI system that can do 80% of that work for €500 a year.

What would you do then? What would your customers do? What would any business do if they had a hundred people performing those types of tasks?

This is where the financial motivation becomes impossible to ignore.

People need to be part of the plan

This is where the human side becomes just as important as the financial one. If you’re not actively planning for how AI and automation will be introduced in your organisation, how people will be trained, how their roles may evolve, and how this new technology will find a place that feels fair and comfortable, then people simply get left out of the story.

Because if the discussion reaches the board without that human context, it turns into a numbersonly decision. On a spreadsheet, €550,000 versus €500 is not a dilemma; it’s a conclusion. And when that comparison involves dozens or hundreds of people, the choice becomes even more obvious.

That’s why it’s essential to build a human plan alongside the financial logic. People need to understand what’s coming, how it affects their work, and what their future looks like in an AIenabled organization. This shift is happening whether we want it or not but how people experience it is still very much in our hands.

The first steps every company should take

We need to start having real conversations about AI, not because it's trendy, but because the world around us is moving whether we participate or not. Two years ago, for some organisations, “AI” meant buying a chatbot or automating a single workflow. But every day I open my laptop, read the news, or check new research, and the capabilities have grown again. Things we thought were impossible last year are suddenly standard.

Other companies are already acting on this. And if we aren’t even aware of what’s becoming possible, we can’t expect our organization to generate the ideas or innovations we’ll need to stay competitive.

The best ideas always come from people. But only if those people are informed, involved, and part of the conversation.

1. Remove the fear around automation

Automation is already happening all around us, and one of the most important things organisations can do is make it a topic people feel safe discussing. It doesn’t have to be a scary word. In many industries (manufacturing is a great example) automation has been evolving for decades. Work that was once done with hammers, chisels, and manual effort is now done by robots, and often done better.

So automation itself isn’t the problem. The real challenge is helping people understand what it means for them. You need a plan for how your organisation will adapt, how roles might evolve, and how people will be supported through that change. When automation is part of an honest, structured conversation, it becomes something you manage, not something you fear. And that brings me to the second point.

2. Be transparent

Transparency becomes critical the moment you start moving toward AI adoption. People need to understand what is happening, why it is happening, and how it will affect the way they work. When organisations stay quiet or vague, uncertainty fills the gaps. And uncertainty quickly turns into fear.

That’s why you need a clear roadmap. Not a perfect one, but one that shows direction, intent, and honesty. Let people see how you’re approaching this project, what decisions are being made, and where they fit into the story.

If we are upfront about the scale of the transformation, people can prepare, contribute, and adapt. But if we keep the process behind closed doors, AI becomes something that “happens to them” rather than something they are part of.

3. Enable organisational insight

Before you can do any of this successfully, you need a clear understanding of your own organisation. Your processes, your data, your people, and how work actually gets done. This has never been more important, because AI is now capable of automating the kinds of work that were previously considered impossible to automate.

Most companies have beautifully documented process diagrams and welldefined application flows. But everything between those flows, the real daytoday work, the unwritten parts of your job description, the informal steps people take to keep things moving? Those are rarely captured anywhere. And it’s exactly in that unstructured space where AI is beginning to make its impact.

Act or be acted upon

Are you going to be the kind of organisation that embraces AI intentionally? One where people are informed, aligned, and understand how the company plans to work with AI as its capabilities grow?

Or will you become the organisation where AI simply “happens” to you? Two years pass, competitors have embraced AI, costs have dropped, efficiency has soared, and suddenly customers are asking why you can’t keep up.

If you reach that point, you no longer have the time or space to create your own framework, your own human story, or your own way of adapting to these changes. You’re forced into action instead of choosing it. And by not acting, by not even beginning the discussion, you’re still making a choice.

You’re choosing to end up in the group where AI happens to you rather than through you. And that is a position no organisation wants to find itself in, yet it is the silent reality many companies are drifting toward.

AI is a train already moving

AI is getting more capable every day, and ignoring it won’t slow it down. It’s a train already in motion, whether we like it or not. The only real question is whether we choose to take control of how it impacts us.

That starts with getting informed, involving more people, and having the conversations that matter. And I genuinely believe we are already taking good steps in that direction at CLEVR. More people are engaged, more discussions are happening, and that’s exactly what we need.

So talk about it. Think about it. Discuss it with your colleagues. The more we share our thoughts and questions, the better prepared we become.

‍