For IT Teams
Outbound access on two ports, sign-in through your own Microsoft tenant, and nothing opened inward. The detail is below, and the full document is a form away.
Auredia is delivered as a managed service. We operate the platform, the software on the edge appliance and the sign-in broker. Your team owns the environment those things sit inside — which comes down to outbound network access, your identity provider, and your normal device policy.
| We operate | You configure |
|---|---|
| The cloud platform your data lands in | Outbound firewall or proxy rules so your site can reach it |
| The edge appliance software, and patching it remotely | Where it is physically installed, and which network segment it sits on |
| The sign-in broker that sits in front of the application | Your own identity provider, and which of your people are allowed in |
| Data collection, dashboards and alerting | Nothing — it travels over the same outbound path as everything else |
Nothing in an Auredia install requires you to open an inbound firewall rule, forward a port, or expose an internal service to the internet.
Two kinds of data, and they matter separately because they start in different places. Most sites end up writing one firewall rule for each, which makes it obvious which path has broken when something stops arriving.
Numeric readings from equipment on the floor — spindle speed, tool state, cycle counts, sensor values. Collected by the Auredia edge appliance, batched roughly once a second, and held on local disk if the internet drops, so nothing is lost while a line is down.
Starts on the plant floor or edge segment.
What an operator presses on the Auredia screen — job starts, part completions, downtime reasons. Sent one event at a time from tablets or workstations, and queued on the device if it is briefly offline.
Starts on the segment your tablets and workstations already use.
The document sets out a three-zone reference model, vendor-neutral — it names functions rather than products, so whatever firewalls, proxies and wireless kit you already run will do. The shape is the part worth knowing up front.
Equipment and its wired sensors. In the recommended layout this segment has no network route to Auredia at all: readings leave it as physical signals on a wire, not as network traffic.
Our appliance and the module it reads. The only segment with a route out to the internet, and the only one that sends machine data.
Tablets and workstations on their own segment, authenticated individually to the wireless network. They reach machine data through the application, not by talking to the edge appliance, so no rule is needed between the two.
One consequence worth raising early, because it is a genuine trade-off rather than a detail: because operator devices read machine data through the application, they need working internet to show live values. Sites that need those screens up during an outage should plan resilient connectivity — a second carrier or mobile failover — rather than a local fallback, which would undo the separation above.
A short list of hostnames on two ports: 443 for everything, and 8883 for machine data. This is the single most common reason a go-live slips, so it is worth doing early. We give you the exact list.
Our agents check the certificate they are given, so a proxy that re-signs traffic will stop them authenticating. Match our destinations by name and let them pass unopened — you can keep inspecting everything else.
We support single sign-on against Microsoft Entra ID. Your identity team creates one application entry and assigns the people who are allowed in. Your multi-factor and conditional access rules keep applying, unchanged.
Which segments the edge equipment will sit on, and which machines your people will use the application from. We check the path with you rather than discovering it on install day.
Where your tenant runs, how it is separated from every other customer, and what sits in front of it. Covered below in outline, and in full in the document.
These are the six things a security reviewer asks for in writing. If you need more than this — data residency, how long audit logs are kept, a penetration test summary — ask, and it will reach the team that owns the evidence.
There is no inbound firewall rule to add, no port to forward and no service of yours to expose. Every connection is started from inside your network. Our support access works the same way — a session your equipment opens outward, not a door we knock on.
Traffic is encrypted from the browser or device to the application, with no point in between where it travels in the clear.
We never receive your users’ passwords. Sign-in happens in your own Microsoft tenant, under your policies. Disabling someone there stops them reaching Auredia immediately.
Your hostname, your application instance, your database and your certificate are all yours alone. Only the underlying compute is shared, and it is not a route between tenants — there is no path in the application that can read another customer’s data.
The portal sits behind Cloudflare, so web attacks, floods and abusive clients are dealt with at the edge. It is not an option a customer can switch off, and there is no way around it.
The operator application ships through the normal app stores and installs as a managed app, so your existing device management handles it. We ask for a supported OS and outbound access, and impose no policy of our own. Personal devices are supported where your policy allows it.
Twenty-six pages: the endpoint list, the reference network architecture, single sign-on setup step by step, device management, and how tenant isolation works. We send it by email, usually the same day.
See how Auredia can help you reduce downtime, empower your people, and increase profitability.
