For IT
No open ports. No VPN. One signed installer.
This page is written for the person who has to approve OPDC. It covers what gets installed, what the firewall has to allow, how callers are authenticated, and what your Sage 100 Contractor database is exposed to. The short version: your IT company installs one EV code-signed Windows executable, and nothing else changes.
Firewall
No ports to open
No inbound firewall rule, no port forward, no published listener. Your perimeter stays exactly as your IT company configured it.
Access
No VPN to hand out
Nobody needs network-level access to reach Sage data. Applications authenticate to an API instead of being let inside the network.
Install
One EV signed executable
The entire install is a single Windows executable signed with an Extended Validation certificate. That is the whole footprint.
Why there is no port to open
OPDC does not wait for the internet to call it. The connection is established outbound, from your server, over HTTPS. Because your server is the side that dials, there is no inbound rule to write, no port to forward, and no listener on your perimeter for anyone to find and scan.
That also means no VPN. The usual alternative to a VPN is punching a hole in the perimeter for a reporting tool, and the usual alternative to that is emailing spreadsheets around. OPDC replaces both without changing your perimeter.
Your Sage 100 Contractor database keeps talking to OPDC over the local network and to nothing else. Callers address OPDC. Nothing outside your network ever addresses the database itself, and there is no raw SQL path through the API for them to address it with.
Outbound, from your server
Encrypted HTTPS to our endpoints. Your IT company can allowlist it by hostname if egress is filtered.
Inbound, from the internet
None. No listening port is published, so there is nothing to expose and nothing to firewall.
Local, to the Sage database
Stays inside your network, exactly as it does today. OPDC does not move a copy of your database anywhere.
The installer
EV code signed, so it arrives already trusted
Every executable we ship is signed with an Extended Validation code signing certificate, the highest assurance tier available for Windows code signing. The signing key lives in certified hardware, and the certificate was issued only after a certificate authority verified Twinn Engineering as a legal entity rather than an email address.
For your IT company that means the installer identifies its publisher before it runs. Windows SmartScreen and enterprise application control policies see verified publisher software instead of an unknown binary, so it does not need a policy exception, a temporary bypass, or someone clicking through a warning to get installed.
Verified publisher, not a guess
The certificate is issued to Twinn Engineering as a verified legal entity, so Windows can name the publisher before the installer runs.
Hardware protected signing key
EV signing keys are held in certified hardware. The key cannot be copied off a laptop, which is the point of the tier.
Passes application control
SmartScreen and publisher-based allowlisting recognise it on sight, so no bypass or exception is needed to install it.
Every release, not just the first
Updates ship under the same signature, so the trust decision your IT company makes once keeps holding.
You do not have to take our word for it. Right-click the download, open the Digital Signatures tab, and confirm the publisher and the certificate chain before you run anything.
The controls behind it
A closed perimeter is only half the answer. These are the controls that decide who gets through the API and what they are allowed to do once they are through.
Mutual TLS on every call
Client and server each authenticate the other before any data moves. A caller without a valid certificate never reaches the request stage.
Your identity provider
Users authenticate through Auth0, with LDAP and enterprise identity providers supported, so accounts live where you already manage them.
Scoped, revocable keys
Every request carries an API key tied to one organization and one permission set. Revoke a key in the dashboard and that caller stops, alone.
Relationship-based authorization
Access is decided by relationship-based access control (ReBAC) on OpenFGA, so what a caller can reach is an explicit relationship between that caller and that object rather than a role flag that quietly grants too much.
Sage credentials stay encrypted at rest
The database credentials the connector uses are encrypted with Windows DPAPI and salted, scoped to the account the service runs under, so they are not readable as configuration sitting on disk.
Read-only means read-only
On a read-only plan no endpoint your keys can reach is able to change Sage data. The limit is in the API surface, not in a setting.
Writes go through validation
There is no raw SQL path. A write satisfies Sage business rules such as cost code structure, GL format, and fiscal period, or it is rejected with a reason.
Every call is logged
Reads and writes alike are recorded with the authenticated user, timestamp, endpoint, and payload, reviewable in the dashboard.
Data stays on your hardware
Your Sage database is not copied to a cloud we run. It stays on the server it is on now, and OPDC reads it from beside it.
Sage is left untouched
No Sage files, settings, or database structures are modified by the install. OPDC connects to what is already there.
One install, every company
One install handles a multi-company Sage environment natively, so there is not a separate connector per company to review and patch. Each company has its own key, so access to one can be revoked without affecting the others.
Checklist
What your IT company actually has to do
Hand this section to whoever manages the server. It is the whole ask, and most of the rows are a variation on "nothing".
- Inbound firewall changes
- None. Nothing needs to accept a connection from outside your network.
- Ports to open or forward
- None.
- VPN or remote access
- Not required, and not requested.
- Outbound traffic
- Encrypted HTTPS from the server to our endpoints. Allowlist by hostname if egress is filtered.
- What gets installed
- One EV code-signed Windows executable, which registers a Windows service.
- Privileges needed
- Local administrator rights for the install, to register the service and set up local certificates.
- Where it runs
- Windows Server 2016 or later, or Windows 10/11, with local network access to the Sage database.
- Changes to Sage 100 Contractor
- None. Files, settings, and database structures are left as they are.
- Changes to the database server
- None beyond OPDC reaching it over the local network, the same way Sage does.
- Cloud copy of your data
- None. Your database stays on your hardware.
- Time to install
- Usually one session, with our engineer on the call.
- Rollback
- Remove the service. Sage is unaffected either way.
Uninstalling is the same story in reverse. Remove the service and Sage keeps running exactly as it did before, because OPDC never modified it.
Compliance and review
We are not SOC 2 certified today, and we would rather say so here than have you find out in a questionnaire. What we can put in front of a security review is the control set on this page: on-premise isolation, no inbound exposure, mutual TLS, identity through your own provider, relationship-based authorization, scoped and revocable keys, credentials encrypted at rest, EV code signing, and an audit log of every call.
Members of our team have taken previous companies through SOC 2 audits, so we know what the evidence request looks like. If certification is a hard requirement for your organization, tell us and we will start the process.
In the meantime, send us your security questionnaire or vendor review form. We answer them directly, and we will walk your IT company through the install on a call before anyone signs anything.
Questions IT asks us
More on how OPDC works is on the OPDC page, and the API contract itself is documented for developers.