ERP Portal Security: How We Keep Your Data Safe Connected to Your Business System

Connecting a web application — a customer portal, a staff dashboard, or a partner extranet — to your ERP system raises legitimate security questions. If you are a managing director, IT manager, or manufacturing director reading this, you are right to ask them.

Your ERP holds your financial records, customer data, supplier details, inventory valuations, and operational history. Opening any of that up to a new application demands a clear understanding of who has access, where data lives, how it moves, and what happens if something goes wrong.

This guide lays out the security architecture that Sysgraft uses when connecting portals to ERP systems. It covers authentication, data residency, encryption, access controls, auditing, and compliance — in plain language. We use British English because we are a UK company engineering these solutions for UK manufacturers and distributors.

1. Authentication: OAuth 2.0 and Microsoft Entra ID

Every connection between a Sysgraft portal and your ERP is authenticated via OAuth 2.0, the industry-standard protocol for authorising API access. There is no shared password. No static API key floating around in configuration files. No basic auth.

Here is how it works in practice:

Staff access via Entra ID SSO

Your employees authenticate using their existing Microsoft 365 credentials through Microsoft Entra ID (formerly Azure Active Directory). Single sign-on means they never create a separate password for the portal. If they leave the business, you disable their Microsoft account and their portal access dies with it. No orphan accounts. No manual offboarding.

Customer access

Portal users who are not on your Microsoft tenant — customers, suppliers, partners — authenticate through separate secure identity providers, typically Entra External ID (formerly Azure AD B2C) or Auth0. These platforms handle password hashing, MFA, brute-force protection, and session management for you.

Service-to-service: the client credentials flow

When the portal itself calls your ERP’s API, it uses the OAuth 2.0 client credentials grant — a service-to-service pattern where the portal authenticates as an application, not a user. The result is a short-lived access token (typically valid for 60–90 minutes). Short-lived tokens mean that even if a token were intercepted, the window of exposure is measured in minutes, not months.

Compare this with a long-lived API key stored in a configuration file — a pattern we still see in the wild. If that key leaks, an attacker has persistent access until someone notices and rotates it. OAuth 2.0 with short-lived tokens eliminates that class of risk.

2. Data Residency: UK-Region Cloud Infrastructure

All Sysgraft application infrastructure is hosted in UK-region data centres. We deploy primarily on Azure UK South (London/Milton Keynes) and, where a client has a preference, AWS London (eu-west-2).

This matters for several reasons:

• UK GDPR adequacy: Your data never leaves UK jurisdiction. There is no cross-border data transfer to assess, no standard contractual clauses to manage, no onward-transfer risk.
• Latency: UK-hosted infrastructure talking to a UK-hosted ERP (Business Central in UK South, Sage 200 on-prem with a UK Azure VPN endpoint, OrderWise on UK servers) means round-trip times in the low single-digit milliseconds.
• Regulatory comfort: If you operate in a regulated sector, your compliance team will want to know that data is stored and processed within the UK. UK-region hosting answers that question definitively.

You can verify this yourself: every Sysgraft deployment comes with a deployment manifest showing the exact Azure region or AWS availability zone. No ambiguity.

3. Data Scoping: Field-Level Access and Customer Isolation

One of the most common fears about connecting a portal to an ERP is the “all or nothing” problem — the idea that the portal needs blanket database access to function. That is not how we build it.

Customer-level isolation

A customer who logs into their portal sees only their own data. Their sales orders. Their invoices. Their statements. They do not see other customers’ data. This is enforced at two layers:

• API level: The ERP API is queried with automatic filters scoped to the authenticated customer’s record. For Business Central, this means filtering on the customerNumber or sellToCustomerNumber field in every query.
• Application level: The portal enforces its own authorisation layer. Even if an API call were misconfigured, the application refuses to render data that does not belong to the requesting user.

Field-level scoping

We do not expose entire ERP entities through the portal. Each endpoint in the adapter layer explicitly maps only the fields that the application needs. An invoice display might return invoice number, date, line items, and total — but not the GL entries, cost allocations, or internal notes that sit on the same record in the ERP.

Customer-facing sales order response (example):
{
  "orderId": "SO-10234",
  "orderDate": "2026-06-20",
  "status": "Shipped",
  "lineItems": [
    { "sku": "BRK-001", "description": "Bracket, steel", "qty": 50, "unitPrice": 12.40 }
  ],
  "totalAmount": 620.00,
  "carrier": "DPD",
  "trackingUrl": "https://dpd.co.uk/track/..."
}

// Not included: cost price, margin, GL account, internal notes,
// delivery address alternative, payment terms, credit limit

The adapter pattern

This scoping is enforced by an API adapter layer — a thin service that sits between the portal frontend and the ERP API. The adapter:

• Maps ERP field names (which may be cryptic OData identifiers) to human-readable names
• Strips fields that are not in the permitted scope
• Validates that the requesting user is authorised for each record before the data leaves the adapter
• Provides a single point of change if fields need to be added or removed

The adapter is the only code that talks directly to your ERP. Everything else talks to the adapter. This gives you a clean audit boundary: you can review every field, every endpoint, and every transformation in one place.

4. Encryption: TLS 1.2+ in Transit, Encryption at Rest

In transit

All communication between the user’s browser and the portal is encrypted with TLS 1.2 or 1.3. All communication between the portal and your ERP API is encrypted with TLS 1.2 or 1.3. There are no plaintext fallbacks, no HTTP endpoints, no unencrypted internal service calls.

We enforce this in three ways:

1. Infrastructure-level: the TLS termination layer (Cloudflare or Azure Front Door) rejects connections that do not meet the minimum TLS version.
2. Application-level: the portal’s HTTP client library is configured to refuse any server that offers less than TLS 1.2.
3. Monitoring: any connection attempt at TLS 1.1 or below is logged and alerted.

At rest

Data stored within the Sysgraft infrastructure — application cache, session data, configuration, logs — is encrypted at rest using AES-256. Azure Storage Service Encryption and AWS EBS encryption handle this at the platform level. There is nothing we can do to disable it, even if we wanted to.

Note that Sysgraft does not store ERP data permanently. The portal reads data from your ERP in real time and caches it only for session duration or for performance optimisation (typical cache TTL: 30–300 seconds). Persistent storage is limited to configuration, user preferences, and anonymised audit logs.

5. No Credentials Stored: Service Principal Model

One of the most important security decisions we make is never to store ERP user credentials in the portal or its configuration.

Instead, the portal authenticates to your ERP using a service principal — an identity registered in your Microsoft Entra ID tenant that represents the application itself, not a person. The service principal:

• Has only the API permissions it needs (typically “read/write” scoped to specific Business Central API endpoints)
• Uses certificate-based authentication or managed identity — no passwords to rotate
• Can be audited independently of any user account
• Can be revoked at any time from your Azure portal

The practical effect: there is no ERP password stored in a .env file, no shared mailbox credential tucked into a configuration file, no human user whose password expiry breaks the portal at 3am. If you decide to terminate the engagement, you revoke the service principal and the portal loses all access immediately.

This is fundamentally different from the older pattern of creating an ERP user account with a password, storing that password in the application configuration, and hoping nobody finds it. The service principal model removes the credential as an attack surface.

6. Data Processing Agreement: Included with Every Engagement

Every Sysgraft engagement includes a signed Data Processing Agreement (DPA) that meets the requirements of Article 28 of the UK GDPR. You do not have to ask for it. It is not an upsell. It is part of how we work.

The DPA covers:

• The categories of personal data processed
• The purpose and duration of processing
• Sub-processors (currently Azure and AWS — both UK-based / UK-region)
• Data breach notification procedures
• Your rights as data controller
• Data deletion commitments on termination

If your compliance team needs to conduct a Data Protection Impact Assessment (DPIA), we provide full architecture documentation to support it. We have done this for UK manufacturers supplying the MoD, NHS, and critical national infrastructure. The process is well worn.

7. Penetration Testing: Regular Third-Party Testing

Sysgraft portals undergo regular penetration testing by independent third-party security firms. Our testing programme includes:

• Annual full-scope pentest: An external firm tests the entire application including authentication, authorisation, session management, input validation, API security, and business logic flaws.
• Quarterly vulnerability scanning: Automated scanning of the application and infrastructure for known CVEs.
• Continuous dependency monitoring: Dependabot and Snyk track every dependency in the stack and flag vulnerabilities within hours of disclosure.
• Post-deployment test: Each client deployment receives a targeted test against their specific configuration and data model before go-live.

Findings are categorised by severity and remediated on a defined schedule: Critical (72 hours), High (7 days), Medium (30 days). We publish a security bulletin for each engagement showing the findings and their resolution status.

Responsible disclosure

If you are a security researcher and believe you have found a vulnerability, you can reach us at security@sysgraft.com. We maintain a responsible disclosure policy and commit to acknowledging reports within 48 hours.

8. Monitoring and Logging: Immutable Audit Logs and Anomaly Detection

Every action taken through a Sysgraft portal is logged in an immutable audit trail. Logs record:

• Who performed the action (user ID, session ID)
• What action was performed (read, write, update, delete)
• Which ERP endpoint was called
• When the action occurred (UTC timestamp, nanosecond precision)
• The HTTP response code and payload size

Logs are written to a separate logging service (Azure Log Analytics or AWS CloudWatch) with append-only access. Even Sysgraft engineers cannot delete or modify log entries. Logs are retained for a minimum of 12 months and are available for your review at any time.

Anomaly detection

Our monitoring platform watches for anomalous patterns:

• Unusual traffic spikes from a single IP or user account
• Repeated failed authentication attempts (potential brute force)
• Access attempts to API endpoints outside the expected scope
• Unusual data volumes (potential data exfiltration attempt)

Anomalies trigger automated alerts that reach our engineering team within minutes. We respond to security incidents under a defined incident response plan, with initial assessment within 1 hour and escalation defined by severity.

9. Security Comparison: Portal Approach vs Giving Users Direct ERP Access

One question that often comes up is whether connecting a portal is actually more or less secure than the alternative — giving users direct access to the ERP interface.

The answer depends on who the users are:

For internal staff who already use the ERP, a portal does not replace the ERP — it augments it for specific workflows. For external users (customers, suppliers), a portal is dramatically more secure than giving them any form of direct ERP access, because they never see the ERP interface at all.

10. Frequently Asked Questions

Is Sysgraft GDPR compliant?

Yes. Sysgraft is registered with the UK Information Commissioner’s Office (ICO). We process personal data only as a data processor on your instructions, as documented in our DPA. All infrastructure is hosted in UK-region data centres. We do not sell or share personal data for any purpose other than delivering the service.

Do you hold Cyber Essentials or Cyber Essentials Plus certification?

We maintain Cyber Essentials certification and are actively working toward Cyber Essentials Plus. If your contract requires a specific certification level, we can scope the deployment to meet it, including the use of UK Sovereign cloud with additional controls.

What about SOC 2?

SOC 2 is a US-centric framework that is less common among UK-based software companies serving the mid-market manufacturing sector. Our security controls align with the SOC 2 trust principles — security, availability, and confidentiality — but we currently certify against the UK’s Cyber Essentials scheme. We are open to SOC 2 certification if a client’s compliance requirements demand it.

What happens if there is a data breach?

Our incident response plan requires initial assessment within 1 hour of detection. If the breach involves personal data, we notify you as data controller within 24 hours, providing the categories of data affected, the number of records, the likely consequences, and the measures taken or proposed. You are then responsible for notifying the ICO within 72 hours if required. We support your notification process with full forensic data.

Can you sign our specific DPA or security questionnaire?

Yes. We routinely review and sign client-specific DPAs, information security schedules, and supplier security questionnaires. This includes documentation for manufacturers supplying the Ministry of Defence, NHS Trusts, and other regulated entities. Allow 5–7 working days for legal review.

What happens to my data when the engagement ends?

On termination, we delete all data held in the Sysgraft infrastructure within 30 days. You retain your ERP data in its original location — it was never migrated, so there is nothing to repatriate. The portal application code is your intellectual property and is handed over on go-live. If you wish, configuration and anonymised audit logs can be exported before deletion.

---