Just-in-Time Vendor Access: A Support Model for Document Platforms
Define who operates production, approve the access a case needs, and prove when that access ends
Published
A claims team uploads scanned documents, but hours later staff still cannot search their contents. The customer asks the platform vendor to help investigate. The engineer may need production logs and processing metrics, while the documents themselves contain sensitive personal information. The support process should make it clear who can approve access, what the engineer can do, and when that permission ends.
Just-in-time access means granting the permissions needed for a specific task for a limited period. It works best when the operating responsibilities, approval process, and technical enforcement are agreed before an incident.
1. Choose who operates production
| Support model | Responsibility to make explicit |
|---|---|
| Customer-operated, no vendor production access | Customer staff collect diagnostics and execute approved changes. They need the skills, runbooks, and on-call coverage to restore service. |
| Customer-operated with just-in-time vendor access | A customer approver authorizes a named engineer for a defined task and period. Agree who approves, monitors, and ends access, including outside business hours. |
| Vendor-managed operations | The vendor needs operational access consistent with its service responsibilities. Define routine permissions, elevated access, evidence, and customer oversight. |
A vendor can also work in non-production while customer staff apply the resulting fix in production. Keep production data out of lower environments unless its use is explicitly approved and protected. Document an emergency route with a reachable approver, limited scope, alerts, and a required follow-up review.
2. Start with diagnostics and escalate deliberately
Define separate permission sets for observation, deployment changes, data repair, and document access. An engineer investigating a backlog may need queue metrics and selected logs without needing document downloads or the ability to change application code.
Check what each permission enables indirectly. Logs and queue payloads can expose sensitive metadata. Permission to change code running under a privileged Lambda execution role can enable access to data even when the engineer’s own role cannot read it. Review deployment, role-passing, secret, backup, and key permissions together.
Use redacted diagnostics and synthetic reproductions first. If content access becomes necessary, approve the affected documents, purpose, permitted export, storage location, and deletion date separately. “Read-only” does not mean the information cannot be copied.
3. Make each grant specific and enforceable
Record the support case, named engineer, customer approver, account and environment, allowed actions and resources, start and end time, and expected outcome. A change in scope or duration requires a new approval.
Follow AWS guidance on federation, temporary credentials, MFA, and least privilege. Enforce authentication requirements through the selected identity system. Prevent the support identity from approving its own request, extending its grant, changing its permissions, or modifying the audit destination.
AWS detail: identify both the vendor and the engineer
For a vendor acting across customer accounts, configure the trusted principal and external ID appropriately. The external ID helps address the confused-deputy problem; it is not a secret or proof of an individual engineer’s identity.
Preserve the named identity through federation and role assumption. Where supported, require source identity from the trusted identity flow, and link the session to the approved support case. Test attribution in the resulting logs.
4. Check what your evidence actually covers
Link approval, authentication, role assumption, actions, changes, and closure to the case. Store the evidence somewhere the support identity cannot alter. Define collection and retention before access begins, and avoid copying document content or credentials into tickets and chat.
| Evidence needed | Coverage to verify |
|---|---|
| Approval and identity | The approved scope and period, identity-provider sign-in, role session, and support case can be connected to a named engineer. |
| Infrastructure changes | CloudTrail management events and deployment records cover the relevant services, accounts, and Regions. |
| Document and data access | Application audit and selected cloud data events cover the access paths permitted by the grant, including direct storage access where allowed. |
| Commands and results | Runbook, deployment, or supported session logs show what ran and its outcome. A cloud API log is not a recording of everything displayed on a screen. |
CloudTrail’s default event history covers 90 days of management events in a Region. S3 object reads and other data events require configured coverage and incur additional charges. Confirm selectors and retention against the approved support activities.
If shell access is part of the support model, verify its recording limits. For example, Session Manager logging does not record session contents for SSH or port-forwarding connections.
5. End new grants and existing sessions
Stopping new role assumptions does not end credentials already issued. Define how approval expiry closes the grant and how existing sessions lose permission at the required time. A session issued near the end of the approval window must not silently extend access beyond it.
AWS provides role-session revocation that denies sessions issued before a specified time. The standard operation affects all qualifying sessions for that role and does not prevent later assumptions. Combine it with the control that stops new grants, account for policy propagation, and use the appropriate revocation procedure for the identity system, including IAM Identity Center permission sets.
Also close application sessions, temporary API credentials, tunnels, and other access paths created for the case. Review presigned download links against the credentials that signed them; ending an engineer’s AWS session may not affect links issued by a separate application role. Access removal cannot recall files already downloaded, so confirm export handling and deletion separately.
A worked example: uploaded scans are not becoming searchable
Suppose a claims team’s scanned PDFs upload successfully, but their contents remain unavailable in search. These files need optical character recognition (OCR) to extract text before it can be indexed. The customer can confirm the symptom but needs the vendor’s help to find which processing step is delayed.
Approve a limited investigation
The customer grants a named engineer time-limited access to selected processing metrics and redacted error logs in one production account. This lets the engineer distinguish a text-extraction delay from an indexing failure. Opening claim documents or changing production is outside the grant.
Approve the proposed fix
In this example, the metrics and errors show that a bulk import is submitting text-extraction jobs faster than the service allows. The engineer recommends slowing that import and reviewing failed jobs for retry. Customer staff apply the approved changes through their runbook. If the vendor must perform the changes, that requires a separate scoped grant and validation plan.
Check the result and end access
Customer staff confirm that processing catches up and the affected documents become searchable. They end the grant, test that existing credentials are denied, and check that a new role assumption fails. The case retains the approval, engineer’s findings, change record, and validation results.
Test the arrangement before you need it
Ask procurement and operations to agree who operates production, support response hours, emergency approvers, subcontractor access, permitted data handling, evidence retention, revocation rights, and exit responsibilities. An approval dependency that nobody can satisfy at night changes the practical restoration target.
- Approved diagnostics work, while document reads and unapproved changes are denied.
- The engineer, case, and performed actions can be traced through the selected evidence.
- Expiry and early closure both block new grants and end existing access as designed.
- Emergency approval and restoration work when the usual approver is unavailable.
Technical guidance reviewed: November 10, 2026. Validate the access and logging configuration in the deployed environment.
Make support access ready for the incident
Agree who can approve support access, what the engineer may do, and how the grant and resulting actions will be reviewed. Test approval, expiry, early closure, and emergency operation alongside the restoration task so the access model supports the recovery the business expects.