Security

How we secure what we build and run

Hardware security keys, no password logins, encrypted disks and immutable offsite backups. When your business runs on systems someone else operates, you are entitled to know exactly how they are operated, in specifics rather than reassurance.

Access is gated by hardware

Most breaches start with a credential, not an exploit. So we removed the credential as a way in.

01

Hardware keys, not passwords

Administrative access requires a physical FIDO2 security key. There is no password an attacker can phish, buy or guess their way in with, because the second factor is an object someone has to physically hold.

02

No password logins on servers

Password authentication is disabled on the servers we operate, and so is direct root login. Access is key-based and granted per engineer, which means it can be revoked one person at a time.

03

Admin surfaces are not on the internet

Management interfaces are reachable only through a VPN or a bastion host. There is no login page on the open internet for someone to find, and nothing exposed to brute force in the first place.

04

Nothing is shared or reused

Every system has its own credentials, held in a password manager. A credential exposed in one place cannot be replayed against another client, because it does not exist anywhere else.

Hardened, then kept that way

A server is not secured once. These are the things we keep doing for as long as we run it for you.

dns

EU infrastructure, servers of their own

We host on bare-metal infrastructure we build and operate ourselves in the European Union, and managed Odoo runs on a dedicated server rather than a shared tenant. Your data does not leave the EU, and one client's incident is not another client's problem.

encrypted

Encrypted at rest

Servers run with full-disk encryption. A drive that is pulled, replaced or decommissioned is not a readable copy of your business.

update

Security updates that do not wait

Security patches are applied automatically on the hosts we manage, on top of the scheduled maintenance in your agreement. The gap between a published vulnerability and a patched system is where most breaches actually happen.

shield

Firewalled and brute-force blocked

Host firewalls restrict what is reachable at all, and repeated authentication failures get the source blocked automatically instead of being left to keep trying all night.

monitoring

Logged centrally, alerted on

Logs from the systems we run are centralised and monitored, and alerts go to an engineer. Detection is worth nothing if the signal lands in a file nobody opens.

mark_email_read

Your domain, hard to spoof

We configure SPF, DKIM and DMARC on the domains we manage. Your invoices and order confirmations stay out of spam folders, and sending mail in your name gets considerably harder for everyone else.

Backups built to survive a bad day

The point of a backup is not that it exists. The point is that it still exists after the incident, and that it restores.

enhanced_encryption

Encrypted

Backup data is encrypted at rest, so a copy of the backup is not a copy of your business.

storage

Offsite and geo-redundant

Copies are held in a second physical location. A fire, a theft or a dead rack takes the server, not the recovery path.

lock

Immutable

Backups are written to append-only storage. A compromised server cannot reach back and delete or encrypt its own backups, which is exactly what ransomware tries to do first.

task_alt

Tested by restoring

We perform real restores instead of assuming they would work. An untested backup is a hypothesis, not a recovery plan.

01

Who can access my systems and data?

The engineers who operate them, and nobody else. Administrative access requires a physical security key, so an attacker holding a stolen password still has nothing to use it with. Access is granted per engineer, revoked individually, and ends when the engagement ends. We do not resell or share client data, and we do not use it to train anything.

02

What happens if a server fails or data is lost?

We restore from backup: an encrypted copy, held in a second location, written to append-only storage so that a compromised server cannot take its own backups down with it. We test those restores rather than assuming them. Because we operate the infrastructure ourselves, there is no support queue between you and the person doing the recovery, and recovery expectations are set in writing in your service agreement rather than promised in the abstract.

03

What stops ransomware from encrypting everything, backups included?

Append-only backup storage. Even an attacker with full control of a server cannot rewrite or delete the backup history from that server, which is the step most ransomware depends on to make paying the only option. Combined with offsite copies and tested restores, the honest answer to an incident becomes rebuilding from a known-good state rather than negotiating.

04

Is my data covered by GDPR?

Yes. LEAD NODE is a Luxembourg company hosting in the EU, so your data stays under EU jurisdiction and there is no third-country transfer to justify. Our privacy policy sets out what we process and why.

05

Does using open-source software make my systems less secure?

No. Security comes from how a system is operated: patched, encrypted, backed up, access controlled and monitored. What open source adds is that vulnerabilities are disclosed publicly and fixes do not wait for a vendor's release calendar, and that any engineer you trust can audit the code.

06

Do you hold a security certification?

We do not currently hold a formal security certification, and we would rather say so than imply otherwise. What we offer instead is specific and checkable: hardware-key authentication, no password logins, encrypted disks, immutable offsite backups we actually test, EU infrastructure we run ourselves, and a written service agreement that states the scope. If your sector requires certified providers, tell us early and we will say plainly whether we fit.

shield

Found a vulnerability?

If you believe you have found a security issue in one of our systems or in something we built, tell us before you tell anyone else. Send us the details and we will confirm receipt, investigate, and keep you informed about the fix. We do not pursue researchers who report in good faith.

code_blocks

Auditable by design

The systems we operate are built on open-source software, so how your data is handled can be inspected rather than taken on trust.

Questions about how your systems are run?

Ask the engineers who would operate them. You get a straight answer, including when the answer is no.