The challenge: Complex facilities are not only built from systems and equipment. They are built from information. When objects, signals, requirements, documents and responsibilities drift apart, technical debt is created before the facility is even in operation.
The effect: Traceability across systems, clear ownership, and a facility that can be integrated, maintained and developed throughout its lifecycle.
The Problem Is Not Lack of Data
Modern industrial and facility projects are becoming increasingly digital, connected and supplier-driven. Automation systems, building systems, production equipment, IT/OT networks, BIM models, SCADA platforms, data platforms and maintenance systems all create and consume technical information.
But in many projects, this information is not treated as a system in itself. Each supplier, discipline and platform structures information in its own way. Equipment has one name in the design model, another in the PLC, another in SCADA, another in the documentation, and a separate identity in the maintenance system. Signals are delivered without clear meaning. Requirements are written without traceability. Data is moved between systems without a defined owner.
Most projects already produce large amounts of data. The problem is that the data is often fragmented, inconsistent and difficult to trust. The result is technical debt built into the facility before it is even in operation.
The Same Pump, Eight Identities
Within a single project, one pump may exist as a physical object, a drawing symbol, a BIM object, a PLC tag, an OPC UA node, a SCADA object, a maintenance asset and a line in a supplier document. If these representations are not connected, the owner has no coherent understanding of their own asset.
The same pattern repeats for requirements, signals, alarms, documents, interfaces and handover data. When information is not structured, the facility becomes harder to own.
Data mapping is the work of saying: this is the same real-world object, expressed in different systems and data models.
Data Mapping Is the Activity, Not the Whole Solution
Data mapping is the practical work of connecting information between systems: a supplier tag to an OPC UA node, a BIM object to an asset record, a process signal to a historian tag. It is necessary, but not sufficient.
This is technical information architecture. Standards such as IEC 81346 provide the structural foundation: stable identities for objects, systems and functions that hold throughout the lifecycle.
Why It Matters for Asset Owners
Without a clear information architecture, the owner becomes dependent on suppliers, individuals and undocumented project logic. Future changes become slower, integrations more expensive and operations harder to manage.
With a clear information architecture, the owner can create traceability between systems, assets, requirements, documents and operational data. This makes it easier to commission the facility, maintain it, integrate new systems, analyse performance and continue developing the facility over time.
Technical information architecture is therefore not an IT issue. It is a lifecycle ownership issue.
HubMind’s Role
HubMind helps asset owners create structure where technical complexity would otherwise grow. We work across automation, IT/OT, BIM, asset management, requirements, supplier data and system integration.
Our role is to connect technical objects, signals, requirements, documents, responsibilities and systems into a coherent information structure that can be used throughout the facility lifecycle. The result is better traceability, clearer ownership, stronger integration and a facility that is easier to understand, operate and develop over time.
Need a structure your facility can actually be owned through?
HubMind helps asset owners align information modelling, master data ownership and governance so systems can integrate and operations can scale.
True digitalisation requires that electrical, HVAC, automation, IT and OT disciplines speak the same language and share the same information structures.
The challenge
Disciplines work in silos, each with their own tools, naming conventions and documentation – making integration expensive and data unreliable.
The solution
A cross-disciplinary approach based on shared standards (IEC 81346) and clear interfaces between disciplines.
The effect
Information that flows from sensor to decision support without manual translation – from the first project day to the last day of operation.
The Silo Problem in Complex Projects
Three Perspectives That Must Converge
In modern industrial and building environments, three perspectives must converge for digitalisation to succeed:
The technical perspective – How systems are built, what they do, how they communicate and what their interfaces are
The information perspective – How data is named, structured and made traceable across system boundaries
The organisational perspective – Who owns what, who decides what and how responsibility is allocated when disciplines meet
When only one or two of these perspectives are addressed, the result is a technically connected but informationally fragmented environment.
Getting the Disciplines to Work Together
The most effective tool for creating cross-disciplinary coherence is shared standards – particularly IEC 81346. By requiring that all disciplines use the same reference designation system, the same object appears with the same identity regardless of which system or discipline is looking at it.
Beyond standards, cross-disciplinary work requires:
Early involvement of all disciplines in information structure decisions
Clear requirements on suppliers regarding compliance with shared standards
Explicit ownership of cross-disciplinary information and interfaces
Verification that information requirements are met – not only that systems function
The Role of the Technical Owner’s Representative
In complex multidisciplinary projects, someone must hold the overall information picture on the owner’s side. This is exactly the role of a technical owner’s representative: to ensure that requirements, interfaces and information structures are defined before procurement, maintained during the project and verified at handover.
Without this role, each discipline optimises for its own delivery – and the interfaces between them are left to chance or to whoever ends up managing the integration.
The whole is greater than the sum of its parts. Future automation is not a question of individual products or suppliers. It is a question of architecture, structure and above all collaboration between people and systems. The one who succeeds in building the bridge between IT, OT and the actual business is the one who will extract the real gains from digitalisation.
Need to break silos between IT, OT and operations?
HubMind helps asset owners establish shared information structures, governance and delivery contracts so multidisciplinary teams can scale without rework.
A future-proof facility where lifecycle costs (LCC) are lowered and ROI on digitalisation is maximised. High interoperability creates a scalable digital infrastructure that makes you independent of individual suppliers.
The challenge
Technical facilities are drained of value when short-term choices create isolated silos. This technical debt leads to costly vendor lock-in, security gaps in legacy systems and data that is impossible to use for analytics.
The solution
Establishing genuine system ownership through strategic requirements management and information modelling. By paying down the debt, focus shifts from merely “keeping systems running” to actually developing the business.
Many facility owners and industrial operators believe they are investing in the future when they purchase new digital systems. But without a coherent strategy, you risk doing the opposite: building up technical debt that makes future innovation both more expensive and more difficult. Here we explain what technical debt means in a technical facility and how you start paying it down.
What Is Technical Debt?
The term “technical debt” describes what happens when you choose a quick, short-term solution over a well-structured approach. In industrial and building automation, this interest is paid in the form of expensive custom integrations, isolated data and systems that cannot communicate with each other – dramatically lowering your ROI on digitalisation.
Every time a shortcut is taken in a project, a new technical loan is taken out with high interest that future operations and asset management will be forced to pay.
It is important to distinguish deferred maintenance (not fixing what is broken) from technical debt. Technical debt arises when deliberate or unconscious architectural compromises are made – such as skipping a shared naming standard or accepting a closed integration – to achieve a short-term project goal. The price paid is reduced digital freedom of action.
Three Ways Technical Debt Arises in Your Facility
1. Structural Debt (Lack of Standards)
When different contractors are allowed to name objects and assets according to their own arbitrary systems, a debt arises that directly affects data governance. Without shared information modelling such as IEC/ISO 81346, your data becomes “dirty” and unusable for overall analytics. The interest: when you later want to introduce a digital twin or overall analytics tool, you must spend 80% of the budget on manually cleaning and remapping old data.
2. Architectural Debt (Silos and Point Integrations)
Solving specific problems with isolated apps instead of a well-thought-out API strategy creates a “spaghetti architecture”. Every new special solution reduces your interoperability – the ability of different systems to actually exchange information seamlessly. The interest: your IT environment becomes a spaghetti architecture where an update in one system risks bringing down three others, and nobody has the overall picture of how data flows.
3. Operational Debt – Lifecycle Debt
Installing a modern BMS system without a plan for how its network is to be managed – for example by the IT department – creates an enormous security debt. Retaining outdated legacy systems without an IT convergence plan is like driving a car that is never serviced. It drives up your lifecycle cost (LCC).
Requirements Management: The Bridge Between Governance and Reality
Many organisations have a strategic document for data governance that defines who should own what. But technical debt arises in the gap between these guidelines and the actual delivery in the project. This is where structured requirements management becomes decisive. You must not only “want” order; you must specify requirements for technical governance:
From ownership to requirements: If your strategy says you should have clear system ownership, requirements management must ensure the system is delivered with open APIs that enable this ownership in practice.
Quality assurance: Requirements management ensures the supplier delivers the metadata and information structures required to pay down the debt – not just a functioning physical component.
Warning Signs That Your Facility Is Living on Borrowed Time
“We can’t get the data out”: You have masses of sensors, but nobody can answer how they connect in real time
Innovation standstill: You want to introduce AI-based energy optimisation, but consultants say “the prerequisites are missing”
Consultant dependency: Only one specific person at one specific supplier understands how the system is structured
High LCC: Maintenance costs for “keeping the lights on” are consuming the entire budget for new development
Expensive interoperability: A simple integration that should take a week takes three months due to closed protocols
How to Start Paying It Down
Set technical standards: Decide which technical standards will apply in all future procurements. By requiring structure according to ISO/IEC 81346, you pay down structural debt from day one.
Build IT-ready networks: Ensure your building automation rests on a secure IT foundation. This removes security debt and enables safe integration.
Specify interoperability: Stop buying closed systems. Require open APIs and standardised information modelling in every new procurement to break vendor lock-in.
Establish data governance: Decide who owns the definition of your data. By following ISO/IEC 81346 you create a sustainable structure that survives individual system replacements.
Technical debt is not an IT problem – it is a business risk. By starting to clean the digital foundations today and paying down your legacy systems, you ensure your facility is relevant and optimisable tomorrow.
Can you afford to let technical debt grow in your facilities?
Technical debt arises when information is allowed to become stuck in disciplinary silos. Every time a shortcut is taken in a project, a new technical loan is taken out with high interest that future operations and asset management will be forced to pay.
In the role of technical owner’s representative and Owner’s Representative, HubMind supports you in establishing genuine system ownership, securing the right requirements and creating sustainable data governance for your technical facilities.
Standardisation is not an administrative obstacle but the engine that makes complex digitalisation possible in practice.
The challenge
Without shared standards, every project creates its own structures, leading to fragmented data and fragile integrations.
The solution
By using established frameworks such as IEC 81346 and IEC 81355, a shared information foundation is created that holds over time.
The effect
A “Digital Thread” – an unbroken chain of information that makes your facilities easy to understand, manage and develop further.
Digitalisation as Everyday Reality – and Complexity
Digitalisation, integration and automation are today no longer future issues. They are part of everyday life in building automation, BMS, industrial automation, energy systems, infrastructure and traditional IT environments. IT systems, OT systems, control systems, sensors and digital platforms are connected over IP-based networks and share data in real time.
Standardisation is sometimes perceived as administrative or constraining. In practice it is the opposite.
Technically, this is rarely the biggest obstacle. Most organisations can collect data, build integrations and automate processes. The challenge arises over time. Solutions that work well at commissioning gradually become difficult to understand, change and develop further. Documentation loses currency, integrations become fragile and dependence on specific individuals increases.
The problem is rarely the technology itself. The problem is the lack of shared structures for how systems, information and documentation are organised.
Standardisation as Enabler, Not Constraint
Standardisation is sometimes perceived as administrative or constraining. In practice it is the opposite. Standardisation is what makes complex technical environments possible to understand, manage and develop over time.
When digitalisation spans multiple technology domains, there is a need for shared principles: how a system is bounded, how objects are identified, how information is classified, how traceability is ensured when systems change. Without shared standards, every project and every supplier develops its own structure. The result is fragmentation, increased management costs and integration solutions that do not scale.
Structure Before Technology Selection
In many digitalisation and automation initiatives, the focus lands on technology selection. Platforms, protocols and products are analysed in detail, while questions about structure, classification, metadata and document management fall into the background. This leads to systems that are technically integrated but informationally fragmented. Documentation becomes hard to use. Data loses its context. Every change requires extensive analysis.
Standardisation in this context is not about controlling the technology, but about creating a shared information foundation that makes the technology usable over time.
IEC 61355 and IEC 81355 as the Foundation for Documents and Information
IEC 61355 has long been an established standard for the classification of technical documentation. IEC 81355 builds on the same basic principles but is better suited for digital information management and complex system environments. It provides clearer support for how information can be structured so that it is usable over time, regardless of technology domain. In practice, many organisations today manage existing facilities according to IEC 61355 while new projects are based on IEC 81355 – requiring a conscious strategy for information management during change and further development.
IEC 81346 and Stable System Identity
While IEC 61355 and IEC 81355 focus on documentation and information classification, IEC 81346 addresses how technical systems are structured and identified. The standard describes how function, product and location can be distinguished and identified in a consistent manner. The purpose is to create stable identities that hold over time, even when systems are rebuilt, relocated or further developed.
ISO Standards for Information Management
Beyond the IEC standards, several ISO standards complement the picture:
ISO 82045 – How technical documentation should be identified, version-managed and exchanged in a controlled manner
ISO 15489 – Information management over the entire lifecycle; documentation as business information with clear responsibility and traceability
ISO 19650 – How information is organised, structured and shared over the lifecycle in built and technical environments (often associated with BIM)
ISO/IEC 11179 – Metadata and shared concept definitions; central to master data and ensuring different systems interpret information the same way
Digital Thread Through the Lifecycle
The concept of a digital thread describes how information is kept together throughout the entire lifecycle – from concept and design to installation, operation, change and decommissioning. A digital thread is not a product or platform. It arises when objects, documents and data have stable identities and clear relationships. Standards for structure, documentation and metadata are what makes the digital thread possible in practice.
Master Data, Aliases and Tag Management
In integrated IT, OT and automation environments, the same object often appears in several systems. Different names, tags and designations are used in parallel.
Master data covers the fundamental definitions of objects, functions and properties that must be shared regardless of system. By separating an object’s identity from its presentation in different systems, alias and tag management becomes manageable. This is a structural question rather than a technical speciality, and it is decisive for traceability and long-term integration.
Beyond standards for document structure and metadata, there are also frameworks that address lifecycle governance and management of technical assets. The ISO 55000 series describes how organisations should manage assets across the entire lifecycle, from planning to decommissioning. IEC 62890 focuses specifically on lifecycle management of systems and products, including modernisation and change over time.
These standards complement the IEC and ISO standards for structure and information management by clarifying how information is used as a basis for decisions in operation, change and circular asset management.
Digitalisation as an Enabler of Circular Asset Management
When information follows the systems through their entire lifecycle, the view of technology and products changes as well. Systems and components become managed assets with a known history.
At the point of change or decommissioning, there is then a basis for deciding what can be reused, upgraded or recycled. Circular asset management emerges as a consequence of structured information management, not as a separate sustainability initiative.
Digitalisation without structure often leads to shorter lifespans and increased waste of resources. Digitalisation built on standards instead creates the conditions for circular flows.
Common Reasons It Does Not Hold Over Time
Despite good intentions, standardisation is often introduced late, when the systems are already built. Focus lands on technical integration while information structure and responsibility are left unclear. Suppliers are allowed to use their own terminology and document structure.
The result is solutions that work here and now, but that are difficult to maintain and develop further.
When Structure Becomes a Long-Term Capability
Digitalisation, integration and automation are ultimately not about more systems. They are about the capability to understand, change and manage technology over time. Standards for structure, documentation, metadata and information governance create traceability throughout the lifecycle. They enable the digital thread in practice and lay the foundation for both effective operations and circular asset management.
Organisations that establish this foundation early are better positioned for future changes, whether driven by new technology, new requirements or increased sustainability ambitions.
What to require in your next project
Before selecting a platform or supplier, make these five decisions explicit:
Identity: define how systems, objects and locations will be identified across disciplines.
Information: specify required metadata, document classes and naming rules.
Interfaces: require open, documented interfaces and clarify ownership of each data flow.
Verification: turn the standards into acceptance criteria that can be tested at handover.
Lifecycle ownership: appoint who maintains identities, mappings and rules after commissioning.
If one of these decisions is missing, the project is likely to create a new integration problem for operations to solve later.
Is your digitalisation journey built on a solid foundation?
Without shared standards, integration and automation become both costly and difficult to manage. We help you navigate between requirements specification and practical implementation to create a sustainable technical architecture.
Without order in information (Digitalisation) and clear relationships (Integration), governance (Automation) will never be effective.
Digitalisation
is about information – making data comprehensible, traceable and useful across the entire lifecycle.
Integration
is about context – connecting systems and flows with clear interfaces and responsibilities.
Automation
is about governance – letting systems act independently based on logic and reliable data.
Digitalisation as a Concept
Digitalisation is one of the most used concepts in contemporary discussions about technology, business development and the future. At the same time, it is one of the most elusive. For some, digitalisation means replacing paper with systems. For others it is about data analytics, automation or new business models. In many contexts, the term is used as a catch-all for anything perceived as modern or technically advanced.
This is why the sequence matters: first create order in information, then connect systems with clear interfaces, then let logic act on reliable data. Inverting this order leads to automation that amplifies uncertainty rather than creating clarity.
In technical environments this becomes particularly clear. Digitalisation can refer to anything from building automation and industrial control systems to IT platforms, integrations and decision support. When the same word is used for such different things, misunderstandings easily arise between business, IT, OT and suppliers.
Why the Concepts Are Often Mixed Up
Digitalisation, integration and automation are closely related, but describe different things. In practice, they are often used interchangeably to describe the same initiative. A project can be described as a digitalisation project even though it is mainly about integration. Automation is sometimes used to describe remote monitoring, while integration is reduced to technical connections.
This lack of precision leads to projects where the objectives, the work and the deliveries are never aligned. When digitalisation, integration and automation are described separately and in relation to each other, the conversation becomes more productive – for business, IT, OT and suppliers alike.
Digitalisation in Technical Environments
In technical environments, digitalisation primarily means making information about systems and facilities available in a structured, usable and long-term form. It is not primarily about installing new systems. It is about how information is organised, owned and used.
Digitalisation creates the conditions for integration and automation by ensuring that data has meaning, context and traceability. Without this foundation, integration becomes a technical puzzle that must be rebuilt with every change, and automation risks acting on incorrect or misunderstood data.
Integration as Architecture
Integration in technical environments is not just about connecting systems. It is about creating structures where information flows in a controlled, comprehensible and maintainable way. Well-designed integration means clear interfaces, defined data flows and explicit responsibility for what is sent, received and handled in each system.
When integration is treated as architecture rather than as individual technical connections, the result is more robust, scalable and possible to change without needing to rebuild from scratch.
Automation as the Expression of Logic
Automation is the layer where information and integration create visible value. Systems act on data, logic governs processes and operations are monitored and improved in real time. But automation is only as reliable as the data it acts on and the integrations that deliver that data.
This is why the sequence matters: first create order in information (digitalisation), then connect systems with clear interfaces (integration), then let logic act on reliable data (automation). Inverting this order leads to automation that amplifies uncertainty rather than creating clarity.
A Lifecycle Perspective
The relationship between digitalisation, integration and automation is not static. As facilities develop, systems are replaced and new requirements arise, all three dimensions must be managed over time. This requires a lifecycle perspective where decisions today are made with an awareness of their consequences in ten years.
Organisations that succeed with this work combine strategic thinking about information and architecture with practical execution in projects – always with the whole picture in mind, not just the current deliverable.
Is your digitalisation built on the right sequence?
We help organisations clarify what digitalisation, integration and automation actually mean in their specific context – and how the three can be built in a sequence that creates sustainable results rather than new technical debt.
Successful integration is more about trust and clear processes than just network cables.
The challenge
IT and OT have different priorities; IT focuses on data security and confidentiality, while OT prioritises real-time operations and availability.
The solution
A clear boundary definition and a shared governance model that respects both disciplines’ needs.
The effect
A secure and stable environment where control systems are protected by IT standards without risking the operation of the facility.
Organisation, Competence and Responsibility in Tomorrow’s OT Environments
As automation systems become IP-based, it is not only the technical architecture that changes, but also the organisation’s allocation of responsibility. BMS systems increasingly use the same networks, the same security mechanisms and the same infrastructure as enterprise IT. The IT organisation thus becomes a direct prerequisite for building automation to function – regardless of whether this is formally stated or not.
This is fundamentally a management and governance question, not a technical detail.
From Enterprise IT to a Shared Platform
Traditionally, the IT department’s remit has been clearly tied to enterprise IT: users, clients, servers, applications and networks for office and business systems. Building automation and BMS have often been managed by facility management, operations teams or external suppliers, with their own systems and working methods.
When BMS becomes IP-based, this boundary is erased. The IT infrastructure becomes the shared platform for OT systems as well. This means decisions about networks, addressing, security and changes directly affect the building’s function. In practice, IT is already involved in OT operations – even if the organisation is not always structured for it.
Different Logics – IT and OT Have Different Prerequisites
A fundamental challenge is that IT and OT have historically been governed by different logics.
IT environments are often characterised by: frequent updates, standardised platforms, acceptance of planned outages, and focus on security updates and lifecycle management.
OT environments, by contrast, are characterised by: long lifespans, high requirements for continuous operation, limited tolerance for change, and systems directly linked to physical function.
When these perspectives meet without adaptation, friction arises. Operational disruptions, ambiguous decisions and gaps in responsibility are often organisational problems rather than technical ones.
Patching and Change – An Organisational Key Issue
One of the clearest areas where IT and OT logic differ is patching and change management. In IT, regular patching is a natural part of security work. In OT, the same update can mean risk of downtime, unforeseen side effects or compatibility problems. An outage in a BMS system affects not only IT functions, but also comfort, energy consumption and sometimes safety functions in the building.
When OT systems are on the same network and managed through the same processes as IT, adapted procedures are therefore required:
Separate change windows for OT
Requirements for testing before updates
Clear coordination with OT managers before changes to infrastructure
This is fundamentally a management and governance question, not a technical detail.
Competence – Mutual Understanding Rather Than Dual Expertise
A common mistake is trying to create roles that must fully master both deep IT competence and deep OT competence. In practice this is difficult to maintain and often leads to dependencies on individuals. A more sustainable strategy is to build mutual understanding:
IT needs to understand OT systems’ requirements for stability, lifespan and consequences of outages
OT needs to understand IP networks, addressing, certificates, segmentation and security principles
Specialist competence remains within each area, but with clear interfaces for collaboration
Organisational Models That Work in Practice
Organisations that succeed with IT/OT convergence often have a clear allocation of responsibility. IT is responsible for the platform: network infrastructure, IP addressing, DNS and DHCP, basic cybersecurity, certificate management and segmentation. OT is responsible for the systems: BMS function and logic, availability and performance requirements, validation of changes from an operations perspective. Shared responsibility covers: change management, incident management, documentation and lifecycle management.
The decisive factor is not exactly how the organisation is structured, but that responsibilities and decision paths are clear.
Common Mistakes
Moving OT to IT without changing working methods – IT applies existing processes without regard for OT systems’ operational reliability requirements
Unclear responsibility between IT and OT – Nobody owns the whole picture, leading to decision gaps and delays
Changes implemented without OT alignment – Technically correct changes have unwanted operational consequences
Overconfidence in hybrid roles – Individuals are expected to cover the entire competence spectrum without organisational support
Treating IT/OT convergence as a technology project – Organisational questions, training and governance are deprioritised
Who bears responsibility when the building goes digital?
When the IT department gets responsibility for the building’s OT environment, new challenges arise around security, lifecycles and operational responsibility. We help you define the processes and requirements that make the handover and daily management a success rather than a source of conflict.
The network is not just a cable – it is the backbone of your digital facility strategy.
The challenge
Traditional BMS networks are often isolated and lack the security and bandwidth required for modern digitalisation.
The solution
By building an IT-ready infrastructure with clear segmentation, a stable platform is created for tomorrow’s control systems.
The effect
Enables secure system integration, remote control and real-time analytics without compromising operational security.
Modern IP Infrastructure for Commercial Properties – The Foundation for Tomorrow’s BMS
Building automation has long been built on traditional fieldbus protocols such as Modbus, M-Bus and similar technologies. These systems have been robust and relatively easy to maintain, but have been limited in terms of integration, scalability and access to data outside the system itself.
A modern BMS system is no longer an isolated technical system. It is a network-dependent platform that requires the same structural care as other critical IT infrastructure.
With the transition to IP-based BMS systems, the conditions change fundamentally. Communication takes place over Ethernet, often with standardised protocols, and systems become part of the organisation’s overall IT environment. This opens up new possibilities in analytics, optimisation and integration – but also places clear demands on network design, security and operating principles.
A modern BMS system is no longer an isolated technical system. It is a network-dependent platform that requires the same structural care as other critical IT infrastructure.
IP-Based vs Proprietary Networks
Traditional automation systems are often built on specialised networks and protocols adapted for a specific purpose. IP-based Ethernet instead means: individual addressing of every device (e.g. with IPv6), better support for integration between different systems and suppliers, and use of standardised protocols with broad market acceptance and long lifespans.
When BMS communicates over IP, the system ceases to be technically isolated. It becomes part of the shared network infrastructure and is directly affected by how that network is designed, monitored and managed.
DNS and DHCP – More Than Supporting Functions
In IP-based automation environments, DNS and DHCP are no longer peripheral support services. They form a central part of the infrastructure: managing large volumes of connected devices, creating a readable, traceable and structured address environment, and enabling automatic updates of names and addresses via dynamic DNS.
Without a well-thought-out strategy for DNS and DHCP, the environment quickly becomes difficult to oversee. With standardised naming conventions, DNS can also be used as an active tool for documentation and structure, where names reflect function, system membership and location.
Secure Infrastructure – Encryption, Certificates and Segmentation
When BMS devices connect to the IP network, the attack surface increases. Systems that were previously physically or logically isolated are now accessible via the network, requiring an entirely different security mindset. Fundamental principles for a secure BMS infrastructure include:
Central certificate management, rather than local manual solutions
Security in OT environments cannot be reduced to individual firewall rules. It must be built into the network architecture from the start and take into account both the threat landscape and operational safety.
Technical Maturity – Standards, Tools and Processes
IP-based building automation requires greater technical maturity than traditional solutions. A modern BMS environment needs, among other things: standardised communication protocols such as OPC UA or MQTT, monitoring and visibility of both network and systems, and continuous risk assessment linked to changes and updates.
Established IT principles such as defence-in-depth and zero trust must be applied with an understanding of the OT environment’s requirements. Security and stability must be balanced, not set against each other.
Common Mistakes
Assuming office IT principles work unchanged in OT environments – Automatic patches and rapid changes can have direct operational consequences in BMS systems
Underestimating the need for network segmentation – Inadequate separation increases both security risks and the risk of unintentional impact
Lacking a clear strategy for addressing and DNS before implementation – Unstructured solutions lead to increased operating costs and difficult fault-finding
Treating OT security as purely a firewall question – Without a holistic view of certificates, encryption and zone division, protection becomes fragmented
Is your BMS network ready for the next step?
A modern control system is only as strong as the network it communicates on. We help you bridge the gap between traditional building technology and modern IT architecture – from requirements specification to operational network.
