Рекомендуется, чтобы апплет расширял возможности сервера только в контексте аутентификации. Сервер должен перепроверить, что было отправлено апплетом (клиентом), поскольку сообщение могло быть изменено при передаче.
Однако бывают случаи, когда апплет может служить действительной цели. Например, сообщения, отправляемые клиентом, могут иметь цифровую подпись апплета, причем ключи управляются на USB-накопителях для каждого пользователя (содержащих закрытые ключи). В таком контексте апплет служит механизмом доступа к библиотекам JCA в Java, помимо доступа к USB-хранилищу. Полученная подпись должна быть повторно проверена сервером при получении сообщения.
При правильной реализации апплеты, подобные любой схеме безопасности на стороне клиента, повышают уровень безопасности приложения.
При неправильной реализации это приводит к появлению системы безопасности, где сервер полагается на клиент для обеспечения надежного ввода. Кроме того, если нужно выполнять привилегированные операции (например, диски доступа, содержащие закрытые ключи), то апплет должен быть подписан; и соответствующий файл политики безопасности Java должен быть сохранен. Любые ошибки в процессе управления модели безопасности Java, очевидно, снизят безопасность системы. Кроме того, если необходимо получить доступ к API-интерфейсам, относящимся к собственным ОС, таким как MSCAPI, развертывание нативного кода (DLL) является обязательным условием, и программное обеспечение (не апплет), ответственное за это, должно быть надежно написано.