1.  Introduction: Why This Matters to You

If we have spent our career in enterprise IT, our world is built on predictable abstractions. We deal with REST APIs, cloud microservices, Docker containers, JSON payloads, and CI/CD pipelines. When we need two software systems to talk to each other, we pull up a Postman collection, write a lightweight service in Python or Node.js, and deploy it. Then we walk into a manufacturing plant, an oil refinery, or a power distribution facility, and it feels like stepping back into 1995.

In Operational Technology, systems do not talk over HTTP the way we are used to. They communicate over physical serial lines, deterministic industrial fieldbuses, or legacy proprietary protocols that were designed long before anyone thought about REST or JSON. For years, bridging the factory floor and enterprise IT required expensive middleware, proprietary OPC servers, and tedious manual configuration.

Then Node-RED entered the picture. If we have heard this name thrown around by our OT colleagues, we might wonder what it actually is, and why it has quietly taken over so much of the industrial landscape. This article breaks it down without the vendor fluff, from the perspective of someone who has spent decades bridging the gap between hardware and software, and who now looks at every one of these deployments through an OT cybersecurity lens.

I wrote this for OT cybersecurity practitioners or security researchers who came up through IT security and are still building their intuition for the industrial environment. Node-RED is a perfect case study, because it sits exactly on the seam between IT and OT, and understanding it well will sharpen how we think about every other IT to OT integration we are asked to secure.

2.  Where Node-RED Came From

Node-RED was not born inside a high-voltage substation, and it did not come out of a PLC manufacturer's research lab. It started in early 2013 as a side project by Nick O'Leary and Dave Conway-Jones inside IBM's Emerging Technology Services group.

At the time, the team was constantly building experimental IoT prototypes. Every new project meant rewriting the same boilerplate code just to shuttle messages back and forth between hardware sensors, MQTT brokers, and web services. Frustrated by this repetitive digital plumbing, Nick built a lightweight visual prototype over a weekend using Node.js to draw connections between topics.

By September 2013, IBM open sourced the project. It gained real momentum and eventually became a foundational project under the JS Foundation, which later merged into the OpenJS Foundation, in 2016. It was released under the Apache 2.0 license, which is why the global developer community has been free to contribute new nodes and functionality ever since. What began as a tool to map MQTT messages turned into the leading event driven, flow based visual integration engine for the physical world.

Today, thousands of community developed nodes exist for everything from Modbus and OPC UA to Siemens PLCs, MQTT brokers, SQL databases, cloud platforms, and dozens of other industrial protocols.

3.  What Node-RED Actually Is

At its core, Node-RED is a browser based, flow based programming environment built on top of the Node.js asynchronous runtime. Instead of writing lines of code to handle socket connections, data parsing, and protocol handshakes, we drag pre built functional blocks, called nodes, onto a canvas, wire them together, and click deploy.

Each node performs one specific job. One node might read a value from a PLC. Another processes that value. A third stores it in a SQL database. A fourth sends an email alert. A fifth publishes the result to an MQTT broker. By connecting these nodes together, we can build workflows that would otherwise take days of coding in a matter of minutes. Think of it as building an application out of Lego blocks instead of machining every component ourselves.

3.1  Misconceptions

Before we go any further, let us clear up a few misconceptions that IT engineers commonly carry into their first OT project involving Node-RED.

• A - Misconception 1: It is a SCADA or DCS Replacement : It is not, and this is the single most important distinction in this entire article. SCADA, which stands for Supervisory Control and Data Acquisition, and DCS, which stands for Distributed Control System, are heavy duty, high availability, deterministic control engines. They execute real time closed loop control, manage safety instrumented systems, and handle strict alarm states with guaranteed timing. Node-RED is not a control engine. It is a data pipeline and orchestration engine. It sits around SCADA and DCS, not in place of them.
  
• B - Misconception 2: It is Just a Toy for Home Automation Hobbyists : While home automation enthusiasts genuinely do love running Node-RED on Raspberry Pi boards, industrial vendors now bake it directly into production grade hardware. Devices like the Siemens IOT2050 and the Phoenix Contact PLCnext, along with a growing list of industrial edge gateways, run Node-RED natively inside real factory environments.
  
• C - Misconception 3: Visual Programming Means It Is Limited: Underneath that drag and drop canvas, every node passes a standard JavaScript object, typically carrying a msg.payload. If a pre built node does not do what we need, we can drop in a Function node and write full, unconstrained asynchronous JavaScript. There is very little that Node-RED cannot eventually be made to do, which is exactly why it deserves the same security scrutiny we would give any general purpose scripting environment.

3.2  A Good Analogy for OT Newcomers

Picture a production line this way. The PLC is the machine operator, carrying out the exact physical steps it was programmed to do, scan after scan. SCADA is the supervisor, watching the operation and giving high level direction. Node-RED is the translator and coordinator, making sure information keeps flowing between all these different systems efficiently. It does not run the machine and it does not supervise the process. It makes sure everyone in the room can understand each other.

4.  Who Uses Node-RED, and Where It Lives

Node-RED was originally created for developers and integrators who needed a fast, event driven way to wire together hardware devices, APIs, and online services. It was never marketed specifically at plant floor engineers, but that is exactly where a large part of its user base ended up.

Its primary audience splits into two camps that we, as OT cybersecurity professionals, need to recognize immediately when we walk a plant floor.

The first camp is OT engineers and automation specialists, meaning technicians who understand physical machinery and field protocols but are not necessarily expert software developers writing raw C# or Python applications.

The second camp is IT integrators and solution architects, meaning engineers tasked with pulling data out of isolated plant networks and feeding it to cloud data lakes, ERP platforms, or local analytics databases. Node-RED gives both camps a common tool, which is precisely why it spread so fast.

In practice, we see it adopted by industrial automation engineers, control system engineers, SCADA engineers, IIoT architects, OT engineers, manufacturing digital transformation teams, building management system engineers, energy management engineers, system integrators, industrial software developers, and increasingly, OT cybersecurity teams themselves, who use it to build lightweight monitoring and alerting flows. Major industrial vendors now support or integrate Node-RED directly into their own ecosystems, especially within Industrial IoT and edge computing product lines.

We find Node-RED running everywhere IT and OT intersect. That includes manufacturing plants, oil and gas facilities, power generation plants, water treatment facilities, smart buildings, renewable energy sites, data centers, smart factories, industrial IoT gateways, and edge computing devices generally. On the hardware and platform side, it commonly runs on industrial PCs, virtual machines, Linux servers, Windows servers, Docker containers, Raspberry Pi boards, industrial edge devices, and cloud virtual machines.

4.1  OT Embraced It in Solving the Industrial Data Problem

To understand why the industrial world embraced Node-RED so quickly, we need to understand the pain of traditional OT integration that came before it. For decades, industrial automation relied on rigid, vendor locked software. If we wanted to read a register from a Siemens PLC and send that value to a SQL database or a REST API, we typically had to buy an expensive OPC server license, often priced per tag or per device, configure a separate piece of middleware mapping software, and then pay an integration consultant a substantial fee to build custom data extractors.

Node-RED shattered that model. Through its open source package ecosystem built on npm, the community wrote custom nodes for nearly every industrial protocol in existence, including Modbus, Siemens S7, EtherNet/IP, OPC UA, BACnet, and DNP3. Now, an engineer can read an S7 data block directly from a PLC, transform the raw binary array into a clean JSON object, and push it over MQTT or HTTPS to a cloud IoT endpoint in about fifteen minutes, with zero license fees.

There is a second, equally important reason for its popularity, which is the sheer diversity of vendors sitting on a typical plant floor. One production line may run Siemens PLCs. Another uses Rockwell. A packaging machine might use Mitsubishi. Energy monitoring may come from Schneider Electric. The SCADA layer could be Ignition or AVEVA. Enterprise reporting may depend on Microsoft SQL Server, while predictive analytics runs somewhere in the cloud. None of these systems naturally speak the same language. Node-RED acts as the integration layer, speaking multiple industrial and IT protocols at once, which dramatically reduces both integration time and development cost.

5.  Placing Node-RED on the Purdue Model

Before we look at real deployments and their risks, we need a shared reference point. Most of us coming from IT security already know the Purdue Enterprise Reference Architecture in passing, but it is worth walking through it again with Node-RED specifically in mind, because where we choose to put a Node-RED instance changes the entire risk conversation.

The extended Purdue Model breaks the industrial environment into levels. Level 0 is the physical process itself, the sensors and actuators touching the product. Level 1 is basic control, meaning the PLCs and RTUs executing logic in real time. Level 2 is area supervisory control, where our HMI and local SCADA screens live. Level 3 is site operations, covering historians, engineering workstations, and plant level MES functions. Level 3.5 is the industrial demilitarized zone, a segmented buffer that most modern reference architectures insert specifically to broker traffic between OT and IT rather than letting it cross directly. Level 4 and Level 5 are business and enterprise IT, where ERP, email, and corporate cloud connectivity live.

 5.1  Common Purdue Violations We See in the Field

Because Node-RED is so easy to install, it tends to get placed wherever it is most convenient for the engineer building the flow, not wherever the architecture says it should sit. We consistently see four patterns that violate Purdue segmentation, and each one deserves its own line item in a risk assessment.

• A Node-RED instance installed directly on an HMI or engineering workstation at Level 2, with an outbound MQTT connection to a public cloud broker, collapsing four Purdue levels into one host.
• A Node-RED gateway with a Modbus TCP connection straight into a Level 1 PLC network, and a second network interface bridged onto the corporate LAN, effectively becoming an unmanaged Level 3.5 crossing point that nobody approved as one.
• Shadow Node-RED instances running on a spare industrial PC under a desk, invisible to the asset inventory, quietly polling Level 1 or Level 2 devices and forwarding data to a personal cloud dashboard.
• Node-RED flows that accept inbound webhook or HTTP triggers from Level 4 or Level 5 and use them to write values back down to Level 1 registers, turning what should be a one way historian feed into a two way control path.

None of these deployments are hypothetical. We have found variations of every one of them during ICS security assessments. The pattern is always the same. Someone with good intentions and a real operational need reaches for the fastest tool available, and Node-RED is almost always the fastest tool available, so it ends up carrying more architectural weight than anyone planned for it to carry.

6.  How Node-RED Actually Helps Industrial Automation

Rather than replacing existing automation systems, Node-RED extends what they can already do. It can collect data from PLCs using Modbus TCP or OPC UA, process that data, store it in a database, generate dashboards, publish readings over MQTT, send alerts through Microsoft Teams or email, invoke REST APIs, and forward selected information to cloud platforms such as Azure or AWS.

It also enables lightweight edge computing by doing local calculations before sending only the meaningful data upstream. This reduces network bandwidth and cuts latency while still preserving the operational insight that matters. Because these workflows are built visually, engineers can develop and modify integrations far faster than they could with a traditional software development cycle.

6.1  Practical Example: A Cement Plant Conveyor System

Consider a cement manufacturing plant running several conveyor systems controlled by Siemens PLCs. Motor temperature, bearing vibration, and current draw are all continuously monitored. Using Node-RED, the workflow could look like this. The platform periodically reads operational values from the PLC over OPC UA. If a bearing temperature exceeds a predefined threshold, Node-RED checks whether the condition holds across several consecutive readings, which filters out transient spikes rather than reacting to noise.

Once the condition is confirmed, several things happen at once. The event is logged to a SQL database, an incident record is generated through a REST API, an email goes out to the maintenance team, an MQTT message is published to the maintenance dashboard, and the event is forwarded to the organization's analytics platform. No PLC logic needs to change. No changes are required to the SCADA application. Node-RED is simply orchestrating the flow of information between the operational systems and the business applications sitting above them. This ability to bridge OT and IT without touching certified control logic is one of its greatest strengths.

6.2  Practical Example: Predictive Maintenance on a Legacy Pump

• A- The Problem : A plant has a twenty year old critical water cooling pump controlled by a legacy PLC over Modbus RTU serial. The maintenance department wants to install a modern wireless vibration and temperature sensor on the pump bearing to feed a machine learning model in the cloud for predictive maintenance. The legacy PLC has neither the memory nor the connectivity to process this extra data, and modifying its certified code would cost real money in re-testing and requalification.
  
• The Node-RED Solution : An edge gateway running Node-RED is installed inside the local control panel. One flow input uses a Modbus node that polls the legacy PLC every five seconds to read the operational state, meaning pump running or stopped, and motor current. A second flow input is an MQTT node that listens for vibration data published by the new wireless sensor mounted on the bearing. A Function node then combines these two asynchronous streams, checking whether the pump is actually running before it formats a single JSON payload, something like this.

 That payload is then pushed over a secure TLS encrypted HTTPS POST request to an enterprise cloud API gateway, which triggers an alert if vibration spikes past a safe operational limit. The entire integration happens at the edge, without touching a single line of certified PLC code or purchasing proprietary middleware. Note that in Purdue terms, the correct place for this gateway is right at the Level 3 or Level 3.5 boundary, reading up from Level 1 and pushing out to Level 4 and 5, never accepting inbound write commands from the cloud side back into the PLC.

7.  Node-RED vs. Traditional SCADA: Choosing the Right Tool

The industrial automation landscape is genuinely shifting. Established SCADA and HMI platforms such as FactoryTalk View, Siemens WinCC, Advantech WebAccess, and AVEVA's Movicon based products have dominated plant floors for decades, and Node-RED has emerged as a real contender in specific parts of that landscape. As automation and OT security professionals, the question we actually face is not which tool wins, it is when we should reach for Node-RED's flexibility and when a traditional SCADA platform remains the right call.

7.1  Why Node-RED Keeps Gaining Ground

Node-RED's visual programming model lowers the barrier between IT and OT teams. A maintenance technician with limited coding experience can build a working dashboard to monitor equipment health without waiting weeks for an IT department or paying for a consultant engagement. It is also protocol agnostic, with native support for Modbus, OPC UA, MQTT, REST APIs, and a long list of industrial protocols, plus straightforward integration into AWS IoT, Azure IoT Hub, and Google Cloud, and direct connectivity to SQL Server, MySQL, InfluxDB, and MongoDB without extra middleware.

The economics matter too. Node-RED's core is open source and free, it runs on anything from a Raspberry Pi to an enterprise server, there are no per tag licensing fees, and the community driven model reduces vendor lock in. Traditional SCADA, by contrast, often carries licensing costs that run from the tens of thousands of dollars into six figures per server, per tag or per connection fees that scale with plant size, proprietary hardware requirements, and annual maintenance contracts that typically run fifteen to twenty percent of the license cost. Node-RED's drag and drop interface also supports proof of concepts in hours rather than weeks, iterative development with immediate visual feedback, version control through Git, and containerized deployment through Docker.

7.2  Why Traditional SCADA Still Holds Its Ground

Enterprise SCADA platforms offer round the clock vendor support with guaranteed response times, redundancy and failover capabilities that have been tested in demanding industrial environments, and change management systems with audit trails and validation workflows built in. Regulated industries such as pharmaceuticals, food and beverage, and nuclear power depend on this. They need FDA 21 CFR Part 11 compliance for electronic records, ISA-88 and ISA-95 standard compliance for batch processing, pre validated modules that shorten qualification time and reduce risk, and professional services for validation documentation.

There is also the maturity argument, which should not be underestimated. Traditional platforms benefit from decades of industrial deployment experience, established training and certification paths, a large pool of skilled integrators and consultants, and proven architectures for complex multi site deployments. On top of that, modern SCADA platforms offer sophisticated graphics engines with three dimensional visualization, mobile responsive interfaces, advanced alarming with escalation and acknowledgment workflows, and deep historian integration for trending and analytics.

7.3  A Practical Decision Framework

7.4  The Hybrid Approach Most Mature Plants Land On

In practice, the organizations we see doing this well are not choosing one platform over the other, they are running hybrid architectures. Node-RED handles edge computing and data preprocessing, and covers cloud integration and advanced analytics. Traditional SCADA keeps ownership of the core HMI and control functions, and stays firmly in charge of anything compliance critical. This division of labor gives us the flexibility of Node-RED where it earns its keep, while keeping industrial grade reliability exactly where it matters most.

Looking ahead, we expect the two worlds to keep converging. Traditional vendors are already adopting visual programming concepts of their own, open source solutions are becoming steadily more enterprise ready, cloud platforms are bridging the gap with hybrid offerings, and edge computing keeps opening new deployment scenarios. Within the next several years, do not be surprised to see traditional SCADA platforms incorporating Node-RED style visual development environments, while Node-RED itself grows more industrial grade features aimed at mission critical use. The debate was never really about picking a winner, it is about selecting the right tool for the right application, and building the platform agnostic skills, meaning a solid grasp of data models, communication protocols, and system architecture, that outlast any single tool.

8.  The Cybersecurity Risks We Actually Need to Manage

Everything above is why Node-RED spread so quickly through industrial environments. None of it changes the fact that deploying it into OT without proper governance introduces real risk. If we are an OT cybersecurity professional coming from an IT security background, these are the vulnerabilities that deserve a line item in our risk register, in roughly the order we tend to encounter them during an assessment.

8.1  Insecure Defaults and Unmanaged Exposure

Out of the box, a default Node-RED installation does not enforce authentication on its editor web interface, which listens on port 1880, and its traffic is plain unencrypted HTTP unless someone deliberately configures otherwise. If an unhardened instance ends up on a network segment connected to the corporate LAN, or worse, exposed to the internet, an attacker can reach the editor directly, write arbitrary JavaScript into a Function node, and gain full shell access to the underlying operating system. This is not a theoretical edge case. It is the single most common finding in real Node-RED assessments, and it is entirely preventable with basic authentication, TLS, and network segmentation.

8.2  Excessive Trust and Missing Change Control

Because Node-RED is so easy to install and configure, engineers sometimes deploy it straight onto production systems without following formal change management, security hardening, or access control procedures. A flow that looks like a quick fix during a shift can quietly become permanent production infrastructure that nobody ever formally approved, reviewed, or documented.

8.3  Open Source Supply Chain Risk

Node-RED leans heavily on community contributed nodes distributed through npm. The ecosystem is extensive, but third party nodes vary widely in quality and ongoing maintenance. Pulling an unvetted package directly into a Level 3 operational network introduces genuine software supply chain risk. Every node package we plan to use should be audited, ideally mirrored in an internal repository, and scanned for known vulnerabilities before it ever touches a production flow.

8.4  Credential Handling

API keys, database passwords, and PLC credentials sometimes end up stored directly inside flow configuration files. If those files are compromised, improperly backed up, or simply committed to an unsecured Git repository, sensitive credentials can be exposed well beyond the scope anyone intended. Credentials belong in a proper secrets store or Node-RED's built in credential encryption, not in plaintext flow JSON.

8.5  Unplanned Bridging Across Security Zones

Node-RED can connect simultaneously to IT systems, OT networks, cloud services, and external APIs, often from the same running instance. Without deliberate network segmentation and firewall policy, it can unintentionally become a bridge between environments that were always meant to stay isolated. This is the Purdue violation pattern we walked through earlier, and it is worth repeating here because it is the risk most likely to turn a convenient integration into an actual intrusion path.

8.6  Shadow OT

Because it is so easy to stand up, Node-RED sometimes ends up running mission critical data flows on an undocumented industrial PC sitting under a desk, invisible to the asset inventory. If that flow fails, or if the engineer who built it leaves the company without documenting the wiring, the plant is left holding an unmaintainable black box that nobody can safely modify or decommission.

8.7  Non Deterministic Execution

Node-RED runs on a single threaded Node.js event loop. It is asynchronous, not deterministic. It should never be used for real time safety interlocks, sub millisecond trip signals, or any critical physical control loop where a delayed execution thread could cause equipment damage or a genuine safety hazard. That job belongs to the PLC and the safety instrumented system, full stop.

8.8  Inherited Platform Risk

Because Node-RED is built on Node.js, it inherits the security responsibilities of the underlying operating system and the broader JavaScript ecosystem. Regular patching, dependency management, secure configuration, and continuous monitoring are not optional extras, they are the baseline cost of running it safely.

9.Final Thoughts: It Is Not Binary

Node-RED is not a PLC, a SCADA platform, or a replacement for traditional industrial control systems, and it never claimed to be. It is an integration and orchestration platform that excels at connecting industrial assets with modern IT and cloud technology. The Node-RED versus traditional SCADA debate is not really about picking a winner, it is about selecting the right tool for the right application. Both platforms will keep coexisting, serving different parts of the industrial automation market.

For organizations pursuing Industrial IoT, predictive maintenance, digital transformation, or operational analytics, Node-RED offers a fast, flexible, and genuinely cost effective way to bridge the long standing gap between IT and OT. For those of us coming from an IT security background into the industrial world, understanding Node-RED well is valuable precisely because it shows us how modern factories move information beyond the PLC and SCADA layers. It is often the glue binding legacy automation, enterprise applications, cloud platforms, and industrial data together, and that makes it one of the more instructive systems we can study to build real OT intuition.

Like any powerful technology, its value depends entirely on how it is implemented. When we deploy it with sound engineering practice, deliberate network segmentation, strong authentication, careful credential management, and OT focused cybersecurity controls, Node-RED can meaningfully accelerate industrial integration while preserving the reliability and resilience that critical infrastructure demands. Get the governance wrong, and the same flexibility that makes it so useful becomes the reason an attacker finds a foothold. For automation professionals, the lasting skill is developing platform agnostic judgment, meaning a real understanding of data models, communication protocols, and system architecture that outlives any single tool. For organizations, the strategy should focus on business outcomes, meaning faster time to market, lower total cost of ownership, improved operational efficiency, and better decision making, delivered without ever losing sight of the security posture that critical infrastructure requires.

The future belongs to those of us who can work comfortably in both worlds, leveraging the innovation of open source tools while respecting the proven reliability of industrial grade platforms. Node-RED, treated with the same rigor we would apply to any enterprise middleware and scoped firmly to data integration rather than direct physical control, earns its place as one of the most useful tools in a modern OT security practitioner's toolkit.

10.  References & Sources

This article was developed through an extensive review of academic journals, peer-reviewed research papers, technical reports, industry publications, and professional guidance covering operational technology (OT), industrial control systems (ICS), smart grids, and critical infrastructure protection.

10.1  Disclaimer

This article is intended solely for educational and awareness purposes. It consolidates information from multiple publicly available academic and technical sources together with the author's professional experience in industrial cybersecurity and critical infrastructure protection. While every effort has been made to ensure technical accuracy, some concepts have been simplified to improve readability for a broader audience. Readers should consult OT cybersecurity professionals, vendor documentation, and authoritative guidance before making engineering, operational, or security decisions.

10.2  AI Assistance Disclosure

To improve readability, grammar, sentence structure, remove typos and overall clarity, AI writing tools were used as an editorial assistant. The technical concepts, interpretation, structure, and final technical review were performed by the author. AI was not used as a primary source of technical information or research.

10.3  About ICSCyberPro.net

A few of us started ICSCyberpro.net as a small non-profit community with a simple goal: to learn, share, and collaborate in the field of OT/ICS cybersecurity while helping professionals build their skills and knowledge without expensive barriers.

Everything we do is 100% non-profit. We have no plans to sell courses, memberships, or paid content. We believe good knowledge should be accessible to everyone. Our focus is on real-world experience and deep research, not copy-pasted content or AI-generated fluff. If you'd like to be part of the community, you're welcome to sign up. We don't send marketing emails, at most, you'll receive one email a month covering important topics, practical insights, and learning resources.

I'm always interested in hearing different perspectives. What's one lesson from your own OT environment that changed the way you think about cybersecurity? If you have a question, an idea, or simply want to share your experience, I'd be glad to hear from you. Feel free to email me at sec[dot]asmz[at]gmail[d

Download the PDF Version Here

Node-RED - AN OT / ICS CYBERSECURITY PERSPECTIVE

Most people in OT security still think Node-RED is a hobbyist toy for Raspberry Pi tinkerers. It’s actually running inside Siemens and Phoenix Contact hardware on real production floors right now, quietly becoming the connective tissue between forty year old PLCs and modern cloud analytics. I spent my career on both sides of the IT and OT fence, and this is the tool I keep coming back to when people ask me where industrial integration is actually heading. It doesn’t replace SCADA, and it was never meant to. What it does is let an engineer pull data off a legacy Modbus pump, format it into clean JSON, and push it to a predictive maintenance model in the cloud, all without touching a single line of certified PLC code. No expensive OPC license, no six week integration project, just a working flow in about fifteen minutes. That is exactly why it’s spreading so fast through plants, refineries, and utilities, and exactly why it deserves serious security attention rather than being dismissed as a toy. The same flexibility that makes it powerful is what turns a good idea into a Purdue Model violation if nobody’s watching where it gets deployed. I wrote a full breakdown of where it belongs, where it doesn’t, and the exact hardening checklist I use in the field, because I think this is one of the clearest signals of where OT and IT are actually converging. The plants that get this right in the next few years are going to move faster than the ones still waiting on a six figure SCADA license renewal. This is worth understanding now, not later.

ICSCyberpro.net