What a secure system integration really needs

An order that never shows up in the ERP. A customer who sits in the database twice, with two different addresses. A carrier who can read your purchase prices along with the delivery address. Problems like these almost never start with encryption or a badly configured firewall. They start with an integration that was built quickly once and never properly looked at again.

For a lot of organisations those integrations are now business critical. The webshop talks to stock management, the planning tool to time tracking, the customer portal to the CRM, and the bookkeeping to a payment provider. That saves manual work and prevents typos. It also creates a web of connections that somebody has to keep track of. So the question is not only whether an integration works, but whether you know who uses it, what it is allowed to do, and how you switch it off when something goes wrong.

Where it actually goes wrong

Individual systems are usually in reasonable shape. There is user management, updates arrive, a vendor ships patches. Integrations are not inherently unsafe either: the standards are mature and the technology is dependable. The difference is in the upkeep. A token that was dropped into a script years ago is often still sitting there. A webhook that was opened up during the build still accepts messages from anyone who knows the address.

This is rarely carelessness. An integration gets built because there is a bottleneck, and once the bottleneck is gone, so is the attention. Who revokes access when the developer who built it moves on? Who notices when an external API suddenly returns dates in a different format? And whose problem is it when an update on the other side stalls the exchange for an entire weekend?

An integration you genuinely control does three things. It exchanges only the data that is needed, it accepts only systems you know about, and it surfaces errors before your customer does. The first two are mostly technical. The third one is organisational, and that is usually the part that is missing.

Start with the process, not with the API

Write down what is exchanged, and why

The first question is not which protocol you pick, but why the integration exists at all. Describe that in plain language, in a few lines. Which event starts the exchange? Which data travels with it? Which system wins when the two disagree? And what happens when the receiving side is unreachable for an hour?

While you are at it, separate the data that is necessary from the data that is merely convenient. A carrier needs a delivery address, an order number and a weight. Not the full customer history, and certainly not your margins. Less data means less damage during an incident, and an integration that stays easier to understand.

Then name two owners: a business owner and a technical one. The business owner decides whether the exchange is still needed and whether the data being sent can be justified. The technical owner tracks behaviour, changes, certificates and permissions, and knows what to do when it breaks. Without those two names an integration belongs to everyone, which means it belongs to nobody.

Let systems prove who they are

For a business critical integration you want a form of machine authentication you can actually manage: OAuth 2.0, signed tokens, mutual TLS certificates, or an API key that is stored properly and replaced on a schedule.

Which one fits best depends on the situation. OAuth is practical when an integration has to act on behalf of a user or an organisation with limited rights. Mutual certificates suit a closed connection between two fixed systems. And an API key is not weak by definition. The difference is in how you handle it: a separate key per integration, never in source code, stored in a secrets manager, and revocable within minutes. A password that has been sitting in a config file for years and is known to three suppliers is a different thing entirely.

One rule holds throughout: a system never gets more trust than it needs. Use separate credentials for production, staging and test. Do not share a key between two suppliers or two applications. If one of those parties is compromised, you want to block exactly that access without bringing the rest of your processes down with it.

Grant no more rights than the integration uses

An integration that reads order statuses does not need to be able to delete customers or export financial data. That sounds obvious, yet during the build a broad administrator role often gets used because it is quicker. And then it stays.

The time you saved evaporates the moment you have to investigate an incident. With narrow permissions it is immediately clear what an integration could and could not have done, and the damage from a leaked token stays contained. So work with specific scopes, roles and endpoints: the invoicing integration gets invoice data, the stock integration gets nowhere near customer data. And review those rights again as soon as a process changes, a supplier is swapped out, or an application is phased out.

Encrypt the traffic and guard the keys

Traffic between systems belongs on TLS, with current settings. That part is table stakes by now. The harder part is the secrets themselves. An encrypted connection stops helping the moment a token ends up in an email, a ticket, a spreadsheet or a public repository.

So keep secrets in one controlled place, hand out access by role, and make sure you can trace who retrieved what. Plan replacement up front, because certificates expire, tokens have to be rotated and suppliers tighten their requirements. None of that is an incident, it is ordinary maintenance. Put the expiry dates in the technical owner's calendar.

If personal data, contract details or payment data crosses the line, also decide how long messages and logs are kept. An error message is useful, but a log file holding complete customer and payment details is a new risk in itself. Mask sensitive fields and keep no more than you need to operate and investigate.

Treat incoming messages as untrusted

A message can be technically valid and still make no sense. A price of zero, a status you have never seen, a text field of ten thousand characters: all three can derail whatever happens next. So validate more than the format. Are the required fields present? Do the values fall inside limits that make sense for your process?

With webhooks, check the sender too, through a signature or token validation. A public webhook address without sender verification is effectively an open door into your administration.

Decide in advance what should happen when something fails. A queue with a handful of retries and a growing wait between them works well when an external service is briefly down. Retrying forever works against you: it produces duplicate orders, extra transaction fees, or an external API that you overload yourself. So agree on a maximum, and let messages that still fail after that land in a separate queue somebody actually reviews. For transactions and synchronisations, also make sure that running the same instruction twice gives the same result as running it once.

Without visibility there is no control

An integration that stops without raising an alarm is not something you manage. Monitoring therefore has to go further than asking whether an endpoint responds. Are messages actually being processed? How many of them fail? How long does processing take compared with last week? And does the volume deviate from the normal pattern, because zero messages on a Monday morning is just as suspicious as ten thousand.

Record enough to reconstruct an incident afterwards: which integration did what, at what time, with which outcome, and under which technical account. Then attach alerts that match the stakes. A stuttering monthly report can wait until Monday. An integration that handles payments, orders or access has to be able to reach somebody at three in the morning.

And make sure there is a recovery procedure that a person can follow under pressure. Who do you call? Can the integration be paused safely? Can messages be replayed without processing them twice? Is there a fallback if a supplier ships a bad release? A document written only at handover will not help you at that point. Update it after every change, and occasionally walk through it with the people who are on call.

Test changes as if they were already live

Most disruptions do not come from an attack but from a small change. A field gets renamed, an API version is retired, a supplier lowers a rate limit. If that change lands straight in production, you usually hear about it from a customer first.

So use separate environments and test with realistic data that is not needlessly sensitive. Keep track of which API versions you use, how long they are supported, and which processes depend on them. For critical integrations, test the unpleasant scenarios as well: a timeout, an invalid message, a duplicate delivery, and a target system that stays silent for half an hour.

Write down what you expect from the other party too. Not just functionality, but availability, how quickly you are told about a security incident, how changes are announced, and how access gets revoked. A technically tidy integration stays vulnerable if a supplier changes its behaviour without telling you.

Security lives in the upkeep, not in the handover

Measures that were correct at go live lose their value if nobody looks at them afterwards. So put a recurring review in the calendar: which integrations are still running, with which permissions, which tokens and certificates are expiring, what is in the logs, and which external parties are you depending on? The older integrations deserve that attention most. They often run unnoticed for years while the contacts, the processes and the security requirements have all moved on.

At LJPc we see that integrations go better when development, hosting and operations sit together. Someone who knows the application, the infrastructure and the alerting can usually place an anomaly in one go. That beats handing a problem back and forth between parties at exactly the moment every minute costs money.

So when you add a new integration, do not pick the fastest connection. Pick the one you will still understand in two years, can adjust, and can switch off safely. That gives your organisation room to grow without every new integration adding another slice of invisible risk.