How do I set up identity and access management for secure vendor access in satellite operations?

Here’s a practical way to set up identity and access management (IAM) for secure vendor access in satellite operations. The goal is to let vendors do their job while tightly controlling what they can see, when they can access it, and how you can audit everything.

1) Start with a vendor access policy

Define, in writing:

• Who counts as a vendor
• What systems they may access
• Why they need access
• How long access lasts
• Approval process
• Logging and monitoring requirements
• Emergency access process
• Offboarding and revocation rules

For satellite operations, include systems such as:

• mission control / ground segment tools
• telemetry, tracking, and command interfaces
• satellite network operations systems
• patch management and support portals
• SIEM, ticketing, and remote support tools

2) Classify vendor roles and least-privilege permissions

Don’t give vendors broad “admin” access. Create role-based access tied to specific tasks:

• Telemetry analyst
• Ground system maintainer
• Network support engineer
• Software patch vendor
• Hardware OEM support
• Incident response specialist

For each role, define:

• allowed systems
• allowed actions
• allowed time windows
• allowed locations / networks
• whether read-only or write access is permitted

Use least privilege and separation of duties. For example, someone who can approve commands should not also be the same person making changes to command scripts.

3) Use a centralized identity provider

Use a centralized IAM/IdP such as:

• Azure AD / Entra ID
• Okta
• Ping
• Keycloak

Prefer federated identity for vendors instead of local accounts where possible. That way:

• vendors authenticate with their own identity provider
• you avoid unmanaged shared accounts
• you can enforce your own policies through federation

If vendors do not support federation, issue unique named accounts only. Never use shared generic logins like vendor1 or support.

4) Enforce strong authentication

Require:

• MFA everywhere
• preferably phishing-resistant MFA: FIDO2/security keys or certificate-based auth
• no SMS MFA for high-risk access
• strong password policy only as a baseline, not the main control

For privileged satellite ops access, use:

• step-up authentication
• conditional access
• device compliance checks
• certificates or privileged access workstations where feasible

5) Put privileged access behind a PAM solution

Use Privileged Access Management (PAM) for:

• just-in-time access
• time-limited elevation
• session recording
• command approval workflows
• credential vaulting
• checkout/check-in of secrets

This is especially important for:

• command and control environments
• jump hosts
• admin interfaces
• remote maintenance sessions

A good pattern is:

1. vendor logs into IdP with MFA
2. requests access through PAM
3. approval is granted for a limited time
4. access occurs through a bastion/jump host
5. session is recorded and monitored
6. credentials are not exposed directly to the vendor

6) Use segmented access paths

Never let vendor traffic go straight into mission-critical systems from the internet.

Use:

• VPN or ZTNA with device and identity checks
• jump servers / bastion hosts
• network segmentation
• separate vendor subnet or enclave
• firewall rules that only allow required destinations and ports

For satellite operations, strongly consider:

• a vendor DMZ
• separate IT support zone
• separate operations zone
• highly restricted paths into command/telemetry environments

7) Make access time-bound and case-based

Vendor accounts should be:

• temporary by default
• approved per ticket, change request, or incident
• automatically expired after the task ends
• reviewed regularly for inactivity

Good practice:

• access granted for a specific maintenance window
• explicit ticket reference required
• auto-disable after inactivity or expiration
• re-approval required for each new maintenance event

8) Secure secrets and service accounts

If vendors need credentials for automation or integration:

• store them in a vault
• rotate them regularly
• scope them narrowly
• avoid embedding secrets in scripts or documentation
• use service accounts with no interactive login if possible

For service accounts:

• separate by application and function
• no shared passwords between vendors
• rotate on handoff and offboarding
• monitor usage closely

9) Log everything and centralize monitoring

Record:

• successful and failed logins
• MFA challenges
• privilege elevation
• commands run
• file transfers
• configuration changes
• remote session recordings
• API calls

Send logs to a central SIEM and correlate with:

• ticket IDs
• change management records
• asset inventory
• threat detection alerts

For satellite operations, also monitor for:

• command anomalies
• unusual access outside maintenance windows
• access from unexpected geographies
• configuration changes to telemetry or command systems

10) Add approval and break-glass controls

For sensitive systems, require:

• manager approval
• system owner approval
• security approval for elevated access
• dual control for command execution, where appropriate

Also create a break-glass account for emergencies:

• heavily protected
• offline escrow or vault
• monitored and reviewed after every use
• no routine vendor access through this account

11) Build onboarding and offboarding workflows

Onboarding should include:

• identity proofing
• contract/NDA verification
• role assignment
• required training
• MFA enrollment
• access approval
• logging enrollment

Offboarding should automatically:

• disable accounts
• revoke tokens and certificates
• terminate VPN/ZTNA access
• remove from groups and roles
• rotate shared secrets
• review recent actions for anomalies

12) Align with security and operational standards

Useful frameworks to map to:

• NIST SP 800-53 for access control and auditing
• NIST SP 800-63 for identity assurance
• Zero Trust Architecture
• ISO 27001
• CIS Controls
• relevant space/mission assurance requirements and internal safety policies

13) Recommended reference architecture

A common secure pattern looks like this:

Vendor user
→ federated login to IdP with MFA
→ access request through PAM
→ session through ZTNA/VPN
→ bastion/jump host
→ target system in segmented operations network
→ full logging to SIEM

14) Minimum baseline you should not skip

If you need a quick checklist, at minimum implement:

• unique vendor identities
• MFA required
• no shared accounts
• least privilege RBAC
• time-limited access
• centralized logging
• jump host for sensitive systems
• approval workflow for elevated access
• immediate offboarding and credential revocation
• periodic access reviews

---

If you want, I can also provide:

1. a sample vendor IAM policy,
2. a reference architecture diagram, or
3. a step-by-step implementation plan for a satellite ops environment.