Day Two of BYOC: Supporting and Troubleshooting Deployments You Don't Own
Supporting software running in a customer's cloud means you can't SSH in, can't read the logs, and can't reproduce the bug. Here's a practical playbook for building observability, secure remote access, and realistic SLAs for BYOC deployments. For product context, see Twingate's documentation.
You know the drill. A customer files a P1 at 2am. The stack trace they pasted is truncated. Your normal move is to open the dashboard, tail the logs, maybe hop on a box.
Except this deployment lives in their AWS account, behind their VPC, gated by their security team's change control, and the on-call engineer who has access is in a different time zone and doesn't work for you.
Bring Your Own Cloud (BYOC) has quietly become one of the more common ways enterprise software gets shipped. Databricks, Confluent, MongoDB Atlas, Snowflake, all offer some flavor of it. The pitch is straightforward: the customer keeps their data inside their own compliance boundary, and the vendor still gets to sell managed software. Everyone wins on paper. On day two, the support model gets weird.
This piece is a playbook for the teams that inherit that weirdness. If you're on support, SRE, or customer engineering at a vendor shipping into customer clouds (or if you're defining those processes) this is for you.
Why supporting BYOC is harder than SaaS
In pure SaaS, your support model is essentially: you own everything. When something breaks, you have root, you have the logs, you have the metrics, and you have a runbook. Mean time to diagnose is bounded by how fast your engineers can read a dashboard.
BYOC inverts that. The data plane runs in the customer's cloud account. The control plane usually runs in yours. The customer controls the network, IAM, and often the schedule for when you're allowed to touch anything. A partial list of the constraints that fall out of that:
You may not have any standing access to the running deployment. Getting in requires a ticket, an approver, and often a scheduled window.
Logs and metrics may not leave the customer's account by default. What's normal telemetry for you is data exfiltration for their security team.
Version drift is real. Some customers upgrade weekly. Others sit on an 18-month-old release because their change board hasn't approved the newer one.
The environment is not reproducible. Their VPC, their subnet layout, their proxy, their IAM policies — all subtly different from every other deployment you support.
Compliance boundaries are a hard constraint. HIPAA, PCI-DSS, FedRAMP, GDPR — these determine what you can copy out, look at, or store on your side.
The net effect: the diagnostic loop that takes minutes in SaaS can take days in BYOC. The whole support model has to be redesigned around not having hands on the machine.
The observability-first principle
The single highest-leverage move for supporting BYOC is to solve the problem before you need remote access. If your telemetry pipeline is good enough, you can diagnose 70–80% of issues without ever asking the customer for a session. Everything else in this playbook is a fallback for when observability isn't enough.
What "good enough" telemetry looks like
Ship telemetry out by default, on an opt-in basis, with the customer clearly in control of what goes where. Concretely, that usually means three streams:
Structured logs at the application and system level, with PII scrubbing applied before egress
Metrics covering both infrastructure (CPU, memory, disk, network) and application-level SLIs (request latency, error rate, queue depth, replication lag)
Traces for the request paths that matter most for your product
Push these to a vendor-side observability backend the customer has explicitly approved. The two design decisions that matter here:
Scrub at the source, not the destination. PII redaction, secret scrubbing, and customer-data filtering should happen inside the customer's environment before the data leaves. This is the difference between "we redact on ingest" (which requires trusting your pipeline) and "the raw data never left your account" (which is what a security review actually wants to hear).
Make the egress path explicit. The customer's network team wants to know exactly which endpoints you're calling and what's in the payload. Publish it. Provide a network diagram. If your egress goes through a specific set of IPs or hostnames, document them so they can be allowlisted cleanly.
The telemetry that actually helps
A common failure mode is shipping too much low-value data and none of the high-value stuff. Bias toward:
Structured events over free-text logs.
event=upgrade_failed reason=migration_timeout schema_version=42is worth tenINFO: something went wronglines.Version and configuration fingerprints. Every deployment should regularly emit its version, build SHA, feature flags, and non-secret config. Half of BYOC support tickets are eventually solved by discovering the deployment isn't running what the customer thinks it is.
Recent config changes. A rolling record of the last N config changes with timestamps is often the fastest path to root cause.
Health signatures. Not just "am I up" but "am I healthy in the ways that matter for this product." A running process that can't reach its dependency is worse than a crash.|
A minimal collector pattern
The pattern most BYOC vendors converge on looks something like this: an agent runs inside the customer's environment, collects local telemetry, applies redaction and filtering, and pushes it outbound over TLS to a vendor endpoint. No inbound connections into the customer's environment.
The outbound-only shape matters. It's the same reason zero trust access architectures avoid inbound firewall rules — anything that requires opening a port into a customer's network is going to lose fights with their security team. Outbound with mTLS and clear audit is easier to get approved and easier to defend.
Secure remote access, when you actually need it
Observability handles most of the volume, but there is always a residual set of issues where you need a human on the box. Kernel weirdness, stuck processes, database corruption, or the classic "the logs say everything is fine but nothing works." For these, you need a remote access model that's fast enough to be useful and disciplined enough to survive an audit.
Design principles
Whatever pattern you pick, it should satisfy these:
No standing access. No shared bastion account with a key that lives in a password manager. Every session is provisioned on request and revoked automatically.
Time-boxed by default. Sessions expire. If the engineer needs more time, they request an extension and the clock is visible.
Customer-approved. Access requires an approval that lives in the customer's system of record, not just yours. Slack DMs don't count.
Fully audited. Session recording, command logging, or at minimum a durable record of who connected, when, and to what.
Least privilege at the resource level, not the network level. The engineer accessing a stuck Kafka broker should not also be able to reach the customer's payment database that happens to live in the same VPC.
That last point is the one traditional VPN-based support models get wrong. Punching a VPN tunnel into the customer's network gives your engineer network reachability to everything on that subnet. It's fast, and it's a nightmare in a compliance review. The modern alternative is resource-based access: the engineer gets a session to a specific service or host, not a network.
Twingate's architecture is designed around exactly this pattern. Connectors deployed inside the customer's environment maintain outbound-only connections to the Twingate Controller. When a support engineer needs to reach a specific resource, the Controller checks policy, issues a time-bound authorization, and the connection is proxied through the Connector to only that resource. No inbound firewall rules on the customer side, no lateral network access on the engineer side, and every session is logged.
Break-glass patterns that don't compromise the model
There's always a genuine emergency where the normal approval flow is too slow. The instinct is to build a "break glass" path that bypasses controls. Do this carefully or don't do it at all — most compromised support systems started as a legitimate break-glass workflow that stopped being exceptional.
A defensible break-glass pattern:
Requires two humans, not one. The engineer requesting access and a second approver on your side (not the customer).
Escalates automatically to the customer's security contact, even if it doesn't wait for them.
Grants the shortest possible session — measured in minutes, not hours.
Triggers a mandatory post-incident review with the customer, including a session recording or command log.
Is used rarely enough that a spike in usage is itself an alert.
If break-glass is a routine part of your support workflow, it's not break-glass. It's just your access model, and it's a bad one.
Approval workflows that don't grind support to a halt
The hard part of customer-approved access isn't the approval itself. It's making sure the approval can happen at 3am when the customer's on-call is asleep. A few patterns that work:
Pre-approved runbooks. For well-defined maintenance operations (rotating a certificate, restarting a specific service), the customer approves the class of action ahead of time, and specific instances are self-service within that scope.
Standing approvers with rotation. The customer designates a small group of engineers who are authorized to approve emergency support access. Approval requests go to whoever is on-call.
Asynchronous approvals with escalation. Requests default to notifying the customer but auto-approve after N minutes if there's no response and the request meets specific criteria (severity, scope, requester).
None of these are universal. Larger enterprises usually want synchronous approval with a real human. Smaller teams often prefer async with escalation. Design for both, and let the customer pick during onboarding.
SLAs and expectations for a support model you don't fully control
Here's where operations leaders get burned. You promised a four-hour resolution SLA because that's what your competitors promise. Then you shipped BYOC, and now your ability to resolve depends on how fast a customer can approve access to their own environment. The SLA math no longer works.
The honest fix is to write SLAs that reflect the shared-responsibility reality of BYOC.
Split the clock
Every SLA has an implicit clock. In BYOC, that clock should pause when the ball is in the customer's court. Concretely:
Response time: how fast you acknowledge the ticket and start work. This is fully on you.
Diagnosis time: how fast you identify root cause. This depends on telemetry. Mostly on you, with a dependency on whether observability was enabled and healthy.
Resolution time: how fast the fix is applied. This depends on customer approval for access, change windows, and sometimes the customer applying an upgrade themselves.
Publish these separately. A single "resolution SLA" that combines all three is dishonest and impossible to hit consistently.
Tier by observability posture
A customer who has enabled full telemetry export and pre-approved a small set of support access patterns should have faster SLAs than a customer who has disabled telemetry and requires synchronous approval for every session. This isn't a punishment — it's the truth. You can't diagnose faster than the data allows.
Make this explicit in the contract. Something like:
Standard tier: Telemetry export enabled, pre-approved access for defined operations. Four-hour diagnosis SLA.
Restricted tier: No telemetry export, synchronous approval required. Best-effort diagnosis, resolution SLA on paused clock.
Some customers will pick restricted anyway. That's fine. They now understand what they're trading.
Set expectations during onboarding, not during outages
The single biggest cause of BYOC support disasters is a mismatch between what the customer expected and what the vendor can actually do inside their environment. Handle this during implementation:
Walk through the telemetry pipeline. Show the redaction rules. Get sign-off from their security team on what leaves the environment.
Walk through the access model. Provision a test session so their team sees exactly what happens when a support engineer connects.
Document the escalation path with named contacts, not just role-based inboxes. On-call at 3am doesn't work through generic aliases.
Do a tabletop exercise. Pick a plausible P1 scenario and walk through the whole flow: alert fires, ticket opens, engineer requests access, customer approves, session happens, resolution documented. Find where it breaks before it breaks in production.
Most of this feels heavy during onboarding. It's much lighter than the alternative.
A short checklist
If you're standing up a BYOC support model from scratch, or fixing one that's straining, work through this list:
Is telemetry opt-in, well-documented, and scrubbed at the source before egress?
Can you diagnose the top ten most common issues without any customer interaction?
Is there a version/config fingerprint emitted regularly by every deployment?
Does your remote access model provision to specific resources, not networks?
Are all sessions time-boxed and audited by default?
Is break-glass a documented exception with two-person control, or is it your regular workflow with extra steps?
Do your SLAs separate response, diagnosis, and resolution?
Does the SLA clock pause when you're waiting on customer approval?
Was the whole flow walked through during onboarding, including a live test session?
Do you have a documented escalation path with named humans, not just aliases?
If most of those are yes, you have a support model that will survive real incidents. If most are no, the first big customer P1 is going to teach you something painful.
Closing
For teams building the access side of this — outbound-only connectivity, time-boxed sessions, resource-level policy, and full session audit — Twingate's Connector and Identity Firewall documentation covers the patterns described here. The Twingate documentation is the best starting point for implementation specifics.
New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
Day Two of BYOC: Supporting and Troubleshooting Deployments You Don't Own
Supporting software running in a customer's cloud means you can't SSH in, can't read the logs, and can't reproduce the bug. Here's a practical playbook for building observability, secure remote access, and realistic SLAs for BYOC deployments. For product context, see Twingate's documentation.
You know the drill. A customer files a P1 at 2am. The stack trace they pasted is truncated. Your normal move is to open the dashboard, tail the logs, maybe hop on a box.
Except this deployment lives in their AWS account, behind their VPC, gated by their security team's change control, and the on-call engineer who has access is in a different time zone and doesn't work for you.
Bring Your Own Cloud (BYOC) has quietly become one of the more common ways enterprise software gets shipped. Databricks, Confluent, MongoDB Atlas, Snowflake, all offer some flavor of it. The pitch is straightforward: the customer keeps their data inside their own compliance boundary, and the vendor still gets to sell managed software. Everyone wins on paper. On day two, the support model gets weird.
This piece is a playbook for the teams that inherit that weirdness. If you're on support, SRE, or customer engineering at a vendor shipping into customer clouds (or if you're defining those processes) this is for you.
Why supporting BYOC is harder than SaaS
In pure SaaS, your support model is essentially: you own everything. When something breaks, you have root, you have the logs, you have the metrics, and you have a runbook. Mean time to diagnose is bounded by how fast your engineers can read a dashboard.
BYOC inverts that. The data plane runs in the customer's cloud account. The control plane usually runs in yours. The customer controls the network, IAM, and often the schedule for when you're allowed to touch anything. A partial list of the constraints that fall out of that:
You may not have any standing access to the running deployment. Getting in requires a ticket, an approver, and often a scheduled window.
Logs and metrics may not leave the customer's account by default. What's normal telemetry for you is data exfiltration for their security team.
Version drift is real. Some customers upgrade weekly. Others sit on an 18-month-old release because their change board hasn't approved the newer one.
The environment is not reproducible. Their VPC, their subnet layout, their proxy, their IAM policies — all subtly different from every other deployment you support.
Compliance boundaries are a hard constraint. HIPAA, PCI-DSS, FedRAMP, GDPR — these determine what you can copy out, look at, or store on your side.
The net effect: the diagnostic loop that takes minutes in SaaS can take days in BYOC. The whole support model has to be redesigned around not having hands on the machine.
The observability-first principle
The single highest-leverage move for supporting BYOC is to solve the problem before you need remote access. If your telemetry pipeline is good enough, you can diagnose 70–80% of issues without ever asking the customer for a session. Everything else in this playbook is a fallback for when observability isn't enough.
What "good enough" telemetry looks like
Ship telemetry out by default, on an opt-in basis, with the customer clearly in control of what goes where. Concretely, that usually means three streams:
Structured logs at the application and system level, with PII scrubbing applied before egress
Metrics covering both infrastructure (CPU, memory, disk, network) and application-level SLIs (request latency, error rate, queue depth, replication lag)
Traces for the request paths that matter most for your product
Push these to a vendor-side observability backend the customer has explicitly approved. The two design decisions that matter here:
Scrub at the source, not the destination. PII redaction, secret scrubbing, and customer-data filtering should happen inside the customer's environment before the data leaves. This is the difference between "we redact on ingest" (which requires trusting your pipeline) and "the raw data never left your account" (which is what a security review actually wants to hear).
Make the egress path explicit. The customer's network team wants to know exactly which endpoints you're calling and what's in the payload. Publish it. Provide a network diagram. If your egress goes through a specific set of IPs or hostnames, document them so they can be allowlisted cleanly.
The telemetry that actually helps
A common failure mode is shipping too much low-value data and none of the high-value stuff. Bias toward:
Structured events over free-text logs.
event=upgrade_failed reason=migration_timeout schema_version=42is worth tenINFO: something went wronglines.Version and configuration fingerprints. Every deployment should regularly emit its version, build SHA, feature flags, and non-secret config. Half of BYOC support tickets are eventually solved by discovering the deployment isn't running what the customer thinks it is.
Recent config changes. A rolling record of the last N config changes with timestamps is often the fastest path to root cause.
Health signatures. Not just "am I up" but "am I healthy in the ways that matter for this product." A running process that can't reach its dependency is worse than a crash.|
A minimal collector pattern
The pattern most BYOC vendors converge on looks something like this: an agent runs inside the customer's environment, collects local telemetry, applies redaction and filtering, and pushes it outbound over TLS to a vendor endpoint. No inbound connections into the customer's environment.
The outbound-only shape matters. It's the same reason zero trust access architectures avoid inbound firewall rules — anything that requires opening a port into a customer's network is going to lose fights with their security team. Outbound with mTLS and clear audit is easier to get approved and easier to defend.
Secure remote access, when you actually need it
Observability handles most of the volume, but there is always a residual set of issues where you need a human on the box. Kernel weirdness, stuck processes, database corruption, or the classic "the logs say everything is fine but nothing works." For these, you need a remote access model that's fast enough to be useful and disciplined enough to survive an audit.
Design principles
Whatever pattern you pick, it should satisfy these:
No standing access. No shared bastion account with a key that lives in a password manager. Every session is provisioned on request and revoked automatically.
Time-boxed by default. Sessions expire. If the engineer needs more time, they request an extension and the clock is visible.
Customer-approved. Access requires an approval that lives in the customer's system of record, not just yours. Slack DMs don't count.
Fully audited. Session recording, command logging, or at minimum a durable record of who connected, when, and to what.
Least privilege at the resource level, not the network level. The engineer accessing a stuck Kafka broker should not also be able to reach the customer's payment database that happens to live in the same VPC.
That last point is the one traditional VPN-based support models get wrong. Punching a VPN tunnel into the customer's network gives your engineer network reachability to everything on that subnet. It's fast, and it's a nightmare in a compliance review. The modern alternative is resource-based access: the engineer gets a session to a specific service or host, not a network.
Twingate's architecture is designed around exactly this pattern. Connectors deployed inside the customer's environment maintain outbound-only connections to the Twingate Controller. When a support engineer needs to reach a specific resource, the Controller checks policy, issues a time-bound authorization, and the connection is proxied through the Connector to only that resource. No inbound firewall rules on the customer side, no lateral network access on the engineer side, and every session is logged.
Break-glass patterns that don't compromise the model
There's always a genuine emergency where the normal approval flow is too slow. The instinct is to build a "break glass" path that bypasses controls. Do this carefully or don't do it at all — most compromised support systems started as a legitimate break-glass workflow that stopped being exceptional.
A defensible break-glass pattern:
Requires two humans, not one. The engineer requesting access and a second approver on your side (not the customer).
Escalates automatically to the customer's security contact, even if it doesn't wait for them.
Grants the shortest possible session — measured in minutes, not hours.
Triggers a mandatory post-incident review with the customer, including a session recording or command log.
Is used rarely enough that a spike in usage is itself an alert.
If break-glass is a routine part of your support workflow, it's not break-glass. It's just your access model, and it's a bad one.
Approval workflows that don't grind support to a halt
The hard part of customer-approved access isn't the approval itself. It's making sure the approval can happen at 3am when the customer's on-call is asleep. A few patterns that work:
Pre-approved runbooks. For well-defined maintenance operations (rotating a certificate, restarting a specific service), the customer approves the class of action ahead of time, and specific instances are self-service within that scope.
Standing approvers with rotation. The customer designates a small group of engineers who are authorized to approve emergency support access. Approval requests go to whoever is on-call.
Asynchronous approvals with escalation. Requests default to notifying the customer but auto-approve after N minutes if there's no response and the request meets specific criteria (severity, scope, requester).
None of these are universal. Larger enterprises usually want synchronous approval with a real human. Smaller teams often prefer async with escalation. Design for both, and let the customer pick during onboarding.
SLAs and expectations for a support model you don't fully control
Here's where operations leaders get burned. You promised a four-hour resolution SLA because that's what your competitors promise. Then you shipped BYOC, and now your ability to resolve depends on how fast a customer can approve access to their own environment. The SLA math no longer works.
The honest fix is to write SLAs that reflect the shared-responsibility reality of BYOC.
Split the clock
Every SLA has an implicit clock. In BYOC, that clock should pause when the ball is in the customer's court. Concretely:
Response time: how fast you acknowledge the ticket and start work. This is fully on you.
Diagnosis time: how fast you identify root cause. This depends on telemetry. Mostly on you, with a dependency on whether observability was enabled and healthy.
Resolution time: how fast the fix is applied. This depends on customer approval for access, change windows, and sometimes the customer applying an upgrade themselves.
Publish these separately. A single "resolution SLA" that combines all three is dishonest and impossible to hit consistently.
Tier by observability posture
A customer who has enabled full telemetry export and pre-approved a small set of support access patterns should have faster SLAs than a customer who has disabled telemetry and requires synchronous approval for every session. This isn't a punishment — it's the truth. You can't diagnose faster than the data allows.
Make this explicit in the contract. Something like:
Standard tier: Telemetry export enabled, pre-approved access for defined operations. Four-hour diagnosis SLA.
Restricted tier: No telemetry export, synchronous approval required. Best-effort diagnosis, resolution SLA on paused clock.
Some customers will pick restricted anyway. That's fine. They now understand what they're trading.
Set expectations during onboarding, not during outages
The single biggest cause of BYOC support disasters is a mismatch between what the customer expected and what the vendor can actually do inside their environment. Handle this during implementation:
Walk through the telemetry pipeline. Show the redaction rules. Get sign-off from their security team on what leaves the environment.
Walk through the access model. Provision a test session so their team sees exactly what happens when a support engineer connects.
Document the escalation path with named contacts, not just role-based inboxes. On-call at 3am doesn't work through generic aliases.
Do a tabletop exercise. Pick a plausible P1 scenario and walk through the whole flow: alert fires, ticket opens, engineer requests access, customer approves, session happens, resolution documented. Find where it breaks before it breaks in production.
Most of this feels heavy during onboarding. It's much lighter than the alternative.
A short checklist
If you're standing up a BYOC support model from scratch, or fixing one that's straining, work through this list:
Is telemetry opt-in, well-documented, and scrubbed at the source before egress?
Can you diagnose the top ten most common issues without any customer interaction?
Is there a version/config fingerprint emitted regularly by every deployment?
Does your remote access model provision to specific resources, not networks?
Are all sessions time-boxed and audited by default?
Is break-glass a documented exception with two-person control, or is it your regular workflow with extra steps?
Do your SLAs separate response, diagnosis, and resolution?
Does the SLA clock pause when you're waiting on customer approval?
Was the whole flow walked through during onboarding, including a live test session?
Do you have a documented escalation path with named humans, not just aliases?
If most of those are yes, you have a support model that will survive real incidents. If most are no, the first big customer P1 is going to teach you something painful.
Closing
For teams building the access side of this — outbound-only connectivity, time-boxed sessions, resource-level policy, and full session audit — Twingate's Connector and Identity Firewall documentation covers the patterns described here. The Twingate documentation is the best starting point for implementation specifics.
New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
Day Two of BYOC: Supporting and Troubleshooting Deployments You Don't Own
Supporting software running in a customer's cloud means you can't SSH in, can't read the logs, and can't reproduce the bug. Here's a practical playbook for building observability, secure remote access, and realistic SLAs for BYOC deployments. For product context, see Twingate's documentation.
You know the drill. A customer files a P1 at 2am. The stack trace they pasted is truncated. Your normal move is to open the dashboard, tail the logs, maybe hop on a box.
Except this deployment lives in their AWS account, behind their VPC, gated by their security team's change control, and the on-call engineer who has access is in a different time zone and doesn't work for you.
Bring Your Own Cloud (BYOC) has quietly become one of the more common ways enterprise software gets shipped. Databricks, Confluent, MongoDB Atlas, Snowflake, all offer some flavor of it. The pitch is straightforward: the customer keeps their data inside their own compliance boundary, and the vendor still gets to sell managed software. Everyone wins on paper. On day two, the support model gets weird.
This piece is a playbook for the teams that inherit that weirdness. If you're on support, SRE, or customer engineering at a vendor shipping into customer clouds (or if you're defining those processes) this is for you.
Why supporting BYOC is harder than SaaS
In pure SaaS, your support model is essentially: you own everything. When something breaks, you have root, you have the logs, you have the metrics, and you have a runbook. Mean time to diagnose is bounded by how fast your engineers can read a dashboard.
BYOC inverts that. The data plane runs in the customer's cloud account. The control plane usually runs in yours. The customer controls the network, IAM, and often the schedule for when you're allowed to touch anything. A partial list of the constraints that fall out of that:
You may not have any standing access to the running deployment. Getting in requires a ticket, an approver, and often a scheduled window.
Logs and metrics may not leave the customer's account by default. What's normal telemetry for you is data exfiltration for their security team.
Version drift is real. Some customers upgrade weekly. Others sit on an 18-month-old release because their change board hasn't approved the newer one.
The environment is not reproducible. Their VPC, their subnet layout, their proxy, their IAM policies — all subtly different from every other deployment you support.
Compliance boundaries are a hard constraint. HIPAA, PCI-DSS, FedRAMP, GDPR — these determine what you can copy out, look at, or store on your side.
The net effect: the diagnostic loop that takes minutes in SaaS can take days in BYOC. The whole support model has to be redesigned around not having hands on the machine.
The observability-first principle
The single highest-leverage move for supporting BYOC is to solve the problem before you need remote access. If your telemetry pipeline is good enough, you can diagnose 70–80% of issues without ever asking the customer for a session. Everything else in this playbook is a fallback for when observability isn't enough.
What "good enough" telemetry looks like
Ship telemetry out by default, on an opt-in basis, with the customer clearly in control of what goes where. Concretely, that usually means three streams:
Structured logs at the application and system level, with PII scrubbing applied before egress
Metrics covering both infrastructure (CPU, memory, disk, network) and application-level SLIs (request latency, error rate, queue depth, replication lag)
Traces for the request paths that matter most for your product
Push these to a vendor-side observability backend the customer has explicitly approved. The two design decisions that matter here:
Scrub at the source, not the destination. PII redaction, secret scrubbing, and customer-data filtering should happen inside the customer's environment before the data leaves. This is the difference between "we redact on ingest" (which requires trusting your pipeline) and "the raw data never left your account" (which is what a security review actually wants to hear).
Make the egress path explicit. The customer's network team wants to know exactly which endpoints you're calling and what's in the payload. Publish it. Provide a network diagram. If your egress goes through a specific set of IPs or hostnames, document them so they can be allowlisted cleanly.
The telemetry that actually helps
A common failure mode is shipping too much low-value data and none of the high-value stuff. Bias toward:
Structured events over free-text logs.
event=upgrade_failed reason=migration_timeout schema_version=42is worth tenINFO: something went wronglines.Version and configuration fingerprints. Every deployment should regularly emit its version, build SHA, feature flags, and non-secret config. Half of BYOC support tickets are eventually solved by discovering the deployment isn't running what the customer thinks it is.
Recent config changes. A rolling record of the last N config changes with timestamps is often the fastest path to root cause.
Health signatures. Not just "am I up" but "am I healthy in the ways that matter for this product." A running process that can't reach its dependency is worse than a crash.|
A minimal collector pattern
The pattern most BYOC vendors converge on looks something like this: an agent runs inside the customer's environment, collects local telemetry, applies redaction and filtering, and pushes it outbound over TLS to a vendor endpoint. No inbound connections into the customer's environment.
The outbound-only shape matters. It's the same reason zero trust access architectures avoid inbound firewall rules — anything that requires opening a port into a customer's network is going to lose fights with their security team. Outbound with mTLS and clear audit is easier to get approved and easier to defend.
Secure remote access, when you actually need it
Observability handles most of the volume, but there is always a residual set of issues where you need a human on the box. Kernel weirdness, stuck processes, database corruption, or the classic "the logs say everything is fine but nothing works." For these, you need a remote access model that's fast enough to be useful and disciplined enough to survive an audit.
Design principles
Whatever pattern you pick, it should satisfy these:
No standing access. No shared bastion account with a key that lives in a password manager. Every session is provisioned on request and revoked automatically.
Time-boxed by default. Sessions expire. If the engineer needs more time, they request an extension and the clock is visible.
Customer-approved. Access requires an approval that lives in the customer's system of record, not just yours. Slack DMs don't count.
Fully audited. Session recording, command logging, or at minimum a durable record of who connected, when, and to what.
Least privilege at the resource level, not the network level. The engineer accessing a stuck Kafka broker should not also be able to reach the customer's payment database that happens to live in the same VPC.
That last point is the one traditional VPN-based support models get wrong. Punching a VPN tunnel into the customer's network gives your engineer network reachability to everything on that subnet. It's fast, and it's a nightmare in a compliance review. The modern alternative is resource-based access: the engineer gets a session to a specific service or host, not a network.
Twingate's architecture is designed around exactly this pattern. Connectors deployed inside the customer's environment maintain outbound-only connections to the Twingate Controller. When a support engineer needs to reach a specific resource, the Controller checks policy, issues a time-bound authorization, and the connection is proxied through the Connector to only that resource. No inbound firewall rules on the customer side, no lateral network access on the engineer side, and every session is logged.
Break-glass patterns that don't compromise the model
There's always a genuine emergency where the normal approval flow is too slow. The instinct is to build a "break glass" path that bypasses controls. Do this carefully or don't do it at all — most compromised support systems started as a legitimate break-glass workflow that stopped being exceptional.
A defensible break-glass pattern:
Requires two humans, not one. The engineer requesting access and a second approver on your side (not the customer).
Escalates automatically to the customer's security contact, even if it doesn't wait for them.
Grants the shortest possible session — measured in minutes, not hours.
Triggers a mandatory post-incident review with the customer, including a session recording or command log.
Is used rarely enough that a spike in usage is itself an alert.
If break-glass is a routine part of your support workflow, it's not break-glass. It's just your access model, and it's a bad one.
Approval workflows that don't grind support to a halt
The hard part of customer-approved access isn't the approval itself. It's making sure the approval can happen at 3am when the customer's on-call is asleep. A few patterns that work:
Pre-approved runbooks. For well-defined maintenance operations (rotating a certificate, restarting a specific service), the customer approves the class of action ahead of time, and specific instances are self-service within that scope.
Standing approvers with rotation. The customer designates a small group of engineers who are authorized to approve emergency support access. Approval requests go to whoever is on-call.
Asynchronous approvals with escalation. Requests default to notifying the customer but auto-approve after N minutes if there's no response and the request meets specific criteria (severity, scope, requester).
None of these are universal. Larger enterprises usually want synchronous approval with a real human. Smaller teams often prefer async with escalation. Design for both, and let the customer pick during onboarding.
SLAs and expectations for a support model you don't fully control
Here's where operations leaders get burned. You promised a four-hour resolution SLA because that's what your competitors promise. Then you shipped BYOC, and now your ability to resolve depends on how fast a customer can approve access to their own environment. The SLA math no longer works.
The honest fix is to write SLAs that reflect the shared-responsibility reality of BYOC.
Split the clock
Every SLA has an implicit clock. In BYOC, that clock should pause when the ball is in the customer's court. Concretely:
Response time: how fast you acknowledge the ticket and start work. This is fully on you.
Diagnosis time: how fast you identify root cause. This depends on telemetry. Mostly on you, with a dependency on whether observability was enabled and healthy.
Resolution time: how fast the fix is applied. This depends on customer approval for access, change windows, and sometimes the customer applying an upgrade themselves.
Publish these separately. A single "resolution SLA" that combines all three is dishonest and impossible to hit consistently.
Tier by observability posture
A customer who has enabled full telemetry export and pre-approved a small set of support access patterns should have faster SLAs than a customer who has disabled telemetry and requires synchronous approval for every session. This isn't a punishment — it's the truth. You can't diagnose faster than the data allows.
Make this explicit in the contract. Something like:
Standard tier: Telemetry export enabled, pre-approved access for defined operations. Four-hour diagnosis SLA.
Restricted tier: No telemetry export, synchronous approval required. Best-effort diagnosis, resolution SLA on paused clock.
Some customers will pick restricted anyway. That's fine. They now understand what they're trading.
Set expectations during onboarding, not during outages
The single biggest cause of BYOC support disasters is a mismatch between what the customer expected and what the vendor can actually do inside their environment. Handle this during implementation:
Walk through the telemetry pipeline. Show the redaction rules. Get sign-off from their security team on what leaves the environment.
Walk through the access model. Provision a test session so their team sees exactly what happens when a support engineer connects.
Document the escalation path with named contacts, not just role-based inboxes. On-call at 3am doesn't work through generic aliases.
Do a tabletop exercise. Pick a plausible P1 scenario and walk through the whole flow: alert fires, ticket opens, engineer requests access, customer approves, session happens, resolution documented. Find where it breaks before it breaks in production.
Most of this feels heavy during onboarding. It's much lighter than the alternative.
A short checklist
If you're standing up a BYOC support model from scratch, or fixing one that's straining, work through this list:
Is telemetry opt-in, well-documented, and scrubbed at the source before egress?
Can you diagnose the top ten most common issues without any customer interaction?
Is there a version/config fingerprint emitted regularly by every deployment?
Does your remote access model provision to specific resources, not networks?
Are all sessions time-boxed and audited by default?
Is break-glass a documented exception with two-person control, or is it your regular workflow with extra steps?
Do your SLAs separate response, diagnosis, and resolution?
Does the SLA clock pause when you're waiting on customer approval?
Was the whole flow walked through during onboarding, including a live test session?
Do you have a documented escalation path with named humans, not just aliases?
If most of those are yes, you have a support model that will survive real incidents. If most are no, the first big customer P1 is going to teach you something painful.
Closing
For teams building the access side of this — outbound-only connectivity, time-boxed sessions, resource-level policy, and full session audit — Twingate's Connector and Identity Firewall documentation covers the patterns described here. The Twingate documentation is the best starting point for implementation specifics.
New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.
Solutions
Solutions
The VPN replacement your workforce will love.
Solutions