CelinQ Insights · No. 91 · Last technically reviewed: August 2026
How to Share Enterprise Architect With Remote Consultants
A consulting engagement needs real, productive access to your model — not a VPN account into your core infrastructure and not a stale export that's out of date by the second meeting.
Short answer. The realistic options are: a VPN or remote-desktop path into your existing repository, Pro Cloud Server's own remote access, a duplicated/exported copy the consultant works on separately, or a local-first synchronised copy that stays in step with the live model without exposing your core database directly. Each trades off differently on security exposure, setup effort, and how current the consultant's copy actually stays.
Why this is harder than "just give them a login"
A consulting engagement is, by definition, a party outside your own network boundary needing real, working access to a live architecture model — not a read-only export, actual modelling access, because most engagements exist specifically to change the model. That combination is exactly the shape of access most security postures are built to prevent by default: a shared, centrally hosted repository is usually reachable only from inside the corporate network or over VPN, and extending either of those to an external party's laptop is a real, deliberate exception to make, not a checkbox.
Underestimating this is common and expensive. Handing out a VPN account without thinking it through grants network-level access far broader than "read and write this one model," a genuine security exposure most organisations would not accept if they thought about it in those terms rather than "give the consultants access."
The realistic options, compared
| VPN / remote desktop into existing repository | Fastest to set up if VPN infrastructure already exists. Real cost: network-level access broader than the model itself, and remote-desktop or VPN latency degrades the modelling experience the same way it does for any remote worker. |
|---|---|
| Pro Cloud Server | Purpose-built for exactly this — remote access to a live EA repository without VPN. Real cost: licensing and operating a dedicated service, and it's a meaningful infrastructure decision to stand up for one engagement. |
| Duplicated / exported copy | Simplest to set up — export a copy, hand it over. Real cost: it diverges from the live model immediately, and reconciling the consultant's changes back in later is exactly the manual merge problem this series covers elsewhere. |
| Local-first synchronised copy | The consultant works against their own local repository, changes synchronise through a server rather than direct network access to your core database. Real cost: a server to run, and — like any collaboration architecture — new infrastructure to stand up for the engagement. |
What actually matters for this specific scenario
Three things distinguish a good answer for external consultant access from a good answer for internal team collaboration generally, and it's worth being explicit about why this scenario is different.
The consultant's laptop is not your laptop
You don't control its patch level, its other software, or what else it connects to. Whatever access you grant should assume the endpoint itself is less trusted than an employee's managed device.
Engagements end
Revoking access cleanly when the engagement finishes matters more here than for a permanent employee — a workspace-scoped, revocable credential is easier to reason about than a VPN account someone has to remember to disable.
Stale copies create real rework
An engagement that runs for weeks or months on a copy that stopped updating on day one produces recommendations against a model that no longer reflects reality by the final workshop.
Where CelinQ fits. A local-first synchronised copy addresses all three: the consultant never gets direct network access to your core repository or database, only to a workspace-scoped server connection; access is a revocable token or role, not a VPN account; and the copy stays in step with the live model throughout the engagement rather than diverging from day one. It is not the only legitimate answer — Pro Cloud Server is a real, purpose-built alternative for organisations already invested in that path.
Frequently asked questions
Is a VPN account the simplest option? It's often the fastest to set up if VPN infrastructure already exists, but it grants network-level access broader than just the model, which is a real security trade-off worth weighing deliberately rather than defaulting into.
Can access be revoked cleanly when the engagement ends? With a workspace-scoped token or role, yes — revocation takes effect on the next request, not the next sign-in. A VPN account requires someone to remember to disable it separately.
Does the consultant need their own licence for the modelling tool? Yes, regardless of which access approach is used — none of these options change the underlying tool licensing requirement.
Related reading
CelinQ vs Pro Cloud Server
The full architecture comparison, including when Pro Cloud Server is the better fit.
Audit Trails for Public-Sector EA
What auditors ask for when external parties have touched the model.
Modelling Across Distributed Teams
The broader distributed-collaboration problem this scenario is one specific case of.