Why mTLS between services needs a self-hosted CA in regulated environments
Regulated teams often reach the point where services call each other over internal networks, and the auditor asks two plain questions: which service is this, and how is its access logged? Network location and shared static credentials cannot answer either one well. Mutual TLS gives every service its own certificate, so each side of a connection presents an identity that can be checked and recorded. A self-hosted certificate authority is the usual place to issue those identities, because the trust chain, the lifetimes and the audit trail stay under your control inside your own infrastructure.
Once every workload depends on a certificate, the CA becomes a production dependency. Short lifetimes move the main risk from expiry to issuance: if the CA cannot sign renewals, services fail on their next rotation rather than on a date you can see coming. That is why the design has to answer what happens during a CA outage, who may request certificates, and how each request is authorized. Confirm with your platform team how many renewals per hour your busiest clusters will generate, and test the issuing path under load before you commit to lifetimes.
The short answer for most teams is to use step-ca for workload issuance and configure its provisioners to match how workloads prove identity, such as cloud instance identity, OIDC or JWK. Use OpenBao PKI where secrets and auth methods already run and the team already operates its storage and high availability. Whichever you choose, decide in writing which system owns the root and intermediate keys and which owns issuance policy, because two CAs issuing into the same trust path without a clear owner is a common source of audit findings. Check the step-ca license and the OpenBao repository against your procurement rules before you finalize the choice.
Which regulatory requirements shape service identity and what they mean for the build
This table maps two US rules to concrete service identity build items for a self-hosted CA. Read each row as a requirement, the build item that supports it, and the evidence an assessor will look for. Certificates support these controls but do not satisfy them alone, so confirm applicability with counsel or an assessor.
| Requirement | What it asks for | Build item for mTLS | Evidence to keep |
|---|---|---|---|
| Unique user identification (45 CFR 164.312(a)(2)(i)) | Each user of a system holding ePHI must be uniquely identifiable | Give every service and workload its own certificate identity, with no shared client certificates across services | Issuance records mapping each certificate subject to one workload owner and deployment |
| Person or entity authentication (45 CFR 164.312(d)) | Verify that a person or entity seeking access is who it claims to be | Require client certificate authentication between services and reject connections without a valid chain to the internal root | Server configuration showing mTLS is enforced, plus failed handshake logs |
| Audit controls (45 CFR 164.312(b)) | Record and examine activity in systems that contain ePHI | Log every certificate issuance, renewal, revocation and CA administrative action, and forward them to the monitoring platform | CA audit logs with timestamps, operator identity and periodic review records |
| Transmission security (45 CFR 164.312(e)) | Protect ePHI transmitted over networks, including encryption where appropriate | Encrypt east-west service traffic with TLS 1.2 or later and short-lived certificates, covering internal hops as well as perimeter traffic | Cipher and protocol settings per service, and scan results for plaintext internal endpoints |
| Encrypt customer information in transit (16 CFR 314.4(c)(3)) | Encrypt customer information in transit over external networks and within the institution | Apply mTLS to internal APIs that carry customer data, including hops inside the cluster, not only the public edge | Inventory of services handling customer data with their certificate and TLS status |
| Monitor and log authorized user activity (16 CFR 314.4(c)(8)) | Monitor and log activity of authorized users and detect unauthorized access | Log workload identity on each request, so service-to-service calls can be attributed to a specific certificate | Sample request logs showing caller identity, retention settings and alert rules for unexpected callers |
| Multi-factor authentication (16 CFR 314.4(c)(5)) | MFA for any individual accessing an information system | Certificates authenticate workloads, not people. Human access to the CA and provisioners still needs MFA through the identity provider | Access reviews of CA administrators with MFA enforcement records |
| Scope of applicability | Whether HIPAA or the FTC Safeguards Rule applies depends on your entity type and data | Confirm with counsel or an assessor before treating this mapping as a compliance position | Written applicability determination kept with the PKI design records |
Which open-source CA and secrets platforms fit service-to-service mTLS
Service-to-service mTLS depends on which CA issues workload certificates, how services prove their identity to it, and who on your team operates it. The options below differ mainly in provisioner and auth model, key protection, and license terms, so the choice should follow your existing identity and secrets tooling.
step-ca as a dedicated workload CA
step-ca is Smallstep's open-source online certificate authority under Apache-2.0, built to issue short-lived X.509 certificates for TLS and mutual TLS through ACME, OIDC, cloud instance identity and JWK provisioners. It fits teams that want a focused CA service with automated renewal and no general secrets engine around it. Check which provisioner your workloads can use to authenticate, how CA keys will be protected in an HSM, cloud KMS or YubiKey, and whether your renewal client can rotate certificates without a restart.
OpenBao PKI alongside secrets management
OpenBao is an MPL-2.0 fork of Vault, hosted by the OpenSSF under Linux Foundation stewardship, that combines a PKI secrets engine with key/value storage, dynamic secrets and leasing. It suits organizations that already plan to centralize secrets and want certificate issuance under the same audit, policy and HA model. Confirm the PKI role, TTL and revocation features you need against the current OpenBao documentation before committing to a design.
Workload authentication through auth methods
Issuing a certificate is only as strong as the proof a workload gives to get one. OpenBao documents auth methods including Kubernetes, JWT/OIDC, AppRole and TLS certificates, and it recommends AppRole for servers. step-ca relies on its own provisioners, so the question is whether your platform identity (Kubernetes service accounts, cloud instance identity or an existing OIDC issuer) maps cleanly onto one of them. Test this with a sample workload before standardizing.
Storage and high availability model
OpenBao's documented storage backends are integrated storage (Raft), PostgreSQL, PebbleDB and in-memory, and its HA model uses an active node holding a lock with standbys forwarding requests. If the CA is in the request path for every service start, its availability and backup procedure matter as much as the issuance logic. Ask your platform team which backend it already operates, and confirm current HA and read-scaling behavior in the docs before sizing the cluster.
Vault 1.15.0 and later licensing
HashiCorp Vault version 1.15.0 and later is licensed under the Business Source License 1.1 with IBM named as licensor, which is not an OSI-approved open source license. Teams that want a permissive, community-governed codebase for internal mTLS should treat this as a procurement and legal question, not a technical one. Confirm the license terms that apply to your version and deployment with counsel before selecting Vault as the basis for a self-hosted CA.
Matching the platform to team skills
Choose by the tools your teams already run. If identity is handled by Keycloak, authentik or FreeIPA and secrets by OpenBao, a PKI engine in OpenBao keeps policy and audit in one place. If the platform team mainly automates Kubernetes and cloud workloads, step-ca with an ACME or cloud provisioner may be simpler to operate. Document who owns the root and intermediate keys, who approves provisioner changes, and who responds when renewal fails.
How workload identity is proven: provisioners versus auth methods
In step-ca, a provisioner is the rule that decides whether a certificate request is allowed and which certificate profile it receives. Before the CA signs anything, the provisioner checks proof of identity supplied by the requester. The supported provisioner types include ACME, OIDC, cloud instance identity and JWK, so the choice depends on where your workloads run and which identity source they already trust. Provisioners are configured on the CA itself, so changes to them are changes to your trust model and should go through the same review as a policy change.
- OIDC provisioner: verifies a token from your identity provider, so the certificate is tied to a user or a service principal that the provider has authenticated. You must provision the OIDC client, restrict allowed domains or subjects, and set the certificate lifetime limits in the provisioner.
- Cloud instance identity provisioner: verifies the signed instance identity document issued by the cloud platform, so the identity is the virtual machine itself. You must confirm which cloud accounts and regions are trusted and which instance attributes map to certificate names.
- JWK provisioner: verifies a signature made with a key pair you distribute to the workload, so the identity is only as strong as the protection of that private key. You must plan key delivery at provisioning time and a rotation path for keys that leak.
- ACME provisioner: verifies challenges such as HTTP-01 or DNS-01 for names the requester controls, which suits ingress and clients that already speak ACME. If the CA is unreachable, renewal stops and certificates expire on their normal schedule, so the renewal window must be shorter than the certificate lifetime with margin.
Confirm with your platform team which identity source is authoritative for each workload class and what happens to running services when that source is unavailable.
OpenBao auth methods answer a different question: which client may log in and then read secrets or ask the PKI secrets engine for a certificate. A client authenticates to OpenBao, receives a token with attached policies, and that token controls which paths it can use. This model fits services that already fetch database passwords or API keys from OpenBao, because the certificate becomes one more secret in the same workflow. OpenBao documents AppRole, Kubernetes, JWT/OIDC and TLS certificate methods, among others, and recommends AppRole for servers.
- AppRole: verifies a role ID and a secret ID issued to a server, so the identity is the role the operator has bound to that machine. You must provision roles with narrow policies, decide how the secret ID reaches the host, and set short secret ID lifetimes.
- Kubernetes auth: verifies the service account token of a pod against the cluster, so the identity is the namespace and service account. You must configure the cluster connection and bind each service account to a role with only the PKI paths it needs.
- JWT/OIDC auth: verifies a token from your identity provider, so the identity follows the user or workload claims you map. You must define claim mappings and confirm that the provider can issue tokens for non-human workloads.
- TLS certificate auth: verifies a client certificate that OpenBao already trusts, which suits bootstrapping but creates a chicken-and-egg problem for the certificates it is meant to issue. Plan the initial trust anchor carefully.
If the identity provider or Kubernetes API is unavailable, new logins fail, but tokens already issued keep working until their lease ends, so confirm your token lifetimes against your outage tolerance.
The practical choice is less about which tool is more secure and more about where the authoritative identity lives and which system the team already operates. Many environments use both: step-ca for certificate issuance tied to cloud or provider identity, and OpenBao when workloads already read secrets from it and certificate requests can follow the same login. Running two issuing paths for the same service name creates trust confusion, so decide per workload class and record the decision.
- Start from the identity source: list where each workload's identity is already established, such as cloud metadata, the cluster API, or the identity provider, and prefer the provisioner or auth method that reads that source directly.
- Avoid shared credentials: a JWK key or AppRole secret ID copied to many hosts behaves like a shared password, so favor identities that are issued per instance.
- Separate issuing roles: give each provisioner or PKI role its own allowed names and maximum lifetime so a compromised identity cannot request arbitrary certificates.
- Keep the CA and the auth system in separate failure domains where practical: confirm which services will still start if one of them is down.
- Record the mapping: keep a register that ties each workload to its provisioner or auth role, owner and renewal path, because auditors will ask how a certificate's subject was established.
Before committing, ask your implementation partner to show the failure behavior of each identity source in a test environment, including what breaks first.
Rollout phases for moving internal service traffic to mTLS
This sequence moves internal service traffic from plain or perimeter-trusted connections to mutual TLS in controlled stages. Each phase produces a artifact that the next one depends on, so the CA design, workload identities and outage plan are settled before any production traffic changes.
Build the service inventory and call map
Start by listing every service, batch job and sidecar that makes or accepts internal calls, then record which services call which, over which ports and protocols, and who owns each one. Assign each service a unique identity name that will later appear in certificate subjects or SANs, and flag shared service accounts, since they block per-workload identity. The output is a call map that a security engineer and the service owners have both signed off. You know this step is done when every call path in the map has an owner and a named identity, and no service is still using a shared credential.
Decide the CA hierarchy and key custody
Define the trust chain for workload certificates, including whether a root stays offline and whether the online issuing CA runs in step-ca, OpenBao PKI or another platform. Decide where CA private keys live, such as an HSM, cloud KMS or a hardware token, and who can operate them. Confirm with the vendor and your own environment which key storage options the chosen CA supports before you commit. The output is a written CA design document with key custody rules and an approval record. You know this step is done when the design names an issuing CA, a key custody method and an owner for each key.
Map provisioners and auth methods to workload classes
Group workloads by how they start and what identity they can prove, such as Kubernetes pods, virtual machines, cloud instances or CI jobs, and pick a provisioner or auth method for each class. step-ca offers ACME, OIDC, cloud instance identity and JWK provisioners, and OpenBao documents auth methods including Kubernetes, JWT/OIDC, TLS certificates and AppRole. Document the certificate lifetime and subject rules per class, and record which workloads cannot authenticate automatically and need a manual or exception path. The output is a provisioner matrix reviewed by the platform and security teams. You know this step is done when every workload in the inventory maps to exactly one issuance path.
Pilot mTLS on one call path
Choose a single, low-risk call path between two services that you own, then issue certificates to both ends and enforce mutual authentication on that path only. Test rotation while the services keep running, so you can confirm that new certificates are picked up without a restart, or identify where a restart or reload is still required. Record the handshake failures, client trust errors and reload behavior you observe. The output is a pilot report with a rotation test result and a rollback procedure. You know this step is done when a certificate rotates on both ends and traffic continues without a service restart.
Expand with issuance and expiry monitoring
Extend mTLS to the remaining call paths in waves that follow the call map, and place monitoring on issuance requests, failed renewals, handshake errors and upcoming expiry for every issued identity. Alert on renewal failures early enough that an operator can act before a certificate lapses, and keep a current inventory of which identities exist and where they are deployed. Each wave should have its own rollback step. The output is a dashboard and alert set that the operations team owns. You know this step is done when every wave has monitoring in place and renewal failures produce an alert that reaches a named on-call team.
Document the CA outage runbook
Write down what happens when the issuing CA or its auth backend is unreachable: how far workloads can keep using cached certificates, what grace periods apply before a service must stop trusting an expired identity, and who can invoke break-glass trust. Test the runbook with a controlled outage in a non-production environment and confirm the behavior with the CA vendor's documentation. Include steps for restoring issuance and re-validating trust afterward. The output is a runbook with tested steps and named approvers. You know this step is done when the team has run the outage test and the break-glass path has been reviewed and recorded.
How rotation works without restarts and what to do when the CA is unavailable
Short-lived certificates only work if every workload renews before expiry, so the renewal window is the first design decision. Set the renewal point well before the certificate's notAfter time, and make the client library or sidecar responsible for fetching a new certificate and private key on that schedule. Most step-ca and OpenBao PKI issuance paths let a workload request a fresh certificate with the same identity proof it used at first issuance, which keeps renewal from depending on a human. Confirm in each client library you plan to use whether it renews automatically, whether it reloads the new certificate into a running process, and what it does when renewal fails. Those three behaviors vary and decide how much custom code you will own.
Reloading matters as much as renewing. Services should pick up the new certificate through a file watcher, a sidecar proxy or the library's built-in reload hook, not a process restart, because a restart for every rotation turns certificate lifetime into an outage schedule. The harder part is trust. When the intermediate CA or the root changes, every peer must already trust the renewed chain, so distribute trust bundles ahead of any chain change and test a mutual handshake between old and new certificates before the old chain is retired. Remember that a workload holding a valid certificate keeps working until expiry even if the CA is down, which gives you a window to act.
Design for CA unavailability before it happens. Run the issuer online with more than one replica and a supported high availability backend: OpenBao documents integrated storage (Raft) and PostgreSQL as its officially supported HA backends, with an active node holding a lock and standbys taking over. Monitor issuance failures and the time remaining on each workload certificate, and alert well before the renewal window closes. Write down who may authorize emergency measures, such as temporarily extending certificate lifetimes, adding a backup issuing intermediate or disabling a compromised provisioner, and make sure that person has a tested break-glass path to the CA. Ask your partner to rehearse a full issuer outage in a non-production environment and record how long services kept working.
Evidence auditors ask for on service certificates and which component produces it
This table maps the evidence an assessor typically asks for on service-to-service certificates to the component that produces it, whether step-ca, OpenBao or the surrounding tooling. Read it as a checklist to confirm early, because some records only exist if logging, inventory and key custody were designed in from the start. DeployOpen prepares this evidence but does not issue attestations; independent assessors make the determination.
| Evidence item | Produced by | What to confirm before the assessment |
|---|---|---|
| CA hierarchy and policy documents | Your certificate policy and CA design records, referencing the step-ca or OpenBao PKI configuration | Root and issuing CA chain, intended use per CA, and lifetimes for workload certificates are written down and approved |
| Issuance logs for workload certificates | step-ca audit output or OpenBao audit devices, forwarded to your log platform | Logs record requester identity, subject, serial and time, and are retained and protected from edit by the CA operators |
| Provisioner or auth method configuration | step-ca provisioner definitions (such as JWK, OIDC or cloud instance identity) or OpenBao auth method and role settings | Each workload identity maps to a named provisioner or role, and changes to these settings are tracked under change control |
| Inventory of issued workload certificates | CA issuance records joined with service catalog data, plus scanner results for endpoints that bypass the CA | Every service with a certificate has an owner, and the inventory reconciles with what is actually deployed |
| Expiry and renewal monitoring records | Alerting from the CA, certificate renewal agents or the monitoring stack watching certificate expiry | Alerts fire before expiry, failed renewals open tickets, and the history of alerts and responses is kept |
| Key custody records for CA keys | HSM, cloud KMS or YubiKey configuration for step-ca, or the seal and storage configuration for OpenBao, plus ceremony records | Who can use the CA key, how it is backed up, and whether key access is logged and split across custodians |
| Access records for who could issue or revoke | Identity provider group membership, OpenBao policies and tokens, and step-ca admin access logs | Only named roles can issue, revoke or change provisioners, and access reviews are scheduled and signed off |
| Revocation and CA unavailability procedures | Revocation process records and documented runbooks for CA outages and emergency certificate replacement | Revocation paths work for workloads that cannot reach the CA, and the tested outage response is documented |
What do buyers ask before hiring help for service-to-service mTLS?
What drives the effort and cost of a service-to-service mTLS rollout?
The main drivers are the number of services, the mix of languages and runtimes, how the CA keys are protected, and how many identity sources the workloads must authenticate against. Each service needs a client certificate, a trust bundle, and a renewal path, so the work scales with the count of distinct runtimes more than with the count of services. Key protection is a separate decision: step-ca can keep CA keys in HSMs, cloud KMS or YubiKeys, and that choice changes procurement, change control and recovery steps. Recurring costs come from operating the CA, monitoring renewals and handling new services. Ask any partner to split the quote into one-time design and build work, per-runtime integration work, and ongoing operations, and to state which of these depend on your HSM or KMS choice.
How much time and team involvement does an mTLS project need?
The timeline depends on the number of services, how many already speak TLS, and how quickly service owners can change their clients and servers. Plan for participation from service owners who must adopt certificate loading and reload behavior, platform engineers who run the CA and the trust distribution, and security staff who approve the certificate profiles, lifetimes and authorization rules. Security sign-off is usually needed twice: once for the CA hierarchy and provisioners, and again for the rollout to production services. Confirm with any implementation partner which of these roles they will fill, which you must staff internally, and how many review cycles the written scope includes.
Can our team build service-to-service mTLS without outside help?
A capable platform team can build it without outside help if it has time to design the CA hierarchy, learn the provisioner model, and integrate each runtime. The harder parts are usually not the first certificate but the edges: trust bundle distribution, rotation without restarts in every language, authorization on the server side, and the failure modes when the CA is unreachable. Teams that run a small number of services on one platform often manage this in-house. Teams with many runtimes, strict key custody rules, or an audit deadline often bring in a partner for the design review and the first few integrations. DeployOpen implements, hardens and documents self-hosted platforms in the client's own infrastructure, and most engagements are fixed-scope with the scope agreed in writing before work starts.
Why choose step-ca over OpenBao PKI for workload certificates?
The choice depends on what else you run and where workload identity will come from. step-ca is Smallstep's open-source online CA for automated issuance and renewal of private X.509 certificates, licensed under Apache-2.0. It issues TLS and mutual TLS certificates, supports ACME for renewal, and authorizes requests through ACME, OIDC, cloud instance identity and JWK provisioners. OpenBao is an MPL-2.0 secrets manager, forked from Vault and managed under the OpenSSF, with a PKI capability and a range of auth methods including Kubernetes, JWT/OIDC, AppRole and TLS certificates. If you already run OpenBao for secrets and want one authentication plane, OpenBao PKI may fit. If you want a dedicated CA with ACME-based renewal and cloud-native provisioners, step-ca often fits better. Ask a partner to test both against your identity sources and your key custody requirements before deciding.
What happens to running services when the CA is unavailable?
Services that already hold valid certificates keep working until those certificates expire, so the design question is how long an outage can last before expiry affects traffic. Short lifetimes shorten the window of exposure but also shrink the time you have to fix a CA outage before renewals fail. Good designs include a highly available CA backend, a documented procedure for restoring issuance, monitoring that alerts well before expiry, and a plan for what new workloads do while issuance is down. OpenBao documents integrated storage (Raft) and PostgreSQL as its officially supported high-availability backends, and an active node with standbys. For step-ca, confirm the deployment model, backup of CA state and key access during recovery with your partner. Test the outage scenario in a non-production environment before go-live.
Does this project help with the public 47-day certificate timeline?
Yes, the same automation applies, but the two timelines are separate. Public TLS certificate lifetimes fall to 200 days in March 2026, 100 days in 2027 and 47 days in 2029, and that schedule governs certificates issued by public CAs. Internal mTLS certificates from your own CA are not bound by that schedule, so you choose their lifetimes. Many teams use the work to build the inventory and automated renewal that the public schedule will require, then move internal services to short-lived certificates from their own CA. Confirm the lifetime policy for each certificate class with your security team and document it, because assessors will look for the reasoning behind each choice.
Which compliance evidence does a self-hosted mTLS design produce?
A well-run design produces a CA policy, certificate profiles and lifetimes, a record of issuance and revocation, an inventory of workload identities, and logs showing who or what requested each certificate. These support the access control and unique identification expectations in the HIPAA Security Rule at 45 CFR 164.312, which covers unique user identification, audit controls, person or entity authentication and transmission security. The FTC Safeguards Rule at 16 CFR 314.4 asks covered financial institutions to encrypt customer information in transit and to monitor and log activity. DeployOpen prepares these systems, controls and evidence for assessments but does not issue audit reports or certifications, so confirm with your auditor which artifacts they expect.
Questions to ask an implementation partner about mTLS and the CA
Start with the root and key custody, because nothing downstream is easy to undo. Ask the partner to walk you through the root key ceremony: who attends, what is recorded, where the root and intermediate keys are generated, and whether they can be held in an HSM or a cloud KMS. For step-ca, ask how CA keys are protected, since the product can use HSMs, cloud KMS or YubiKeys, and confirm which of those your environment actually supports. For OpenBao PKI, ask how the unseal material and the storage backend (integrated Raft or PostgreSQL) are protected and backed up. Ask who holds the keys to the root after handover and how a rotation of the intermediate would be performed. Next, test the identity model. Ask how each workload gets a unique identity: which provisioner or auth method issues its certificate (ACME, OIDC, cloud instance identity, JWK for step-ca, or Kubernetes or AppRole for OpenBao), and whether two replicas of the same service can be told apart in the certificate subject or SAN. Ask how rotation works without restarts in each language and runtime you run, including whether the partner has tested reloading certificates in your JVM, Go, Python and Node services. Request a short list of services that will fail if a certificate is rotated mid-connection, and ask how those are handled. Finally, cover failure and ownership. Ask for the CA outage design: how long already-issued certificates keep working, where break-glass signing happens, who can authorize it, and how that path is tested. Ask how audit logs are retained and exported to your SIEM, and for the migration plan from your existing CA, including trust bundle distribution. Confirm who owns the runbooks after handover and whether they are reviewed on a schedule you control.
How DeployOpen scopes, builds and supports service mTLS
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the CA, workload identity and rotation design for mutual TLS. We start from your service inventory and failure requirements, then agree a written scope before any build work begins.
How we scope
- Inventory of services, languages, runtimes and the trust boundaries each mTLS connection crosses
- Choice between step-ca and OpenBao PKI for issuance, with the CA hierarchy and key custody method agreed in writing
- Certificate lifetimes, renewal thresholds and the behavior expected when the CA is unreachable
- Named provisioners or auth methods for each workload type, including Kubernetes and VM identity sources
How we build
- Deploy the chosen CA in your cloud accounts, data centers or air-gapped network, with keys in your HSM, cloud KMS or hardware token
- Configure workload identity through provisioners or auth methods, so each service receives its own short-lived certificate
- Wire rotation into service clients and sidecars so certificates renew without restarts where the runtime supports it
- Test expiry, revocation and CA outage scenarios against the documented failure behavior before cutover
How we hand over
- Runbooks for issuance, renewal failures, emergency trust changes and CA key recovery, written for your operations team
- Architecture and configuration records mapping each control to the evidence an auditor or assessor will request
- Knowledge transfer sessions with your platform, security and application teams, with the handover scope listed in the written agreement
- Inventory exports and logging configuration that show issuance and renewal activity for your own review
How we support
- Fixed-scope engagements with deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Security testing of the mTLS deployment, including the CA, issuance paths and service trust configuration, on request
- Confirm with DeployOpen the support terms, response expectations and upgrade cadence in your written scope
