There are several considerations for implementing security labels with RACF® system-wide options. For details about implementing security labels, see z/OS Planning for Multilevel Security and the Common Criteria.

1. Once you activate the SECLABEL class, users who logon without a security label can no longer access resources protected by security labels. Therefore, you should assign a security label to all users before you assign a security label to a commonly accessed resource, such as SYS1.BRODCAST. Each user who does not have a default label must provide a security label at logon time or else be denied access to the system.
2. If you assign a security label to a resource profile while the SECLABEL class is active, the security label you assign to the users must allow the required users to access the resource.

   This also applies to the z/OS UNIX environment. When you create a z/OS® File System (zFS) file system in a data set covered by a security label while the SECLABEL class is active, directories and files within that file system will be created with security labels. Only users with the appropriate security labels will be allowed to access those files and directories.

3. If your installation uses the SETROPTS MLACTIVE option, all data protected by classes that require security labels must have security labels. For more information, see Enforcing multilevel security (MLACTIVE option).
4. If your installation uses the SETROPTS MLS(FAILURES) option, there are tighter restrictions on attempted accesses to resources, depending on the kind of access attempt and the security labels of the resource and user. For more information, see Security label authorization checking.
5. If your installation uses the SETROPTS MLS(FAILURES) option, the first data set written to a tape volume defines the security label of any data set that is later written to the tape. For more information, see Preventing the copying of data to a lower security label (SETROPTS MLS option).
6. If your system includes products that do not support security labels when they invoke RACF, you should consider using the SETROPTS COMPATMODE option. See Activating compatibility mode for security labels (COMPATMODE option).
7. If your installation uses the SETROPTS MLFSOBJ option, all files and directories must have security labels. No users (except trusted and privileged started tasks) will be able to access files and directories that do not have security labels. See Restricting access to z/OS UNIX files and directories (MLFSOBJ option).
8. If your installation uses the SETROPTS MLIPCOBJ option, all resources related to interprocess communication must have security labels. No users (except trusted and privileged started tasks) will be able to access interprocess communication resources that do not have security labels. See Restricting access to interprocess communication objects (MLIPCOBJ option).
9. If your installation uses the SETROPTS MLNAMES option, users cannot view the names of data sets, files, and directories that cannot be read from their current user security labels. Users are similarly restricted from seeing authorized resource names when they list catalogs and directories. This option is also called name-hiding. Note that if the SECLABEL class is not active while MLNAMES is active, data set names will still be hidden from users who do not have at least READ access to the data sets. See Using name-hiding (MLNAMES option).
10. If your installation uses the SETROPTS SECLBYSYSTEM option, certain security labels can be activated on certain systems, based on the system identifiers specified in the SECLABEL class profile for each security label. See Activating security labels by system image (SECLBYSYSTEM option).