When a control system becomes unavailable, vendor access fails, or a plant cannot be controlled as expected, OT security quickly becomes a matter of operations, responsibility and decision-making power.

For energy and utility companies, OT security is therefore not only about protecting systems. It is about ensuring that the most important functions can continue when something goes wrong. That is why management should start with the scenarios that can hit operations the hardest.

This is the third post in our series on OT security in the energy and utilities sector. In the first two posts, we focused on why OT security has become a management concern, and why OT cannot be handled with the same logic as classic IT security.

If you have not read them yet, they are a good place to start:

When IT and OT meet: 3 classic mistakes management should avoid

New risks, new requirements: 5 OT security tips for management

With that as our starting point, we now move from recognition to practice. Because once management has understood why OT security requires a different approach, the key question becomes:

How do you work with OT risk in practice?

The perspectives in this post are based on experience and recommendations from Mjølner’s domain experts in the energy and utilities sector, Jakob Hviid and André Bryde Alnor, as well as our partner Jørgen Hartig from SecuriOT. They work with security, operations and digitalisation in environments where resilience, uptime and responsible decision-making are critical.

Many organisations start with what is easiest to identify: physical security, access control, network segmentation or individual technical controls. All of these are relevant. But they are not necessarily where the risk is greatest.

For OT security to create real value, management should start with a different question:

What could, in practice, stop or seriously affect our ability to deliver?

That question moves the work from general security measures to concrete scenarios that management can prioritise, test and act on.

Start with what absolutely needs to work

A good starting point for OT security is not a long list of technical measures. It is a more fundamental management question:

Which functions absolutely need to work for us to deliver our core service?

Because OT security is not first and foremost about protecting technology. It is about protecting the organisation’s ability to function. About ensuring that electricity, heat, water or production can be maintained – even when something goes wrong.

This is a crucial distinction. While IT security often starts from access, data and system protection, OT security is largely based on the ability of operations to continue – even when something fails.

Jakob Hviid, Senior Solution Architect at Mjølner, points to the same fundamental difference between the two worlds. While IT can often respond to an incident by shutting down, isolating or quickly changing systems, the premise is different in OT:

Shift the focus from assets to consequences

Many organisations are used to thinking in terms of assets:

• Which plants or systems are the most expensive?
• Which components are the most difficult to replace?
• What is technically the most complex?

These are relevant questions. But they are not enough. A more mature approach is to shift the focus from plants and components to consequences:

• What happens if an essential function fails?
• What happens if a central system is unavailable for several days?
• What happens if a supplier connection disappears at the wrong time?
• What happens if a failure in one system spreads to other parts of operations?

For management, this provides a stronger basis for decision-making. When the consequence is clear, it becomes easier to prioritise the initiatives that actually reduce risk the most.

The consequences do not stop at the OT environment

An OT incident rarely affects only one system or one plant. It can impact the entire value chain around operations, production, troubleshooting and recovery.

We often see this in practice. Many organisations have a good overview of their physical assets, but less insight into the dependencies surrounding them.

These may include order flows, supplier access, support processes, data exchange, internal workflows or key personnel who turn out to be critical when something goes wrong.

That is why it is not enough to ask whether the OT environment is protected. Management must also ask:

Which parts of the value chain do operations depend on — and how quickly can we return to stable operations if they fail?

Build a few scenarios that really hurt

One of the most useful approaches is also one of the simplest: Do not start with everything. Start with a few scenarios that would have serious consequences if they became reality.

It is good advice because it forces the organisation to prioritise. Instead of trying to map every conceivable risk, management can begin with a limited number of incidents that would have serious consequences for operations, supply, safety or reputation.

These could, for example, be scenarios such as:

• A central control system is unavailable for several days
• An external supplier loses access to a critical environment
• A plant cannot be controlled as expected
• An incident in one system affects other parts of operations
• A key person or critical support function is unavailable during an incident

The scenarios do not have to be perfect from the start. What matters is that they are concrete enough for the organisation to begin asking the right questions.

Make time part of the risk

A scenario becomes far more useful when you add time.

It is one thing to say that a system can go down. It is another to ask what it means if it is down for 24, 48 or 72 hours. Then the risk becomes concrete: How long can the function be affected before it impacts supply, safety or operations? Which emergency processes can keep operations running in the meantime? And which suppliers, spare parts or key people are critical to returning to stable operations?

Scenario thinking connects security with contingency planning, recovery and concrete courses of action.

Use the scenarios to prioritise correctly

When the most important scenarios are clear, it becomes easier to determine which investments actually reduce risk the most.

This could be technical controls, better visibility into the OT landscape, tighter management of supplier access, contingency plans, testing, spare parts or clear decision paths during an incident.

What matters is that prioritisation is based on the consequence for operations and supply – not only on what is easiest to implement.

Jakob puts the difference like this:

In OT, it is precisely the ability to maintain the value chain that must guide the work.

OT risk requires several perspectives

Scenario work cannot be handled by one function alone.

There must be clear ownership, but the work only becomes strong when several relevant perspectives are brought into play. OT risk rarely arises in one place. It arises in the interaction between plant operations, IT, suppliers, contingency planning and the business.

That is why the scenarios should not only be assessed by OT specialists. They should be reviewed together with the functions that need to act if the scenario becomes reality.

For management, the task is to establish a structure where the relevant disciplines work together to assess risk, consequence and possible actions. Otherwise, OT security risks becoming either an isolated specialist project or a risk register with no real impact on operations.

From concern to decision

OT security only becomes truly valuable when it moves from being a diffuse concern to becoming a way to make better decisions.

That is exactly what scenario thinking can do.

It helps the organisation focus on what matters most. It makes risk concrete. It creates a shared language between management, operations and specialists. And it makes it easier to prioritise both investments and initiatives.

Management can start with four questions:

1. Which functions absolutely need to work for us to deliver our core service?
2. Which 5-6 scenarios would hit operations the hardest?
3. How long can we tolerate central systems or supplier connections being unavailable?
   
4. Who owns the responsibility for testing, prioritising and following up?

The most important thing is not to find all the answers at once.

The most important thing is to get started with the few scenarios that really matter. Because once they are clear, it also becomes clearer which systems, processes, suppliers and decisions are truly critical.

At Mjølner, we help energy and utility companies translate OT risk into concrete scenarios, priorities and decision-making foundations that management, operations and specialists can act on.

Do you want to strengthen OT security without obstructing operations?

Email

aba@mjolner.dk

Phone

+45 23 46 04 45

You have a new colleague in the office. She is tireless, fast, and extremely confident. Agentic coding can feel like having a new junior developer on the team, but she does not behave like the flesh-and-blood kind. So how do you get security under control before handing your new colleague the keys to everything you can access yourself?

There is great potential in agentic coding, but it also comes with risks. Because when we give AI agents access to code, we are effectively also giving them access to a range of systems, decisions, and actions that can have consequences if the setup is not properly secured.

In this blog post, Lead Security Engineer Mads Schaarup Andersen explains where organisations should start before AI agents become a permanent part of the development environment.

Get started!

AI policies and threat modelling are processes that will evolve over time. If you decide to build an elaborate framework before involving your employees, you are almost certainly already behind.

Understand the threat model

Upskill and involve developers

This includes teaching developers to recognise risks such as prompt injection, insecure plugins, uncritical package installation, sharing secrets, and overly broad permissions. Use recognised resources such as OWASP, internal guidelines, and concrete examples from your own development environments to make security practical and relevant.

Establish governance and risk management

A good rule of thumb is to view the agent as any other part of your software supply chain: it must be assessed, approved, updated, and removable again if it turns out to pose a risk.

Implement security tools and sandboxes

Governance sets the framework. Technical security measures must enforce it in practice.

Use, for example, sandboxes, containers, or isolated development environments so the agent cannot freely read the entire file system, change critical files, or run commands without restrictions.

Security scans, agent hooks, and approval gates can help stop risky actions before they happen. This could include requiring human approval before the agent installs packages, changes CI/CD configuration, uses secrets, deletes files, pushes code, or attempts to access production environments.

Security features should not simply be enabled once and then forgotten. They should be tested continuously, so you know whether they actually stop the actions they were designed to prevent.

• Get started now. Do not wait for the perfect framework. Set the direction, expectations, and boundaries while you learn, and adapt continuously.
• Start with the threat model. Get an overview of what needs to be protected, which data flows where, which components are part of your setup, and where something could go wrong.
• Upskill and involve developers. Security needs to fit the way developers actually work. That is why they should be involved from the start — as users, sparring partners, and co-creators of the framework.
• Set clear boundaries for governance and risk management. It should not be up to the individual developer to assess which plugins, MCP servers, skills, CLI tools, or external services are secure enough.
• Enforce the framework with technical security measures. Use sandboxes, containers, security scans, agent hooks, and approval gates so the agent cannot freely access files, credentials, production data, or critical systems without control.

Initially, it is the responsibility of the organisation and management to create a secure framework. Not the individual developer’s. Because agentic coding is going to play a bigger role, and the organisations that get started now will be in a stronger position than those that only react once the AI agent has already been given the keys.

Mads concludes with a reminder that not everyone is starting from the same place:

Flexible electricity consumption can deliver significant benefits to society when part of the consumption is moved away from the times when the electricity grid is under the greatest pressure. This is the main conclusion of two new reports that highlight why demand-side flexibility can play a crucial role in the green transition.

One report from CIP Foundation examines the structural framework, potential and socio-economic benefits of flexible electricity consumption. Among other things, the report points out that an average household can save up to DKK 11,000 per year by moving its consumption to the times when electricity prices are lowest.

Together with the Alexandra Institute, Mjølner has contributed to the second report, ‘A greener and more flexible electricity consumption’, which takes a closer look at the digital foundation needed to make flexibility possible in practice. Here, we have analysed the digital solutions and technical prerequisites that can activate demand-side flexibility across electric vehicles, solar panels, home batteries and heat pumps.

Providers of flexibility services are already succeeding today in controlling many different flexible devices and are using different technical architectures to handle data and technology challenges. However, the analysis shows that the different flexibility solutions optimise for different parameters.

The control logic of the individual devices is not designed to be coordinated across systems. In short, this creates a home full of devices that each optimise according to their own goals, but not necessarily according to price or the electricity grid’s need for flexibility. When the devices are not coordinated, they may even end up working against each other.

So what can be done?

8 recommendations for robust scaling of demand-side flexibility — in brief

The analysis shows that there is great potential in making it easier to connect smaller, flexible devices to the energy system — for the benefit of both consumers and the electricity grid.

But technical integration cannot stand alone. The recommendations should also be seen in light of three important considerations: digital sovereignty, cybersecurity and the risk of technological obsolescence.

A number of sound principles for technology development can therefore create the foundation for the more technical recommendations:

1. Avoid becoming dependent on individual suppliers

   Heat pumps, batteries and electric vehicles often depend on manufacturers’ own cloud solutions and closed control systems. This can create dependency on individual suppliers and make solutions vulnerable if the technology, service or supplier changes. The market should therefore support multiple suppliers, open solutions and a real opportunity to switch suppliers.

2. Prioritise European and open solutions where possible

   European actors and open source solutions can help strengthen digital sovereignty and reduce dependency on individual foreign technology suppliers. However, this requires that the solutions can genuinely be operated and further developed independently – and do not simply resell closed services from others.

3. Create better opportunities for local control and disconnection

   Devices should, as far as possible, be able to function without a constant connection to the manufacturer’s cloud or remote control. Open APIs, local control options and documented integration interfaces make it easier to retain control, even if a cloud service changes, closes or is no longer available.

4. Create greater transparency around technology dependencies

   Many consumers, municipalities and other professional actors do not necessarily have a full overview of the dependencies and cyber risks that come with a solution. Independent audits and clear documentation can therefore make it easier to choose robust solutions and avoid hidden dependencies.

5. Think beyond the next software update

   Many flexible devices have a lifespan of 10–20 years, while software, cloud APIs and communication standards can change much faster. Solutions must therefore be built so they can be updated, maintained and integrated with new systems over time.

6. Make it easier to connect solutions

   If demand-side flexibility from smaller devices is to be scaled, more common and standardised integration protocols are needed. This will make it easier for suppliers to develop solutions that work across different brands and types of devices.

7. Build in security and robustness from the beginning

   When more smaller devices are connected and can be controlled flexibly, cybersecurity becomes even more important. There should therefore be clear requirements for access control, data protection, secure updates, network separation and documented system robustness.

8. Actively use European standards and initiatives

   European initiatives, common standards, data formats and protocols can help create more open and interoperable solutions. The more actors use them, the greater value they create for the market as a whole.

The Danish electricity grid is not an island

When Denmark strengthens demand-side flexibility, we should look beyond our own borders. Many of the technical frameworks and market principles needed to make flexible devices work together with the energy system are already being developed internationally – not least in the EU. It is therefore important that Danish solutions are built to fit into common European tracks, rather than ending up as isolated systems that later need to be rebuilt.

This places demands on the way we design digital services. They must be adjustable and capable of further development as legislation, standards and technologies change. Otherwise, we risk locking ourselves into solutions that quickly become expensive to maintain or difficult to connect with the rest of the market.

At the same time, the analysis points out that the next step is not primarily about more data. It is more about better common rules of play for how devices, control systems, flexibility service providers and the energy system can communicate. Here, standardisation, interoperability and open integration options will be crucial.

The small electrical devices we have in our homes may end up playing a major role in the electricity grid of the future. But this requires the solutions to be developed from the outset with security, digital control and long lifespan in mind.

Read more in the two reports (only available in Danish)

Demand-side flexibility as a foundation for the green transition

CIP Foundation’s report presents insights and recommendations from a comprehensive analysis project with the purpose of describing the opportunities and barriers to activating demand-side flexibility all the way out in residential neighbourhoods. The report includes 10 recommendations for promoting demand-side flexibility in the Danish electricity grid. Read the report here.

A greener and more flexible electricity consumption

In collaboration with the Alexandra Institute, Mjølner Informatics has analysed the digital solutions that can activate demand-side flexibility across electric vehicles, solar panels, home batteries and heat pumps. Digital solutions already exist, but the landscape is fragmented, and the full potential is far from being realised today. The report contains 8 general recommendations for promoting flexibility, ensuring digital sovereignty and cybersecurity, and avoiding technological obsolescence. In addition, the report includes 7 technical recommendations that point to concrete initiatives for promoting demand-side flexibility in practice. Read the report here.

Let’s talk about digital transformation

Email

Phone

Many energy and utility companies have significantly strengthened their work with cybersecurity in recent years. But as data, integrations and digital tools move closer to physical operations, a new management challenge emerges:

How do you create security when IT and OT systems can no longer be considered separately?

This question is becoming increasingly important in the energy and utility sector, where digital solutions are becoming an integral part of critical operations. And as the dependencies between IT and OT grow and become increasingly important to critical operations, it becomes clear that classic IT measures do not always work as intended in OT environments.

On the contrary, security measures that make good sense in administrative systems can create new problems when transferred directly into production and operations.

The perspectives in this post are based on experience and recommendations from Mjølner’s domain experts within the energy and utility sector, Jakob Hviid and André Bryde Alnor, as well as our partner Jørgen Hartig from SecuriOT.

In a previous post, we gathered 5 concrete recommendations for management on OT security. You can read it here.

In this post, we focus on 3 classic mistakes management should avoid when IT and OT meet.

1. Treating OT like ordinary IT security

The first mistake is to assume that OT can be secured using the same toolbox as IT.

At first glance, that seems logical. If something is cyber-related, IT security must be the natural answer. But there is a crucial difference: in IT, security is typically about protecting data, users and systems. In OT, security is largely about keeping operations running, ensuring uptime and preventing errors or attacks from having physical consequences.

OT security is therefore not only a question of protecting against malware or unauthorised access. It is also about ensuring that the company can continue operating when something goes wrong:

This is a crucial difference. While IT security often starts with access, data and system protection, OT security largely starts with the ability of operations to continue – even when something fails.

Jakob Hviid, Senior Solution Architect at Mjølner, points to the same fundamental difference between the two worlds. While IT can often respond to an incident by shutting down, isolating or rapidly changing systems, the premise is different in OT:

Jørgen points out that classic IT requirements can create new risks if they are transferred directly to OT. He mentions an example from a company where a strict password policy was also applied on the production line, requiring operators working in three-shift rotation to log in with long passwords on an HMI interface. In an administrative IT context, that may seem sensible. But in an operational situation where fast action is required, it can have the opposite effect:

Jørgen’s point is simple: A strong password requirement may be sensible in an administrative system, but it can create a new risk in a critical operational situation where an operator needs to react quickly. When a security control is designed based on IT logic alone, it may come into conflict with the reality of OT.

This does not mean that classic IT controls are wrong. But it does mean that they cannot be copied directly into OT without being assessed in the right context.

For management, the lesson is clear: Security in OT must be assessed based on its consequences for operations, uptime and physical safety – not only based on whether the control looks right on paper.

2. Underestimating how integration between IT and OT changes the risk landscape

The second mistake is to see integration between IT and OT systems as a pure gain.

In practice, integration offers significant benefits. Data from plants and operations can be used for analysis, planning, troubleshooting, decision support and optimisation. It is an important part of the sector’s digital development.

André Bryde Alnor, Energy Solution Strategist at Mjølner, highlights that more and more digital solutions today are built on operational data:

This creates major opportunities. But it also creates new dependencies.

When more systems, suppliers and business-critical processes are connected, the risk landscape becomes more complex. A decision about digitalisation is therefore not only a technical decision. It is also a management decision about risk, responsibility and resilience.

For André, the central question is therefore how companies can realise the benefits of modern architecture and better decision support without weakening security:

In other words, digitalisation should not be stopped. But it must be carried out with an understanding of the new dependencies it creates.

This applies, for example, to supplier access, remote support, data exchange and other connections established to support efficient operations.

This is an important point for management. Many of the solutions that create value in day-to-day operations can also open up new vulnerabilities.

Jørgen points, for example, to how external supplier connections often arise for entirely legitimate reasons: faster support, less downtime and more stable operations. The problem is not the intention. The problem is that the solution can also create a new path into the OT environment.

That is why management should not only ask what digital opportunities the integration creates. They should also ask:

• Where do IT and OT meet in our organisation
• Which connections and dependencies do we have?
• Which practical shortcuts in operations may become potential attack surfaces?
• What do we do if an important connection, supplier or solution suddenly stops working?

3. Placing responsibility in one silo

The third mistake is organisational.

As OT security receives more attention, a natural question arises: Who is responsible?

And here, many organisations see the same tendency. Responsibility is placed in one function – often where the word “security” already exists. But if OT security is placed too narrowly, the company risks assigning the task to someone who only understands one half of the problem.

André Alnor puts it very directly:

That is precisely the challenge at the intersection of IT and OT. A classic IT security function may be strong in cyber disciplines, access control and network protection – but lack the necessary understanding of operations, contingency planning and physical infrastructure. Conversely, an operations function may have a strong focus on uptime and continuity, but not necessarily be equipped to handle the cyber threats that follow from digitalisation and integration.

The “bridge” between IT and OT is not something you can simply take off the shelf. It has to be built organisationally.

For management, this means that OT security should not be reduced to either a purely IT matter or a purely operational issue. It requires a structure where someone has the mandate to bring the perspectives together, coordinate the effort and raise the right risks to management.

But responsibility must not become a silo. It must create coherence between the functions that each hold part of the problem: management, IT, operations, contingency planning, risk management and supplier management.

What does this mean for management?

When IT and OT meet, it is not enough to ask whether security is strong enough. Management must also ask whether security has been thought through in the right way.

Among other things, this means:

• OT security must be assessed based on the reality of operations
• Integration between IT and OT must be seen as both a benefit and a new risk surface
• Responsibility must be anchored in a way that builds bridges between disciplines rather than reinforcing silos

That is ultimately the most important point.

Good security is not necessarily the control that looks strongest on paper. It is the solution that protects the organisation without undermining its ability to function.

In the energy and utility sector, security is not only about data. It is also about operations, uptime and critical functions in society.

That is why classic IT measures cannot stand alone when OT becomes a larger part of the digital risk landscape.

When IT and OT meet, management must understand both worlds. Otherwise, they risk creating new problems in the attempt to solve the old ones.

Do you want to strengthen OT security without disrupting operations?

Email

aba@mjolner.dk

Phone

+45 23 46 04 45

Cybersecurity has become a strategic topic in the energy and utilities sector. In recent years, many organisations have significantly strengthened their IT security. But as digitalisation increasingly reaches production and operations, more are discovering an area where the overall picture is often less clear.

That area is OT — Operational Technology.

OT covers the systems that control physical operations: production facilities, pumping stations, substations and control systems. This is where software meets physical infrastructure — and where the consequences of a security breach are not limited to data loss, but may include operational disruption or impacts on critical infrastructure. For management, this raises a key question:

How do you get started with OT security in a way that creates real business value?

The following five recommendations are based on the experience and advice of Mjølner’s domain experts in energy and utilities, Jakob Hviid and André Bryde Alnor, as well as our partner Jørgen Hartig from SecuriOT.

1. Assign clear ownership

One of the biggest challenges in OT security is organisational.

In many organisations, the issue quickly ends up being passed around between departments: production points to IT, and IT points back to production.

As a result, OT security often falls between several functions: operations, IT and cybersecurity. Everyone recognises the risk – but no one has the clear mandate to drive the effort forward.

That is why OT security does not start with technology. It starts with a management decision about ownership.

But where does it make sense to place that responsibility?

Experience from many organisations shows that the role should rarely sit solely within a pure IT security function. OT security is largely about operations, uptime and physical infrastructure – and therefore requires an understanding of production.

A good rule of thumb is to place responsibility with a function that:

Understands operations and the value chain
The person must be able to assess what is actually critical to production or supply.

Can work across IT and operations
OT security sits at the intersection of multiple disciplines. The role must be able to bring the organisation together, not reinforce silos.

Has the mandate to escalate risk to management
Ultimately, OT security is about business risk. The person responsible must therefore be able to translate technical issues into management decisions. In some organisations, the role sits with a CISO who has OT expertise. In others, it sits within operations or asset management, working closely with IT. The exact placement may vary – but the crucial thing is that responsibility is clear and supported by management.

2. Understand the difference between IT security and OT security

A classic pitfall is to treat OT security as a conventional IT security issue. The two areas operate on fundamentally different premises. In the IT world, security is typically centred on protecting data and systems. In the OT world, the primary focus is stable operations and physical safety.

This also means that some traditional IT security measures do not necessarily fit directly into OT environments.

The point is not that security matters less in OT – but that it must be designed around the operational reality of the utility.

3. Start with risk – not with what is easiest

When organisations begin working with OT security, there is often a tendency to start with the things that are easiest to relate to, such as:

• fencing and physical access control
• network segmentation
• software backups

All three are important. But they are not necessarily where the risk is greatest.

A more effective approach is to start with the risk assessment.

A good first question is: Which functions in our organisation absolutely must work for us to deliver our core service?

Once those essential functions have been identified, you can move on to:

• which systems support them
• which threats could affect them
• what the consequences would be if they failed

Many organisations work with concrete threat scenarios – for example, what would happen if a central control system became unavailable for several days. That makes it much easier for management to prioritise investments, because the discussion is based on business risk rather than technology.

4. IT and OT need to work more closely together

Historically, OT environments have often been relatively isolated from the rest of the organisation’s systems. But as digitalisation and data analysis advance, the integration between IT and OT is becoming increasingly close.

This means that security work can no longer take place in silos. IT and OT specialists need to work more closely together, and management must ensure that the organisation has a structure that supports that collaboration.

5. Find your maturity point – and build from there

Another important lesson from across the sector is that OT security cannot be implemented in one single, all-encompassing effort. This often becomes apparent when the work is driven by compliance requirements or regulation. The organisation tries to implement all controls at once and ends up with a large programme that is difficult to operationalise.

A more realistic approach is to start from the organisation’s current level of maturity.

In practice, that typically means establishing the basic processes first, working systematically with risk and continuously improving security over time. OT security is not a project with an end date. It is a discipline that evolves over time alongside technology, digitalisation and the threat landscape.

Five key recommendations for management – in brief

If the sector’s experiences are boiled down to five key pieces of advice for management in energy and utility companies, they are these:

1. Assign clear ownership of OT security

OT security often falls between operations and IT. Make sure one function has the mandate to lead the area and coordinate the effort across the organisation.

2. Start from business risk

Do not start with the technology. Start with the question: What must not go wrong in our utility – and what would the consequences be if it did?

3. Prioritise based on risk – not on what is easiest

Many organisations start with perimeter protection or network segmentation because it is concrete and visible. That matters – but it is not necessarily where the greatest risk lies. Let the risk assessment guide the effort.

4. Create visibility into your OT landscape

Management should ensure that the organisation has a realistic picture of its OT systems, connections and dependencies. You cannot protect what you do not know

5. Treat OT security as an ongoing maturity journey

OT security is never “finished”. Start from your current level, build structures and processes, and improve them continuously.

The worst thing you can do is nothing

OT security can seem complex. Infrastructure, systems and suppliers have often evolved over many years, and there is rarely a simple fix.

But that does not mean you should wait. Quite the opposite. For many organisations, the greatest risk is not starting too small – it is not getting started at all.

As the sector’s experience shows, the most important step is to begin: create visibility and start working with risk in a structured way.

The worst thing you can do is nothing.

Do you want to dive deeper into the interaction between IT and OT? Then read our article: When IT and OT meet: 3 classic mistakes management should avoid.

Want to know more about OT security?

Email

aba@mjolner.dk

Phone

+45 23 46 04 45

The energy and utilities sector operates in an OT landscape where operational stability, cybersecurity, and compliance are non-negotiable. At the same time, demands for flexibility and integration are increasing. This challenges traditional vendor models. Open source is not a miracle solution, but for many organizations, it can be a strategic response to these challenges.

The need for new functionality in OT solutions has grown significantly. Many organizations find that the development pace of traditional vendors does not always match their need for rapid adaptation. So-called cloud-native, open-source software supports a more modular and independent approach, where solutions are composed of smaller components that can be continuously adapted and replaced.

According to André Bryde Alnor, Energy Solution Strategist at Mjølner, this shift is already taking place in the energy sector. Open source has set the standard in the IT world, and with initiatives such as LF Energy, we are now seeing how this approach can create shared innovation and strengthen control in the energy sector.

Read on to learn why open source has become a strategic alternative to traditional vendor solutions for many energy companies.

Greater Control and Transparency

The open codebases in open-source software provide insight into how a solution actually works, creating greater transparency. At the same time, open licenses allow you to adapt and replace components as needed. In many commercial solutions, the contents are more closed, which can make it more difficult to gain full insight into architecture and dependencies.

Rapid Handling of Vulnerabilities

In many cases, vulnerabilities are handled quickly in open-source communities because errors are discovered and shared openly. This gives organizations the opportunity to respond quickly, provided they have control over updates and operations. The collaborative approach makes it easier to manage and close vulnerabilities in critical systems.

Scalability and Flexibility

With open source combined with a loosely coupled architecture, parts of the system landscape can be adjusted without replacing entire platforms. This enables energy-sector organizations to quickly scale and adapt solutions to changing needs in a sector where requirements are evolving rapidly.

Cost Efficiency

When using open source for OT solutions, you can reduce licensing costs and redirect more resources from licenses to development and operations. At the same time, functionality can be implemented quickly by selecting and configuring existing components.

Shared Innovation and Collaboration

Open source creates opportunities for joint development across the energy sector. When multiple organizations collaborate on shared components, they can share costs, reduce duplicate work, and develop new solutions faster.

The changes and new functionality that emerge from this collaboration can be implemented much faster, as organizations are not dependent on the development cycles of commercial vendors. At the same time, shared components reduce duplication and accelerate integration across countries and infrastructures.

Better Compliance with Cybersecurity Requirements

With access to the source code, it becomes easier to ensure that a solution meets specific security requirements and can adapt to new threats. More eyes on critical code also reduce errors and vulnerabilities – an important quality in OT, where the consequences of failures can be severe.

This provides a stronger foundation for documentation to authorities and boards.

Demystifying the Risks

Using open source may seem controversial because operational requirements are extremely high when it comes to security of supply and critical infrastructure. However, some overlook the fact that open source is already the standard in global software development, and that most commercial products are already built on open-source components.

The increasing complexity of energy systems requires collaboration across organizations and vendors, which is why open source is becoming increasingly unavoidable.

Open source is not the easiest path. The approach requires expertise, governance, and clear operating models. But for energy companies that want flexibility and strategic independence in their OT landscape, it can be an effective way to gain control over their system landscape, risks, and vendor relationships.

Has the IT industry created a culture where individual achievements are celebrated? Where the so-called 10x developers are crucial to a project’s success? And is it even appropriate for a few individuals to bear the great responsibility? Team Topologies points out that teams are the core of delivering high-quality products efficiently.

Imagine a software team where much depends on one superstar developer. When they go on vacation, uncertainty arises in the team, colleagues feel pressured, and errors creep into the code. This is a clear sign of a vulnerable team structure – and precisely the problem that Team Topologies aims to solve.

In this blog post, we explore the principles of Team Topologies and look at the significance of team interactions for software architecture. Henning Böttger is a Senior Software Architect at Mjølner, and he provides specific suggestions on how to make a team effective. It is about designing our teams to promote collaboration, reduce friction, and maintain sustainable productivity. And it is necessary to manage cognitive load if you want to create high-performing teams.

You can also watch Henning’s entire lecture on the topic at the bottom of this page.

The socio-technical aspects of teams according to team topologies

To understand why some teams perform better than others, it is necessary to examine the socio-technical dynamics that affect team efficiency. This involves both human collaboration patterns and the technical structures that shape software development.

Effective team design, as mentioned, is about more than just assembling skilled individuals. The way teams interact determines their ability to deliver value efficiently. Team Topologies introduces a structured approach to organizing teams based on their function and communication patterns.

Instead of relying on a hero culture, where individual members bear a disproportionate burden, organizations should focus on building autonomous teams with clear responsibilities and fewer dependencies. This approach leads to more predictable outcomes and a sustainable development pace. As Henning points out, focusing on individuals rather than the team can create a negative spiral:

Conway’s law: The hidden Blueprint for software design  

One of the most fundamental concepts in team organization is Conway’s Law, based on Melvin E. Conway’s groundbreaking 1967 article: “How Do Committees Invent?“ The law states that the way teams communicate and interact influences the architecture of the systems they create. When organizations are divided into silos, their software will reflect that division, often leading to inefficiency and fragmented systems. Henning points out the importance of being aware of this correlation:

Conversely, organizations that deliberately design their team structures to support the desired architectural outcomes can create scalable and maintainable software. Instead of trying to fix software problems after they arise, companies should focus on improving team communication and alignment first, as this will naturally lead to better systems.

Dunbar’s number: Why small teams work best

A team’s efficiency is also influenced by Dunbar’s number, which suggests that humans can only maintain strong, trust-based relationships with a limited number of people. In the 1990s, British anthropologist and evolutionary psychologist Robin Dunbar discovered a correlation between brain size and group size in primates. He hypothesized that humans have a cognitive limit to the number of social relationships we can manage effectively.

For software teams, this means that smaller, closely-knit groups are more effective at communicating and solving complex problems. Dunbar’s number for larger networks is estimated to be around 150, while for close and trust-based groups, it is between 5-15. Henning describes it like this:

Source: Wikimedia Commons

When teams become too large, coordination becomes more difficult, collaboration weakens, and the decision-making process slows down. This is why many high-performing organizations limit team sizes and ensure that each team remains small enough to function effectively without unnecessary bureaucracy or friction.

For example, Amazon has implemented the famous “two-pizza rule,” where each development team should be small enough to be fed by two family-sized pizzas – typically 6-10 people. Small, autonomous teams make it easier to adapt to changes and reduce dependencies, ensuring that the software architecture remains flexible and modular.

Managing cognitive load for maximum efficiency

In addition to team size and communication patterns, another critical factor in productivity is cognitive load – the total mental effort required to perform a task. When developers are overwhelmed by complex systems, inefficient processes, or excessive responsibilities, productivity decreases. Henning reflects on how it can feel as a developer to hit a mental wall:

To reduce cognitive load, one should limit the team’s area of responsibility (bounded contexts). This involves setting clear boundaries so that a single team is not involved in too many domains or technologies – this can be achieved through Domain-Driven Design, where a team can focus on one value stream.

Structuring and Designing teams for High performance  

In addition to reducing cognitive load, it is crucial that individual teams are designed according to their specific purpose. With a clear understanding of socio-technical dynamics, organizations can structure their teams more effectively. Team Topologies describes four central team types:

• Streamlined teams – Responsible for delivering end-to-end business value and owning specific features or domains. 

• Enabling teams – Help streamlined teams acquire new skills, such as DevOps practices or security expertise.  

• Platform teams – Maintain shared infrastructure and reduce the operational burden for development teams.  

• Complicated subsystem teams – Handle specialized, complex components that require deep technical expertise. 

A well-organized team structure is not only about defining team types but also about how the individual teams collaborate. Team Topologies identifies three primary interaction modes:

• Collaboration – Teams work closely together when solving new or complex problems.  

• Facilitation – One team helps another develop new competencies and then steps back.  

• Access-as-a-Service – Teams interact with minimal direct communication via well-defined APIs or automated processes.  

Although clear communication and good collaboration are parameters that can be perceived as “soft” and difficult to measure, they can have a decisive impact on the business and the bottom line. As Henning puts it:

Take the step from theory to practice with team topologies

Team Topologies shows us that success in software development is not just about talent, but also about structure. By designing teams with clear roles, reducing cognitive load, and understanding the interaction between people and technology, organizations can create more effective and sustainable development teams.

Whether you work in a large company or a startup, small changes in team organization can have a big impact. You can start by mapping your dependencies, identifying bottlenecks, and considering how team design can support your architecture rather than hinder it. Perhaps Team Topologies can help you create better collaboration and more robust systems.

As a decision-maker, building a prototype may seem like a significant investment. What if the product never reaches the market? Would that money be wasted? The reality is that with off-the-shelf components and open-source platforms, you can minimize both time and costs. And even if the idea never becomes a final product, rapid prototyping remains a fast and affordable way to refine your business strategy and make better decisions.

Bent Bisballe Nyeng is a Senior Embedded Solution Architect at Mjølner. We asked him about the benefits of rapid prototyping and how to get started.

How to Test a Business Idea with Rapid Prototyping

So, you want to test a business idea using rapid prototyping? Well, the obvious answer is to call Mjølner! Jokes aside, at Mjølner, we follow a three-phase approach to rapid prototyping, where we assess at each stage whether to proceed or not.

We apply a “Fail Early” strategy, identifying errors and challenges as soon as possible—so we can learn from them quickly. The goal is to minimize risk, reduce costs, and improve the prototype before too many resources are spent on a failed idea.

Phase 1: Technological Feasibility

At this stage, we focus on assessing the technology rather than optimizing every detail. Factors like power consumption are less important. We use standard components to avoid expensive custom solutions. The goal is to quickly determine whether the chosen technology is viable.

Phase 2: Refinement and Optimization

Here, we take a more detailed approach, evaluating each component alongside the software. Can we adjust parameters to lower power consumption? Software often plays a key role in this phase. The objective is to qualify and refine the prototype before moving forward.

Phase 3: Pre-Production Prototype

Now, we start working towards a production-ready prototype. This advanced prototype closely resembles the final product in design, functionality, and materials. It is used to test and validate the production process before scaling up to mass production.

The strength of our approach is that the testing phase carries low risk. We stay in close collaboration with the customer throughout the process, continuously assessing whether to move forward or halt development if necessary.

By failing early, learning fast, and iterating efficiently, we help businesses turn ideas into reality – without unnecessary risk.

Watch Bent Bisballes introduction and example of a rapid prototyping course. 

Why use rapid prototyping in embedded? 

Starting a large project from scratch can be an expensive and risky endeavor. It often requires significant investments in both time and resources before you even know whether the solution works as expected.

An effective way to minimize this risk is to carry out a rapid prototyping process before committing to the entire project. A rapid prototype allows you to quickly test ideas, validate concepts, and identify potential challenges – all without a major financial investment.

Here are some good reasons for using rapid prototyping:  

1. Faster Time-to-Market 
   With rapid prototyping, you can test and improve ideas quickly. This means that your company can bring products to market faster than competitors, gaining a strategic advantage in industries with rapid technological development.

2. Lower Development Costs
   Instead of investing in custom-developed hardware and software from the start, standard components can be used to test concepts. This saves money and reduces the risk of misinvestments in failed ideas.

3. Better Decision-Making
   A physical prototype makes it easier to assess the potential of a product. It can be difficult to understand an idea solely from a PowerPoint presentation—but a functioning prototype provides a concrete foundation for strategic decisions.

4. Early Feedback from Users and Costumers
   With a quick prototype, you can test the product idea directly with potential customers, making it easier to tailor the solution to market needs. This means fewer iterations later in development and a product that hits the mark.

5. Lower Risk by Failing Early 
   By identifying and solving errors early in the process, you avoid bigger and more expensive problems later on. It’s all about testing, learning, and adjusting quickly before investing too much in a solution that might not work.

Can You Give a Concrete Example of an Embedded Rapid Prototype?

We were recently contacted by a client who wanted to use technology to improve the level of service in rehabilitation. They found that their physiotherapists often visited patients who had not completed their prescribed exercises. This led to wasted time and less effective rehabilitation processes.

The solution was a physical device that can be mounted on an exercise bike or a patient’s leg and, using machine learning, determines whether the user is running, standing, or cycling. With Long Range (LoRa) technology, we can wirelessly transmit small data packets over long distances with very low power consumption.

One of the client’s key requirements was minimal battery maintenance—physiotherapists should not have to constantly replace batteries. The goal is for the small device to function for several years on a single battery.

The device integrates into an existing network that physiotherapists already use, providing them with an operational overview and allowing them to focus on their core tasks instead of unnecessary travel. At the same time, it was crucial that the technical solution respects the privacy of patients. The focus is on nudging rather than surveillance, ensuring that the collected data serves as a basis for constructive dialogue between patients and physiotherapists.

What is your best advice to get started with rapid prototyping?

It almost sounds like a cliché but my advice is short and sweet: ” Think big, start small, learn fast”. 

• Think big – Have a clear vision of what you want to achieve, but avoid thinking too complex and specific in the beginning. Focus on the most important function that needs to be tested. 

• Start small– Use off-the-shelf hardware (e.g., Raspberry Pi, Arduino, ESP32) and open-source software to create a quick and cost-effective first version. Avoid designing custom hardware or writing too much code before testing the concept.

• Learn fast – Test your prototype with real users early, gather feedback, and adjust continuously. It’s better to discover mistakes now rather than later in the process.

  Want to know more about rapid prototyping? Or test a concrete business idea? Then reach out to Bent!

We change and transform business ambitions into concrete, digital solutions.

E-mail

Telefon

In a world where artificial intelligence (AI) traditionally requires large amounts of data processing and power, TinyML has emerged as a revolutionary technology. TinyML stands for “Tiny Machine Learning” and refers to the ability to run machine learning models on extremely small and energy-efficient devices. This technology enables advanced data analysis directly on microcontrollers and edge devices without the need for a constant cloud connection.

Mjølner’s Embedded Department recently invited a promising Danish researcher, Ph.D. student Emil Njor from DTU, to give a talk and share his knowledge in the field of TinyML. It led to an exciting technological discussion, covering tools such as compilers, models, algorithms, data, and hardware. Emil emphasized how the technology can be applied across sectors and how developments in supporting tools make it easier to develop TinyML based on existing systems. One very concrete outcome of Emil’s Ph.D. work is a framework for creating better datasets to evaluate the quality of a TinyML algorithm.

What is TinyML? 

Research in TinyML focuses on taking well-known algorithms and optimizing them so that they require minimal processing power and energy. This makes it possible to implement intelligent features in devices that were previously too limited to handle AI computations. This opens the door to a range of new applications within IoT, industrial systems, health technology, and smart products.

One of the major advantages of TinyML is its ultra-low power consumption, meaning that devices can run AI solutions for months or even years on a single battery charge. This is a game-changer for IoT and embedded systems, where battery life is often a significant challenge.

Embedded and TinyML: Make small devices smarter

Embedded development at Mjølner is about creating efficient, user-friendly, and optimized systems for specialized hardware. TinyML fits perfectly into this context because it allows for the integration of machine learning directly onto small, resource-constrained devices without the need for a cloud connection or with minimal cloud dependency.

Why Should Companies Consider TinyML?

At Mjølner, we already have projects and clients working with TinyML, but we also find that many companies are not yet ready to fully implement it. As a result, most of our client engagements start with a technology briefing, which helps identify the company’s competencies for launching TinyML projects.

Starting TinyML projects requires in-house technical expertise, but it also opens up exciting opportunities. With specialized knowledge in embedded resources, compiler optimization, and hardware customization, companies can create more efficient and innovative solutions, giving them a significant competitive advantage.

4 advantages with TinyML:  

• Reduce the need for constant cloud connectivity, thereby improving privacy and security, as data does not necessarily need to be transferred to the cloud.

• Minimize latency, as AI computations are performed directly on the device.

• Build robust systems that can operate even in offline environments.

• Save energy and resources, which impacts both operation and sustainability.

We Asked the Experts: Opportunities and Limitations of TinyML

The developers in our embedded department have an in-depth knowledge of TinyML and have worked with several clients to introduce it into their projects. As a result, they are well aware of the opportunities and limitations the technology brings.

The Future of TinyML

We are just at the beginning of TinyML’s potential. As the technology matures and more companies gain access to the necessary competencies, we will witness an explosion of new application possibilities. For businesses looking to stay ahead, now is the time to begin exploring TinyML and the advantages it can bring.

At Mjølner, we closely follow developments and help companies understand and implement TinyML in their solutions. Want to learn more about how TinyML can make a difference for your business?

With Domain-Driven Design (DDD), you place the focus of software development on the “domain,” meaning the specific business context in which the software operates. This can give you and your business an advantage in a complex market. But what exactly is Domain-Driven Design, and how do you use this approach? Let’s take a closer look.

Domain-Driven Design, or DDD, is an approach to designing and developing software that is deeply rooted in the company’s core area. At its core, DDD emphasizes collaboration between technical and business experts to create a shared understanding of the business domain and model software that accurately reflects it.

DDD is about building software that truly understands and solves the specific problems within a business. It involves breaking down complex business processes into manageable parts and creating software that mirrors these processes. By focusing on the company’s core areas, DDD ensures that the software is tailored to meet the unique needs and challenges the business faces.

Software that is precisely aligned with the business’s needs provides the company with much better opportunities to adapt and innovate – thus distinguishing itself from competitors. In short, DDD provides a business advantage in the market.

The Competitive Advantages of DDD: Customization, Flexibility, and Precision

By deeply understanding and modeling the business domain, companies can use Domain-Driven Design to respond to market changes more quickly. This agility can lead to faster time-to-market for new products and services, providing businesses with a significant advantage over competitors relying on more rigid off-the-shelf solutions.

Domain-Driven Design offers several benefits, making it a great choice for businesses with unique or complex needs:

In a world where companies are constantly striving to differentiate themselves, having software that is perfectly tailored to your business processes can be a game-changer. This allows you to achieve a level of precision and efficiency that standard solutions cannot match.

The close collaboration between business and technical teams also leads to better decision-making and more effective problem-solving. This collaborative approach ensures that the software not only meets the current business needs but is also able to evolve as the company grows and changes. In other words, there is a shorter path from business idea to digital action.

Why standard solutions aren’t always enough

The focus of the DDD approach on customization might sound expensive and cumbersome. Why not just use a standard system? Standard solutions like Customer Relationship Management (CRM) or Enterprise Resource Planning (ERP) are designed to meet common business needs. While they can be highly effective for many organizations, they often fall short when it comes to handling unique or complex business requirements.

As a business, some of the disadvantages of standard solutions can be:

At Mjølner, we have often encountered standard systems that, over the years, have been attempted to be adapted to handle processes they were never designed for. This can mean that the company becomes increasingly dependent on the system, and it may even result in the business and organization having to adapt to the system, rather than the other way around.

Improvement of Quality and Maintenance with Domain-Driven Design

Another important aspect of DDD is its positive impact on the quality and maintenance of software systems. By creating a clear and precise model of the business domain, DDD helps ensure that the software is built correctly from the start. Additionally, the modular nature of DDD makes it easier to maintain and update the software over time. As the system is divided into well-defined bounded contexts, changes can be made in one part of the system without affecting others.

DDD also promotes the use of best practices like Test-Driven Development (TDD) and Behavior-Driven Development (BDD), which further enhance the quality and reliability of the software. By thoroughly testing the software and ensuring it behaves as expected, the risk of errors is reduced, improving overall quality.

When it comes to long-term maintenance, DDD is an invaluable approach. By having a clear and well-defined model of the business domain, development teams can more easily understand and navigate the code – even when new developers join. This enables teams to make changes and additions without worrying about unintended consequences in other parts of the system. The clear structure and division into bounded contexts mean that each part of the system can be developed and maintained independently. This reduces complexity and enhances the system’s robustness.

Summary: Build Long-Lasting Software with DDD

Domain-Driven Design ensures that software remains relevant and effective over time. As the business evolves, the models and contexts defined in DDD can be adapted and expanded to meet new requirements and challenges. This enables companies to remain agile and responsive, even in a dynamic and changing market.

DDD is more than just a technical approach. It is a mindset that brings business-oriented and technical teams together to create software that truly meets the unique needs of the business. By focusing on the core business domain and fostering collaboration, DDD helps companies build software that is flexible, adaptable, and targeted. For business leaders, understanding and embracing Domain-Driven Design can lead to more efficient software solutions that deliver real business value.

Next time you face a complex business problem, consider whether DDD could be the right approach for your organization. Or give us a call. We’re happy to help turn your business ambitions into concrete digital solutions.