anchor.diff:  +
   After you've finished integration and development, you'll need to move disk images from one account to another. For example, you might want to send a development build that you’re happy with to the QA team, or send that build to the deployment team once it’s passed QA.
   
  -//  end::deploy-steps[]+//  end::deploy-steps[]
  
positive.code: 
  * *Set up different user logins*
  +
  In OTA Connect, all devices and software belong to one *user* login. However, you don't want to mix up test software and production software by creating them all under the same user.
  +
  In a proper production workflow, you'll need separate user logins to manage the different stages:
  +
  . A developer user such as "dev@acme.com".
  . A QA user such as ""qa@acme.com"".
  . A production user such as "prod@acme.com"".
  +
  These logins provide you with a convenient way of clearly separating your development, QA and production resources.
  
  ////
  COMMENTING OUT UNTIL ORGANIZATIONS STOPS BEING "ALPHA"
  
negative.code: A user can belong to multiple organizations, and it's easy to switch between them. This provides you with a convenient way of separating your development, QA and production resources.
  ////
  
  * *Start using device-credential provisioning for your devices*
  +
  The term *device-credential provisioning* refers to the process of installing or generating a unique X.509 certificate on each device _before_ adding it to your OTA Connect account, instead of having OTA Connect generate the certificate for each device after it registers.
  +
  Although it's convenient to use shared-credential provisioning so that the OTA Connect server manages the whole process, using shared-credential provisioning means that a private key gets transmitted from the OTA Connect server to each vehicle. For automotive-grade security, most large fleet owners will want to use a TPM or other type of hardware security module, so that the vehicle's private key material never has to exist outside of the vehicle.
  +
  In the initial integration phase you might not have the TPM/HSM ready to use, but you can still start using device-credential provisioning, using a self-signed certificate and loading signed device certificates onto your test devices using our tooling and instructions.
  
  * *Use offline keys to sign software metadata*
  +
  Strong, automotive-grade security using Uptane is one of the most important parts of OTA Connect. Uptane achieves its security benefits by using multiple different, interdependent roles and repositories to sign software, establish trust, and ensure other important security properties. For a truly secure Uptane deployment, the keys that are used to sign metadata should be kept offline--for example, on a hardware security module like a Yubikey. To save you from the difficulties and complications of managing offline keys, new OTA Connect accounts start off by using online signing keys kept in secure storagefootnote::[Using HashiCorp's https://www.vaultproject.io/[Vault], an industry-standard best practice.]. When you upload software and disk images to OTA Connect, the server generates and signs the associated metadata for you.
  +
  During the integration phase, you should take the signing keys offline and rotate them. This puts you in complete control over your fleet's security--even if an attacker somehow compromised the entire OTA Connect infrastructure, they still wouldn't be able to install their software on your vehicles.
  +
  For the integration phase, it's fine if you keep these keys on your development computer. Later, you'll want to keep these keys somewhere more secure.
  
  * *Start customizing the update client*
  +
  Most production use cases will have unique requirements that aren't met by the stock aktualizr app. With libaktualizr, the C++ library used to build aktualizr, you can customize every step of the installation process. Some examples of what you can do:
  * Hook into an HMI system to ask for user confirmation before installing an update
  * Check for safety conditions in the vehicle before starting an update
  * Only download large updates when the vehicle is connected to WiFi, or at off-peak times
  * Pass an update for a secondary ECU off to a custom UDS flashing tool
  +
  To prove you with some inspiration, we've created a demo app that integrates libaktualizr, along with a Yocto layer to integrate it.
  
  //  end::integrate-steps[]
  
  