Vendor reviews must verify that each session has a business purpose, approved path, and least privilege. An account's existence is not enough.
Classify vendor requests with a risk matrix
Classify each request before access is created. This ensures that controls match the vendor's role, connection method, data sensitivity, and remaining risk.
Score data sensitivity, system criticality, privilege level, connection path, vendor risk, safeguards, and remaining risk. Rate each item as low, moderate, high, or critical.
Require a named system and business owner. Require the vendor legal entity, user or service identity, and an end date.
Never approve a request described only as “vendor support access.”
| Access tier | Typical condition | Required controls | Review cycle |
|---|
| Low | No regulated data, no production access | Named identity, MFA, least privilege, 90-day expiry | Every 180 days |
| Moderate | Internal data or limited SaaS administration | MFA, scoped role, device checks, audit logging | Every 90 days |
| High | Customer data, production support, API write access | ZTNA, time-bound access, approval, session logs | Every 30 to 60 days |
| Critical | Admin rights, payment data, sensitive health data | PAM, just-in-time access, recording, dual approval | Per session or every 30 days |
Set approval from residual risk
Assign approval authority after scoring the request.
- The business owner approves low-risk access.
- TPRM and the system owner approve moderate-risk access.
- Security approves high-risk access.
- Critical access needs system-owner and security-leader approval.
- Document risk acceptance when a standard control is unavailable.
Vendor tier alone is not enough. A low-spend contractor with production admin rights may create more exposure than a strategic read-only vendor.
Approval record required for every vendor identity: internal owner, business purpose, target system, access scope, MFA method, connection path, privilege tier, start date, expiry date, reviewer, and exception reference where needed.
Turn due diligence into enforceable access
Turn assessment results into technical identity controls before the vendor connects. A questionnaire alone cannot stop unsafe access.
Require named identities and scopes
Create one identity for each vendor person, technician, service account, and API client. This ties activity to a real person or system.
For human access, require phishing-resistant MFA when supported. For APIs, use scoped tokens, short lifetimes, secret rotation, and service identities.
Do not use employee credentials for vendor API access.
Each approval should name the vendor, target app, allowed action, connection path, device need, and end date.
Match IAM, PAM, and ZTNA
Use IAM for account life cycles, group access, MFA, and access reviews. Use PAM for elevated work, such as server or cloud admin tasks.
Use ZTNA instead of broad VPN access when possible. ZTNA gives a vendor a narrow route to one app.
PAM can store credentials, grant short-term privilege, and record sessions. This works like issuing a timed key for one locked room.
Vendor decision to technical proof
1. Risk finding
High residual risk
→
2. Access rule
Named user, 30 days
→
3. Enforcement
MFA, PAM, ZTNA
→
4. Evidence
Logs and review record
Zero Trust for third parties relies on two assumptions: verify every request and block a compromised vendor identity from reaching unrelated systems.
Use a risk matrix before allowing a session. Include identity proof, device health, location, requested privilege, target sensitivity, and current threat signals.
MFA proves identity, but it does not limit access. Pair it with least privilege, ZTNA, and app or network separation.
For privileged access, PAM should grant just-in-time access through a controlled path. It should also log vendor sessions.
Risk can change during a session. An unmanaged device, impossible travel, or unusual commands should trigger stronger checks, limits, or session termination.
Manage, measure, and improve the vendor access lifecycle
Connect intake, approval, access setup, review, renewal, and offboarding in one recorded workflow. Measure live risk, not only completed questionnaires.
Assign clear ownership
Use a RACI model to set clear ownership across the access life cycle. “Accountable” owns the outcome, while “Responsible” does the work.
| Activity | Accountable | Responsible | Consulted |
|---|
| Business need and scope | Business owner | Business owner | TPRM, system owner |
| Risk tier and residual risk | TPRM leader | TPRM analyst | Security, legal |
Maintain audit-ready evidence
Keep proof of the approved risk review and the identity-to-vendor link. Record the business owner, access scope, end date, and login rules.
Keep records of privileged sessions, review decisions, exceptions, and time-stamped offboarding. Auditors need proof that controls worked.
PCI DSS, HIPAA, GLBA, SOC 2, ISO/IEC 27001, and the NIST Cybersecurity Framework require controlled and reviewed access.
Choose tools based on what they can enforce and prove. TPRM supports assessment workflows, while IAM governs identities and reviews.
PAM manages privileged sessions. SASE or ZTNA limits network paths.
Turn access data into clear operating measures. Track accounts without owners, permanent privileged accounts, shared accounts, overdue reviews, and revocation time.
Critical access should be removed within hours.
Apply controls by vendor connection model
Match controls to each vendor's connection method and allowed actions. A SaaS vendor, API client, and remote technician need different controls.
Control SaaS and API access
For SaaS links, approve the exact tenant, data objects, and actions needed. Then review OAuth consent, token scopes, token age, and unusual API volume.
For API clients, use workload identities and planned secret rotation. Use short-lived tokens when possible.
Broad write access without a named owner is high risk. That risk remains even when no person logs in.
Control support, MSPs, and developers
Require named technician identities and MFA for remote support and MSPs. Require just-in-time privileged access, session recording, and support-event approval.
Keep external developer access to code repositories separate from production access. Require a new approval for production troubleshooting.
Persistent VPN access is easy to use, but it provides weaker app-level proof than ZTNA with PAM.
⚠️ This model does not apply unchanged to vendors without access to systems, data, facilities, or APIs. Do not force an access workflow onto suppliers with no access path.
What people ask
Which vendors need zero trust access controls?
Any external party with access to systems, data, facilities, or APIs needs controls matched to its risk.
Is MFA enough for vendor access?
No. MFA verifies a person, but it does not limit privilege, record sessions, or control API tokens.
How often should vendor access be reviewed?
Review high-risk access every 30 to 60 days. Review moderate access every 90 days and low-risk access every 180 days.
Can vendors use shared accounts?
No. Shared accounts block attribution. Legacy exceptions need named checkout records, jump-host MFA, and short expiry.
What proves vendor access was removed?
Time-stamped proof of disabled accounts, revoked tokens, removed groups, and ended sessions proves removal.
What is just-in-time vendor access?
Just-in-time access grants elevated permission for a short approved period. It removes that permission automatically after the approved period.
Does SOC 2 prove a vendor has safe access?
No. A SOC 2 report supports due diligence, but it does not prove that local access is safely configured.
When should a vendor access exception be approved?
Approve an exception only when business needs cannot meet normal controls. Document safeguards, expiry, remaining risk, and risk ownership.
What matters most:- Base vendor access on residual risk, not vendor criticality alone.
- Turn each risk decision into named, time-bound technical controls.
- Use IAM, PAM, and ZTNA for different access needs.
- Review access after risk events and prove removal with timestamps.
- Measure orphaned access and revocation time to find real control gaps.
Learn more
Here are some additional resources on this subject:
