What Does an Open Port Prove? How to Assess a Provider’s Security Honestly

How to read security claims—not a ranking or technical assessment of named providers.

An e-invoicing provider should be challenged about security. It should not be convicted by a screenshot. An open network port can be a useful observation, but the distance between “a service responded” and “customer invoices are exposed” is substantial. Crossing that distance requires evidence, context and, for intrusive verification, permission. Otherwise, an argument intended to improve public accountability becomes an unsupported allegation.

I support electronic invoicing and Peppol. That makes accuracy more important, not less. Businesses need to know which assurances are meaningful and which questions remain unanswered. Neither a certificate displayed on a website nor a dramatic list of ports is a complete answer. This article reports no scan of any provider and makes no finding about a named service.

Start with what the observation actually means

The Nmap documentation defines an open port as one on which an application is actively accepting connections, datagrams or associations, depending on the protocol.1 It also explains that reported port states describe the scanner’s view rather than an intrinsic, universally observable property: the same port may appear open from one network and filtered from another.1 That qualification belongs in the headline interpretation, not hidden in a technical appendix.

An observation therefore needs a time, a network vantage point, an identified destination, a protocol and a method. A historical search result about an internet address is not a current assessment. Nor does ownership of a domain automatically establish responsibility for every service on an address associated with it. Attribution must be checked before the result becomes a statement about an organisation.

The practical distinction is between exposure and failure of a security boundary. A public invoice gateway must be reachable by its intended users. The relevant question is whether the reachable service performs its intended function while excluding unauthorised activity. Counting reachable services without understanding their purpose cannot answer that question.

Use an evidence ladder, not a leap

I would separate four levels in any assessment. First is a network observation: a destination responded in a particular way. Second is service identification: the response and supporting records justify a claim about what is running. Third is a documented security weakness: configuration, software behaviour or an independently validated finding demonstrates a problem. Fourth is impact: evidence establishes which data or operations could be affected, or were actually affected.

Each step needs its own support. A familiar port number is not conclusive identification of the application. A product banner is not proof that every vulnerability associated with that product applies. A vulnerability report is not automatically evidence of exploitation. Conversely, a quiet public perimeter is not proof of secure internal administration, safe backups or appropriate employee access.

A responsible report should label observations, interpretations and unresolved questions separately. It should also identify scope exclusions. If the assessor reviewed only a public website, the report must not imply that it assessed invoice processing, customer separation or the provider’s recovery arrangements. Strong language should follow strong evidence rather than compensate for missing evidence.

A hypothetical purchasing decision

Imagine a small wholesaler selecting an e-invoicing service. Its adviser receives a screenshot showing several open ports associated with an address believed to belong to a candidate provider. Another candidate has a shorter list. The wholesaler is tempted to treat the shorter list as the safer choice.

This example is hypothetical; no such providers or results were investigated. The purchasing team should first ask what the screenshot represents. Does it concern the production invoice gateway, a marketing site or shared infrastructure? When was the observation made? Who verified attribution? Does the service need to be publicly reachable, and which controls protect the operation behind it?

The provider might offer an architecture summary explaining the public endpoint, the boundary between tenants and the separate administration path. It might instead leave the assurance question unresolved. Refusing to disclose sensitive topology or other customers’ information is not itself evasiveness. Ask for the reason for the restriction and an alternative: a scoped independent summary or controlled access for an authorised assessor. Both responses matter to purchasing confidence, but neither changes the original screenshot into proof of leaked invoices. The useful commercial outcome is a better assurance request, not an improvised public accusation.

Ask about the invoice’s whole journey

The OpenPeppol specification catalogue separates transport specifications, including AS4, from service metadata publishing and locating specifications, SMP and SML.4 That separation is a reminder to assess actual components rather than use “Peppol server” as an all-purpose description. A metadata service should not be described as a central invoice archive merely because it helps participants discover delivery information.

For purchasing purposes, I would request a diagram showing the company’s accounting system, the provider’s customer interface, the network delivery component, any subcontracted processing and any separately applicable tax-reporting path. Mark where invoice content is stored, where only routing information is handled, and where administrative access is possible. Do not assume that business-to-business delivery and reporting to an authority are the same transaction.

Then ask who can access each category of information and how that access is reviewed. What evidence demonstrates separation between customers? How are privileged credentials protected and replaced? How does the provider detect misuse? How are customer exports and incident records protected? These questions test the service a company is buying, not merely the public network surface visible to an observer.

Evidence worth asking for

My preferred assurance pack would contain a current scope statement, a summary of independent assessment, the treatment of significant findings, and a clear explanation of residual risks. The date and coverage of an assessment matter. So does whether the assessed environment corresponds to the service now being offered. A clean conclusion with narrow coverage may answer less than an honest report that records and tracks remaining work.

For personal data, GDPR Article 32 requires appropriate technical and organisational measures taking account of risk and other specified factors; it explicitly includes confidentiality, integrity, availability, resilience, restoration and regular evaluation of measures.10 That is broader than a promise that traffic is encrypted. It is also not a rule declaring that every exposed port is unlawful.

Where a provider processes personal data on a customer’s behalf, Article 28 requires sufficient guarantees and a binding processing arrangement, including provisions on information and audits.9 The precise roles must be determined for the actual processing. An invoice service cannot be assessed responsibly by assuming that every participant has the same legal role for every purpose.

Fairness is not leniency

The strongest objection to this cautious approach is that providers can hide behind confidentiality. A small business cannot inspect infrastructure, commission extensive assessments or negotiate every term. If all meaningful evidence is secret, “trust us” becomes the only practical option. That is a legitimate criticism of the assurance market.

The answer should be proportionate transparency. Providers can publish the scope and date of assurance, explain their control model, disclose how serious findings are handled, and offer more detailed evidence under suitable confidentiality conditions. Public authorities can define minimum disclosures for services involved in a mandatory process. Customers should not need confidential technical detail to understand who handles their invoices and what recourse exists.

There is a limit, however. Publishing exploitable details before responsible handling can create additional risk. Customers need decision-useful evidence, not an operational manual for attacking the provider. A disclosure policy should distinguish public accountability, confidential assurance and restricted vulnerability handling, with named contacts and expected response stages.

Turn uncertainty into a purchasing condition

A business can create a short decision record without pretending to be a penetration-testing laboratory. List the critical data and operations; identify the evidence supplied; record its date and scope; note unanswered questions; and assign a decision owner. Where an assurance gap is significant, require clarification or a contractual commitment before onboarding. If the residual risk is unacceptable, choose another service.

Any intrusive testing should be separately authorised with explicit scope, contacts and safeguards. A commercial relationship is not permission to test every connected system. This is an editorial standard as well as a technical one: asking hard questions does not require inventing findings or exceeding authority.

The conclusion is deliberately less dramatic than “open port equals breach.” A reachable service is a starting point. A defensible claim of a specific vulnerability or impact connects an observation to a verified asset, a relevant control, a demonstrated weakness and a realistic consequence. A conditional judgement about risk or insufficient assurance need not wait for a demonstrated vulnerability, but must state its assumptions and must not imply a proven leak. Demand evidence proportionate to the claim from critics and providers alike. E-invoicing deserves scrutiny precise enough to improve it.