Защита на уровне ключа? драйвера? API?

В современных электронных ключах Guardant, наличие механизма шифрования трафика между электронным ключом и Guardant API дает возможность на аппаратном уровне ограничить использование локального ключа одновременно из нескольких терминальных сеансов.

Подробнее о данном механизме можно прочитать в руководстве по утилитам Guardant: часть 1 стр. 68, часть 2 стр. 10 (по умолчанию вся документация находится в одной папке с установленным комплектом разработчика: %Program Files%\Guardant\Guardant 6\%Public Code%\Doc\).

Вне зависимости от используемой версии Guardant API, защиту от терминальных сессий для старых моделей электронных ключей нужно реализовывать самостоятельно, например:

При необходимости запрета запуска нескольких копий приложения разработчику самостоятельно следует использовать специальные методы, например, создание глобальных объектов или эвентов. 
Такой запрет можно организовать, как с помощью Guardant API, используя декрементацию счётчиков разными копиями приложения, так и запретом на запуск приложения в нескольких сессиях, используя именованный объект (с префиксом "Global\") с учётом рекомендаций MSDN.

В дополнение можно посоветовать еще один простой, но интересный способ.
Он заключается в том, что приложение в случайный момент времени генерирует случайное число, подвергает его изощренным преобразованиям и записывает в определенный адрес памяти ключа. Через некоторый случайный промежуток времени приложение считывает записанное число, подвергает его преобразованиям и сравнивает с тем, что было сгенерировано. Очевидно, что вторая запущенная копия приложения будет делать то же самое. Если числа не сойдутся, значит работает больше одной копии приложения.

Также рекомендуем обратить внимание на ПО Guardant последних версий.
В ПО Guardant начиная с версий 5.хх при работе с локальными ключами можно организовать запреты на запуск нескольких копий приложения с помощью блокировки ключа текущей копией приложения (функция GrdLock).

Все современные модели локальных ключей имеют встроенную защиту

Защита на уровне ключа? драйвера? API?

Иными словами, если ли ключ старый (Stealth I или II), а приложение новое (API 6.2), то как оно должно работать в терминальном сервере?

То есть, если клиент не хочет тратить по лицензии на каждую терминальную сессию, то он может запустить старый сервер и потратить одну лицензию на все терминальные сессии.

Нет, не может. Guardant API, автозащита и сервер сетевых ключей Guardant Net из состава комплекта разработчика версии 6.2 НЕ имеют обратной совместимости с этими же элементами предыдущих версий. Другими словами, приложение, защищенное с помощью утилит защиты версии 6.2, не будут работать с сервером более поздней версии.

Все современные модели локальных ключей имеют встроенную защиту от тиражирования лицензий за счет терминальных серверов (1 сессионный ключ для Guardant API и 1 сессионный ключ для автозащиты).

Нет, данный режим лицензирования есть только в API версии не ниже 6.1.

Если имеется в виду та версия сервера сетевых ключей, которая войдет в состав ожидаемого в декабре е нового релиза...

То есть, если клиент не хочет тратить по лицензии на каждую терминальную сессию, то он может запустить старый сервер и потратить одну лицензию на все терминальные сессии.

У как ведет себя локальный ключ в терминальном сервере?

И еще вопрос: можно ли в старом API (nsk/nnk) включить режим PerProcess?

Как будет вестись подсчет лицензий сервером при логине к сетевому ключу с опцией лицензирования на рабочую станцию из программы, выполняемой на терминальном сервере?
Одна лицензия на все запуски, или все же будет разделение по терминальным сессиям?

Если имеется в виду та версия сервера сетевых ключей, которая войдет в состав ожидаемого в декабре нового релиза комплекта разработчика, то да, будет разделение по терминальным сессиям.

Одна лицензия на все запуски, или все же будет разделение по терминальным сессиям?