That single fact removes every control the rest of your estate depends on, and the usual answers are all attempts to get it back. Ship them a laptop, and you have spent procurement, imaging, shipping and recovery on one application — and the device is out of your sight for six weeks. Make them install an agent, and their IT may refuse, their security policy may prohibit it, and a supplier with leverage will simply decline. Give them a VPN account, and you have placed an unmanaged machine on your network with an access control list as the only thing deciding where it can go.

And when all three are slow enough or contentious enough, the fourth answer happens instead: an account gets shared, a screen-share becomes the access method, or the data is extracted and emailed and now sits on that machine permanently with nothing attached to it at all. That one never appears in an access review, because from the system’s point of view no access was granted.

The part that cannot be fixed

Underneath all four is the same condition, and it is worth stating plainly because it does not go away.

You cannot see what is on that device. Not the browser extensions, not the assistant with access to their desktop, not the tools they connected to their own accounts last month, not whatever arrived with them. You cannot inventory it, you cannot mandate what may be installed, and anything the machine reports about itself is a claim from a system you do not control.

This is a permanent condition, not a gap waiting for a product. Every approach that depends on knowing what is running on the endpoint — including the emerging model for governing AI agents, which asks agents to register and declare themselves — is defeated here by definition. No registry you deploy covers a contractor’s laptop.

So change the question

The question is not how to make an untrusted device trustworthy. You cannot, and the effort spent trying is the reason third-party access takes six weeks to arrange.

The question is how much it matters that it is untrusted — and that is entirely within your control, because it is decided by what the session is allowed to be, not by what the device is.

There are four ways to reduce it. They apply in order, and they compound.

First and second: validate, then bound

We have covered these two before, so briefly.

The session is established against the enforcement point, where identity, authentication strength, context and whatever device signals are genuinely available are evaluated — at the point of access, per request, rather than on an endpoint you cannot instrument. Then the session is given the resource rather than the network: it reaches the one application it was granted and receives no route onto anything else, because there is no route to receive.

The consequence is the one we described when we wrote about contractor and third-party access last February. Whatever is riding along inside that session — an assistant the contractor connected, malware they do not know about, an agent that never declared itself — is confined to exactly what the contractor was granted. Not because it was detected. Because there is nowhere else to go.

One caveat worth stating plainly, because it is the claim a technical reader will test: the device signals available from an unmanaged machine are not the signal set a managed endpoint produces, and any vendor telling you otherwise is selling you something. The comparison that matters is not with a corporate laptop. It is with the VPN account that was the realistic alternative, which asked nothing at all.

Third: move the critical path off the device entirely

For the access where bounding the radius is not enough, there is a further step, and it is the one that changes the risk rather than limiting it.

The application is published so that it executes in a controlled environment you do own — delivered to the contractor as a remote session rather than run on their machine. They interact with it. The application, its data and its credentials never land on the endpoint. What they are holding is a window.

This is the answer for the access that would otherwise be refused outright: an administrative tool, a system holding regulated data, the thing a supplier needs that nobody is comfortable exposing. And critically, it is applied after the session has been identified and validated against policy, not instead of it. Isolation is where a validated session is placed. It is not a way of skipping the validation.

Fourth: set the terms of the session yourself

Which raises the question a security reviewer asks immediately, and it is the right question. A remote session that permits clipboard, drive mapping and printing has moved the application off the device and handed the data straight back.

So those are not defaults to be inherited. They are parameters, and Total Access Control carries them into the session it publishes — what may be copied, what may be printed, whether local drives are mapped, what the window is permitted to do at all. The terms of the remote session are set by your policy rather than by whatever the endpoint or the protocol would allow if nobody specified.

And the same applies to getting data out through the ordinary path. File download can be filtered on authentication strength, device posture and context — so the capability is not a property of the application, it is a property of this session, opened by this person, from this device, in these circumstances.

That conditionality is what makes the whole thing workable commercially, because it means you rarely have to answer no.

The supplier who will not install an agent is not refused. They are given a session with no clipboard, no drive mapping, no printing and no download, into an application running somewhere you control. The same person, later, from a managed device with stronger authentication, gets a session with more in it. Nobody negotiated. Nobody made an exception. The policy simply produced a different session, and both are recorded the same way.

That is the graduated response. Ordinary access gets a bounded session. Sensitive access gets an isolated one. Risky context gets an isolated one with the exits closed. Every one of them is a policy decision on the same platform, made per user, per application, per context — rather than a separate product bought for each tier of risk.

And all of it stays in one place

None of the above is a separate product, and that is the part that matters more than any individual control.

Solving third-party access by buying a dedicated third-party access product solves third-party access and leaves the estate worse — another console, another policy model, another set of logs that has to be correlated with the others during an audit. That is exactly the pattern that produced the sprawl in the first place.

The same enforcement point that handles the contractor handles employees, remote administrators, an OT segment, the cloud and SaaS applications already running well, and the internal applications nobody could move. One policy model. One set of logs recording what was actually reached, by whom, on what. One place to answer an auditor, and one place to change your mind when the contract ends.

Third-party access is simply the case where the argument is easiest to see, because it is the case where you can watch every assumption fail at once.

Where to start

Take the third-party access path you would least like to explain to an auditor, and ask two questions about it.

What does this grant beyond the one application it exists for — and if that machine is already compromised, what have we actually lost?

Every organisation works with people who aren’t employees. Contractors. Consultants. Managed service providers. Vendors. Maintenance companies. Auditors. Each of these relationships involves a genuine business need for access to something inside your environment — and an equally genuine need to make sure that access goes no further than it should.

This is one of the most persistent and underappreciated challenges in enterprise security. And it’s one that TAC solves in a way that no VPN, no shared account, and no generic identity platform can match.

The Problem with Traditional Third-Party Access

When organisations need to give a third party access to something, the options have traditionally been unappealing. VPN access is blunt — it grants network-level access that is almost always broader than the relationship requires. Shared accounts are a compliance nightmare. Custom portals take months to build and maintain. And “just send them the URL and a login” creates ungoverned access that nobody is tracking.

The result is a patchwork of workarounds that security teams spend years trying to clean up — contractors with broader access than intended, service accounts that outlive the relationship, and legacy permissions that nobody has the confidence to revoke. TAC takes a fundamentally different approach. Rather than granting network access and hoping the boundaries hold, it grants access only to specific applications — enforced at the proxy layer, on every request, in real time.

A Portal Sized Exactly to the Relationship

When a third-party user authenticates to TAC, they see a portal. But unlike an employee’s portal — which might contain dozens of applications — a contractor’s portal contains exactly what they need for their role. Nothing more.

An HR consultant brought in for a six-month engagement might see an HR management system, a personnel records database, and a reporting tool. They don’t see the finance applications. They don’t see the engineering tools. They don’t see anything outside the scope of their work — because nothing outside the scope of their work is published to their portal.

In each case, the portal is the boundary. There is no network-level access to explore. There is no adjacent system to accidentally stumble into. The entire access surface is defined, explicit, and enforced.

When the Access Surface Is a Single Application

For some third-party relationships, the appropriate access isn’t a small portal — it’s a single application. TAC handles this just as cleanly. A user whose role requires access to one system gets a portal with one icon. One click, one connection, one scope. The rest of the organisation’s infrastructure doesn’t exist from their perspective. This level of precision — access to exactly one thing, enforced at the infrastructure level — is exactly what regulators and auditors want to see, and exactly what most organisations struggle to demonstrate with traditional access approaches.

Going Even Further: Direct Application Access Without a Portal

For some third-party relationships, even a single-application portal is more than is needed. TAC can publish an application directly — accessible via its own URL — without presenting the user with a portal at all. The contractor simply navigates to the application link, authenticates, and lands directly in the tool they need. There is no portal to navigate, no icons to click, no interface to learn.

This streamlines access even further for relationships where simplicity matters most. A field technician who needs to reach a single monitoring console once a week doesn’t need a portal — they need a link, a login, and immediate access to that one thing. TAC makes that possible while still enforcing all the same authentication, device posture, and policy controls that apply to every other access request. The experience is simpler; the security is not diminished.

Real-World Scenarios: Precision Access in Practice

The HVAC Maintenance Company

A facilities management company maintains the heating, ventilation, and air conditioning systems across your office estate. They need remote access to the building management console to run diagnostics, adjust settings, and respond to alerts. They have no legitimate business need to access anything else in your environment.

With TAC, the HVAC company’s technicians authenticate with their own credentials and are presented with a portal containing a single application: the building management system. They can connect to it, do their work, and disconnect. At no point do they have network-level access to anything else. Your file servers, your business applications, your cloud platforms — none of it is reachable from their session.

This matters more than it might appear. Building management systems are a well-documented entry point for attackers who compromise third-party maintenance vendors — the infamous Target breach in 2013 began with HVAC contractor credentials. TAC doesn’t just limit what the contractor can reach; it limits the blast radius if those credentials are ever compromised.

The Physical Security Provider

A contracted security company monitors your CCTV systems and manages access control for your physical premises. Their operators need to view camera feeds and manage door access schedules — nothing else. TAC publishes the security management console and the camera viewing platform to their portal. When a security operator logs in — with MFA enforced, device posture checked — they see those two applications and nothing beyond them. The logical separation is complete and auditable, demonstrable to insurers and regulators without relying on network diagrams that may or may not reflect reality.

The HR Consultant

An external HR consultancy is engaged to assist with a compensation review and talent mapping exercise. Their consultants need access to the HR information system, the compensation management platform, and relevant personnel data. They don’t need access to IT systems, financial platforms, or operational tools.

TAC provides a portal scoped precisely to those applications. The consultants work within that boundary for the duration of the engagement. When the engagement ends, access is revoked by removing the policy — cleanly, completely, without chasing down VPN accounts, Active Directory entries, or SaaS memberships across multiple systems. The offboarding is as simple as the onboarding.

The Software Development Partner

An external development agency building a new customer portal needs access to development and staging environments, code repositories, and specific APIs — not production systems, customer data, or internal business applications. TAC publishes those specific environments to the agency’s portal. Developers authenticate with strong MFA, device posture is validated, and they work within a precisely defined scope. If access needs change — perhaps production access is needed briefly for a deployment — the policy is updated centrally and takes effect immediately, with a complete audit trail of who had access to what and when.

Identity Without the Migration

One of the practical challenges of managing third-party access is identity. Contractors often can’t be given corporate email accounts. They may already have credentials from their own organisation. Building a parallel identity infrastructure for every type of external relationship is expensive and operationally complex.

TAC integrates with multiple identity sources simultaneously. Third-party users can authenticate through your organisation’s identity provider, their own identity provider via federation, or a local credential store maintained specifically for externals — all governed by the same policy engine, all producing the same granular access control. There is no need to provision corporate accounts for contractors or add them to your Active Directory.

MFA and Device Posture Apply to Everyone

A common gap in third-party access programmes is the assumption that security controls applied to employees don’t need to apply equally to outsiders. In practice, the opposite is often true — third-party accounts are disproportionately targeted precisely because they tend to have weaker controls.

TAC applies the same authentication and posture requirements to third-party users that it applies to everyone else. MFA is enforced at login. Device posture checks can be applied, ensuring that a contractor connecting from an unpatched or non-compliant device is denied access until compliance is achieved. These controls aren’t optional add-ons requiring separate configuration for each vendor relationship — they apply consistently, from the same policy engine, across every user whether internal or external.

A Complete Audit Trail

Every access request through TAC — regardless of whether it comes from an employee or a contractor — is logged. Who accessed what, when, from which device, from which location, and what policy decision governed that access. This audit trail is unified across all users and all applications in the portal.

When an auditor asks for evidence of what access the HVAC vendor had over the past twelve months, the answer is a query, not a manual reconstruction from multiple system logs. When a security incident requires understanding what a specific contractor account did during a particular window, the information is complete, accurate, and immediately available. This is what mature vendor access management looks like — and what regulators across SOC 2, ISO 27001, HIPAA, and other frameworks are increasingly expecting to see.

Clean Onboarding, Clean Offboarding

The lifecycle of third-party access has two ends, and both matter. Getting contractors set up quickly at the start of an engagement has real commercial value. Terminating access cleanly at the end — or when the relationship changes — has real security value.

With TAC, both ends are managed centrally. Onboarding a new contractor means creating credentials or federating their identity, and applying the relevant access policy. Offboarding means removing that policy — a single operation that takes effect immediately across every application in their portal. For organisations with dozens or hundreds of active vendor relationships, this operational simplicity is the difference between access management that actually happens and access management that exists only on paper.

The Bottom Line

Third-party access is one of the highest-risk areas of enterprise security — and one of the areas where the gap between policy intent and operational reality is most likely to cause problems. TAC closes that gap by making precise, granular, auditable access control as easy to implement for a contractor as it is for a full-time employee.

Whether the requirement is a single application for a maintenance vendor, a focused portal for a specialist consultant, or a carefully scoped environment for a development partner — TAC delivers it cleanly, securely, and without the operational overhead that makes good third-party access management so difficult to sustain.

Every third party, in their lane. That’s the TAC difference.

1. Over‑Privileged Accounts

Granting excessive permissions is a recipe for insider threats. To mitigate:

• Adopt a strict least‑privilege model.
• Use Total Access Control’s role‑based access control (RBAC) to map precise job functions.
• Schedule automated reviews of privileged accounts every 90 days.

2. Ignoring Device Health

Allowing access from unpatched or compromised devices expands risk. Remedy the issue by:

• Enabling device compliance checks within the policy engine.
• Integrating endpoint detection platforms to block vulnerable assets.
• Enforcing conditional access that requires up‑to‑date security software.

3. Static Password Policies

Relying solely on passwords, especially weak ones, leaves doors ajar. Strengthen authentication with:

• Multi‑factor authentication (MFA) for all privileged accounts.
• Adaptive risk‑based authentication that escalates verification based on context.
• Regular password rotation combined with password‑less options like FIDO2 tokens.

4. Lack of Real‑Time Monitoring

Delays in detecting anomalous behavior increase breach impact. Implement:

• Continuous audit logging via Total Access Control’s built‑in analytics.
• Real‑time alerts for unusual login locations or times.
• Integration with SIEM platforms for correlation with other security events.

5. Poor Documentation and Change Management

Without clear records, policies drift and compliance suffers. To stay organized:

• Maintain a version‑controlled policy repository.
• Document all changes, including rationale and approval workflows.
• Train staff on the documented processes to ensure consistency.

Putting It All Together

By addressing these common pitfalls, you can build a resilient access control framework that aligns with industry best practices and supports PortSys TAC’s mission to simplify powerful security.

Quick Checklist

1. Review and trim privileged accounts.
2. Enable device compliance checks.
3. Deploy MFA and adaptive authentication.
4. Activate real‑time monitoring and alerts.
5. Establish documented change management.

Take the first step today—run a quick audit using Total Access Control’s dashboard and see where improvements are needed.