Standard and Process

See the specific requirements in the Encryption Management Standard in the University Policy Library. The following supplements the requirements in University policy.

Use existing or build upon system features (e.g., operating system) and infrastructure (e.g., Box storage) for encryption, since they provide the key management.

Encryption needs to be used in conjunction with other security controls (e.g., authentication, access control, account management, change management). For example, use a strong sign-in password for your device or workstation and lock your screen when not using the device/workstation.

Encryption requires proper key management. When a key is lost, it is highly likely that the data on the device cannot be recovered.

Store secret and private keys used to encrypt/decrypt data in one or more of the following forms at all times:

  • encrypted with a key-encrypting key that is at least as strong as the data encrypting key, and that is stored separately from the data-encrypting key;
  • within a secure cryptographic device (e.g., hardware (host) security module (HSM) or PTS-approved point-of-interaction device);
  • has at least two full-length key components or key shares, in accordance with industry-accepted method.

Follow the NIST standards and guidelines for encryption and cryptography.

Data Encryption and Export Controls

Export and import of encryption products must comply with all applicable laws and regulations of the countries involved, including those countries represented by foreign nationals affiliated with the University. Research that incorporates, develops, or uses data encryption software, both mass market and custom-developed, must comply with International Traffic in Arms Regulations (ITAR) and Export Administration Regulations (EAR).


All processes and procedures for encryption key management must be documented (including key generation, distribution, archiving, renewal, retirement, revocation, deletion/destruction, compromise plan).

The key or cryptographic key management plan should include documenting the:

  • creation/generation of the key,
  • use of the key,
  • recovery of the key,
  • storage of the key,
  • archival of the key,
  • retrieval of the key,
  • distribution of the key,
  • retirement of the key, and
  • destruction of the key.

Key management procedures need to include instructions on how to:

  • generate the key for different cryptographic systems and applications;
  • issue and obtain public key certificates;
  • distribute keys to intended entities, including how keys should be activated when received;
  • store keys, including how authorized users obtain access to keys;
  • change or update keys including rules on when keys should be changed and how this will be done;
  • deal with compromised keys;
  • revoke keys including how keys should be withdrawn or deactivated when keys have been compromised or when a user leaves or changes responsibilities;
  • archive keys when changing the key or when a user leaves the University;
  • how to recover keys that are lost or corrupted;
  • back up keys;
  • destroy keys;
  • track and review key management activities.

Archived keys should only be used for decryption/verification purposes.

Encryption for Data Transmission

In the following type of data transmission, restricted data includes data classified as private-highly restricted or private-restricted data.

File Transfers

Encryption of restricted file and data transfers can be achieved via the use of an encrypted
transmission protocol or network service (e.g., SCP, SFTP, IPSec, TLS, Box, etc.) or by transferring any restricted file that has been encrypted prior to the transmission.

Interactive User Sessions

Encryption of restricted data, including authentication passwords, transmitted during remote login sessions (e.g., SSH, PeopleSoft, Gmail, and remote control software for PCs) shall be provided through the use of secure applications or protocols.

Web Applications

Encryption of restricted data communicated between a user's browser and a web-based
application will be provided through the use of current and supported secure protocols (e.g., HTTPS via TLS, etc.).

Database Access

Encryption of restricted data transmitted between an application server and a database shall
be implemented to prevent unauthorized interception.

Application Communications

Encryption of restricted data transmitted between cooperating applications shall be provided
through the use of commonly available encrypted protocols (e.g., SOAP with HTTPS).

Virtual Private Network (VPN)

A VPN connection offers an additional option for protecting restricted data transmitted via the
network when other alternatives are not feasible. The use of VPNs should be carefully
considered so that all security and networking issues are understood. Telecommunications
Infrastructure (e.g., Networking) staff should be consulted prior to any VPN implementations.


University employees who work with Protected Health Information (PHI) as part of their job responsibilities are able to send email messages using the Proofpoint Secure Email Center.

Non-Enterprise Wireless Communications

All wireless communications not using enterprise provided wireless (e.g, Eduroam Wi-Fi) that transmit restricted data must use FIPS 140-2 validated encryption methods. This includes, but is not limited to ZigBee, Thread, Cellular, NFC, Low Power Radio (LPR), Bluetooth, etc.

See the Information Security policy appendices for additional information security standards that also apply.

More Information

Document Management

Document Responsibility and History
Document Owner Document Approvers Effective Date Last Reviewed Date
University Information Security

Brian Dahlin,
Chief Information Security Officer

Bernard Gulachek, 
VP of Information Technology and Chief Information Officer

August 2010 May 2019